AlexandrY

Заклинания тут не помогут. Просто вы зомбированы стандартными рисунками где всегда рисуют ротор с 4-я полюсами на 3-и зубцами (электрическими , к сведению)

В смысле поверили на слово jcxz? Так он не назвал количество зубцов. Т.е. либо придумал сейчас на ходу, либо у него соотношение 3/4 остается постоянным.

Ну попробуйте вместо 4-х полюсного ротора вставить 8-и полюсный и управлять по той же таблице. Как раз дерганья и получите.

А вы в курсе, что таблица коммутации ключей зависит от числа полюсов на роторе? Обратите внимание на эту таблицу - http://www.bavaria-direct.co.za/info/ К каждому сочетанию полюсов и обмоток нужно определять правильную таблицу коммутации. Небольшое запаздывание коммутации из-за прерываний никак не вызовет заметные дерганья у BLDC, так что эту версию сразу можно отмести.

Есть вот такое - https://habr.com/ru/post/392839/ На пины выведено 6-ть UART-ов не считая 2-х VCOM портов по HS USB. На борту литиевая батарейка и RTC. Софтовый фреймворк с RTOS, драйверами UART, и файловой системой прилагается.

Откуда в BLDC асинхронный режим подобный "режиму асинхронных эл.двигателей"? Хотя полностью отрицать нельзя, материал ротора может быть довольно хитрый. Во всяком случае в свое время мне никто не объяснил почему при повороте ротора так сильно меняется индуктивность.

Какой там скутер!? У нас мужик лифты поднимал с BLDC в асинхронном! режиме. Чуть в серию не пошло. Хотел сэкономить на холлах. Типичное желание начинающих.

Ща начнется буря в стакане. Желающие могут объяснять другими терминами, но суть не поменяется.

BLDC могут крутиться в синхронном и асинхронном режиме. И правильнее было бы их назвать моторами для синхронного управления, а не синхронными. В асинхронном режиме как раз дерганья и наблюдаются. Но если мотор с большой инерцией и с очень маленьким моментом на валу, то асинхронное вращение почти не отличимо от синхронного.

Как раз с такими работаем На 87 Гц они чувствуют себя лучше всего. Производители даже рекомендуют нам переходить на 87 Гц, так как это оптимальней по энергозатратам.

Я разгонял до 400 Гц на не более чем на 1 сек. Там виден снятый ремень. На 400 Гц мотор не мог даже прокрутить этот ремень со шкивом без всякой нагрузки. Т.е. момент силы падает катастрофически. Также не забывайте об электрической эрозии подшипников и идеальной балансировке. Подшипники придется делать керамическими.

Да, при десериализации происходит перенос данных из динамического дерева JSON в статические переменные. Мог бы и не делать этого, jansson предоставляет удобное API для извлечения значений параметров по путям и именам в своем дереве построенном в динамической памяти. Но у меня приложения с жестким риалтаймом во-первых , а во-вторых есть некоторое количество других независимых сервисов работы с параметрами. В частности теми же параметрами можно управлять через SNMP и MIB базу, через WEB и HTML страницы, через встроенный FTP и файлы, через USB MSD, через Telnet и VT100 терминал, через движок FreeMASTER и MATLAB, через GATT базу Bluetooth и т.д. И все это требует отдельных мапингов. (т.е. механизмов отображения данных в структуры разных протоколов) и простыми макросами не отделаться. Поэтому у меня отдельная утилита автогенерации исходников с мапингом параметров под разные протоколы. .

Использовал разные, но остановился на https://jansson.readthedocs.io/en/latest/apiref.html JSON используется у меня только для сериализации и десериализации. Сами параметры после десериализации из JSON хранятся в виде переменных в разных местах и модулях. Они могут быть как статические, так и динамические. Сериализатор имеет доступ к переменным через массив связывающий имена переменных и указатели на них. Можно, но сжатие будет хуже. Эт как пытаться сжать текст после шифрования. Он просто не сожмется. С другой стороны применив просто другую схему кодирования в JSON (скажем массивы вместо именованных объектов) и без форматирования размер будет близок к BSON.

Лучше для чего? Для связи с MongoDB? Скажем мой файл настроек JSON размером в 44 Кб в BSON кодировке будет иметь размер 34 кБ, А после моего алгоритма сжатия тот же JSON имеет размер 5 кБ! Кстати, хранение настроек в именованных структурах в памяти избавляет от необходимости проверки версий и применения конвертеров.

Для этого настройки храняться в виде сериализованных именованных структур в файлах. Лучше всего подходит JSON формат. Если в EEPROM мало места, то JSON сжимают. У всех настроек уникальные имена, в простейшем случае - номера. Но лучше иметь кроме имен еще и алиасы. Линейные файловые системы помещаются в EEPROM любого размера, кроме этого обеспечат wear leveling.