amaora

1) Например я не придумал куда приложить эту аналоговую периферию, удобнее получается на внешнее рассыпухе сделать, а от МК мне надо побольше флопсов; 2) Сейчас есть новые G4; 3) Алиэкспресс это какой-то сомнительный показатель.

В приоритете целостность управляющих сигналов от МК на драйверы. То есть, в вашем случае земля МК идет с драйверов. Информационные интерфейсы изолируйте, делайте дифференциальными, по необходимости.

Может быть тогда перекладывать данные в регистры GPIO через DMA по событию таймера?

Имеющийся упомянут к тому, что рассматривается возможность добавить "накопитель" к нему. Повышенный ток нужен только 2-3 сек с последующим отдыхом около 30 сек. Новый аккумулятор проще да, но это будет избыточная ёмкость и масса/габариты.

Забыл важную деталь, что источник должен быть автономный. А по массе/габаритам предел - четыре автомобильных кислотных акб. Это только для экспериментов под моим контролем. Рассматривал батарею ионисторов в параллельном включении. 20-24 банок EDLC по 500Ф. Если упрощенно считать, 100А с конденсаторов и 100А с основной акб. По ёмкости получается можно выдержать 2 сек до просадки на 10в. Но если учесть внутреннее сопротивление (без учёта монтажа и проводов), то конденсаторы просядут на 9в сразу же на старте. Без преобразователя нужно очень невыгодно наращивать ёмкость и снижать ESR.

Есть аккумулятор 48в способный отдавать 80А с просадкой напряжения не более 10в. Мне необходим источник способный давать ток около 200А в течение 2-3 сек минимум. Какие есть способы накопления энергии аккумулятора и последующей отдачи в нагрузку за указанное короткое время? Это разовая задача, для экспериментов с электроприводом. В приоритете дешевое и простое решение. 1) Новый аккумулятор (дорого и он не нужен); 2) Батарея ионисторов и DC/DC (сомнительно и сложно, и дорого тоже); 3) Раскручивать маховик (опасно и нет готовой механики, дорого); 4) ??? Спасибо.

Предпочёл бы вместо явной работы с этой древовидной структурой решать задачу пробросом интерфейсов. У себя например сделал вход в CLI удалённого узла, а если тот имеет доступ к каким-то slave-ам (по другоим интерфейсам или через другую сеть CAN) то можно зайти в их CLI. Матрёшка из транспортных протоколов, а интерфейс через сеть получается такой же как если устройство подключено локально по USB или UART. Сам "network discovery" у меня сильно похож на то, что описывал jcxz, и работа остальных протоколов так же происходит независимо. Есть некоторые особенности как именно новые устройства должны отвечать на запрос энумерации, у которых ещё не назначены короткие идентификаторы позволяющие задействовать арбитраж.

В частности, не хотелось составлять список обработчиков команд и регистрировать их на старте, как это обычно все делают. У меня команды разбросаны по всему проекту, помечены с помощью макросов, что это обработчик CLI, а таблица собирается python-скриптом на этапе сборки. Ну и это не такая сложная задача, чтобы не делать велосипед, посмотрел сейчас, у меня около 600 строк (как упомянутый tinycli). Но у вас в требованиях скрипты, это существенно усложняет задачу. Надо искать не библиотеку командной строки а в первую очередь интерпретатор какого-то языка влезающий по ресурсам.

У меня свой простенький shell, с редактированием, историей и автодополнением названий команд, без скриптов. Библиотечку готовую не подобрал.

ФС это слой абстракции для хранения данных, не обязательно она должна быть распространённой и с чем-то совместимой. На верхний уровень даёт работу с непрерывными блоками данных (файлами) а на нижнем уровне разбирается с конкретным носителем, куда записать новые данные, как потом их читать, когда и как стирать секторы flash, делать выравнивание износа и т.д. Требования к ФС в разных случаях разные, бывают примитивные, но это все равно можно назвать ФС.

Можно использовать то, что число x меняется не слишком быстро и находить обратное q=1/x каким-нибудь итерационным численным методом (метод Ньютона?) взяв за начальное приближение предыдущее значение q. Если значение x поменяется быстро, то находить начальное приближение подсчётом ведущих нулей, или искусственно ограничить его быстрое изменение.

У меня есть вычисление тензора импеданса и далее индуктивностей в собственных DQ осях на переменном токе частотой порядка 1-3 кГц. Побочно там оценивается и активная составляющая, но это не то, что нужно. Относительно замера на постоянном токе эта оценка обычно сильно завышена т.к. включает в себя и магнитные потери. А погрешность на постоянном токе возникает от неопределённости напряжения во время DeadTime. Влияние пульсации тока от ШИМ не надо учитывать, ведь оценка Rs делается для того чтобы использовать это значение в обычном режиме работы двигатель/генератор, где так же используется ШИМ. Пока не везде есть возможность компенсировать DeadTime путём измерения фазных напряжений через RC фильтры подходящих номиналов.

UB с псевдонимами появляется когда через один тип записали а через другой прочитали (компилятор может решить не читать повторно а взять прочитанное ранее из регистра, или отложить запись на потом). В вашем коде type похоже будет константой времени жизни объекта с доступом через тип u32, а остальные поля структуры предназначены для работы только через свой тип, поэтому все нормально. Если так уж страшно, то можно использовать union из структур. Такое видел например в SDL.

Раньше применял ACS7**, потом перешёл на шунты и усилители AD8418 или INA240, только у меня частота в 10 раз меньше.

INA241

Может быть ещё, что вращение не равномерное. Увеличить момент инерции не пробовали? Вращать внешним независимым приводом?

Это же надо магниты неравномерно клеить? Датчики Холла рядом с обмотками на статоре? Или отдельная магнитная система для датчиков? 1) Когда датчики в обмотках, надо ещё анализировать как это будет работать на максимальном токе, паттерн может поменяться; 2) Стабильность на разной температуре и от старения; 3) Если магниты неравномерно расположены, то не будет ли видно эту нерегулярность по токам и напряжениям? А если добавить неравномерность количества витков на разных зубцах статора? 😁

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

Сайд-эффектом помечен барьер, все до чего "законно" без UB может дотянуться функция с неизвестной при компиляции реализацией (аналог барьера), не может быть переставлено вокруг барьера. Поэтому value запишется до барьера. Ну либо не запишется нигде, но я не уверен, что компиляторы могут это надёжно вывести. https://godbolt.org/z/rP4W4Eq19 Не похоже на барьер памяти, надо читать всю документацию чтобы понять.

Барьер компилятора это функция которая потенциально может читать и писать память, поэтому компилятор не может выбросить записи в память до барьера и использовать кэшированные в регистрах значения после барьера. Если value не используется и включена LTO, то наверно единственную запись в value можно выбросить и это будет корректно.

volatile это для IO регистров, чтобы если сказали 10 раз запиши константу по этому адресу, то компилятор так и сделал. А для синхронизации это избыточно и не совсем то, более уместно использовать барьеры гарантирующие необходимый порядок операций с памятью. Например для CM4 барьер это: - инструкция (DMB) обеспечивающая порядок на аппаратном уровне; - указание компилятору ("memory"). __STATIC_FORCEINLINE void __DMB(void) { __ASM volatile ("dmb 0xF":::"memory"); } Для IO области памяти упорядочивание обычно предусмотрено аппаратно без барьеров, но для флажка в SRAM это может быть важно (наверно возможны варианты с настрйоками MPU и кэширования).

Тогда сравните приоритет задачи таймеров (configTIMER_TASK_PRIORITY) и приоритет своей задачи с циклом.

Таймеры же из какой-то одной задачи обрабатываются во FreeRTOS если правильно помню. Ничего удивительного, что все обработчики останавливаются если в одном безвыходный цикл. https://www.freertos.org/RTOS-software-timer.html

Указывать компилятору когда загружать значение в регистр относительно строк исходного кода? Это некорректная постановка вопроса, компиляторы так не работают.

В отдельную .noinit секцию, которая никак не обрабатывается в startup коде.