amaora

Оставьте в цикле только работу с fatfs, остальное перенесите в обработчики прерываний (сами решайте каких, хотя бы и по таймеру). Это самый простой способ.

А я смотрю со стороны того, что имеем сейчас step-down сделанный на LM46001 по схеме из ДШ (500 кГц, 22 мкГ), который делает 5в из диапазона 5-50в, то есть коэффициент 10:1. Он нормально работает и от 5в и от 55в, и это бывает полезно в некоторых применениях. Не понимаю, какие преимущества даёт несколько вариантов исполнения на разные входные напряжения? Почему версия рассчитанная на максимальное входное не может работать от нижнего предела с заполнением близким к 100%? Да, сильно прижиматься к 12в не нужно, бортсеть не предполагается. Допускаю возможность ограничиться диапазоном 48-200в для случая flyback или других топологий с трансформатором, но по ним я ещё не понял ничего.

Нет, не кабель, это источник питания для контроллера BLDC, первичный источник - аккумулятор (наиболее вероятные варианты от 48в до 120в).

Сейчас использую LM46001 для того чтобы сделать 5в ~1А из 5-50в. Можно найти несколько вариантов замены на 100в входного (LM5116, MP9486, ...), но оказывается нужно до 200в. Ввязываться в разработку источника желания нет, хочется взять готовое и надёжное. С изолированными топологиями не работал, не знаю особенностей. 1) Вход: 12-200в (нижнюю границу можно подвигать, чтобы не усложнять преобразователь, изоляция не требуется); 2) Выход: 12в +/- 0.5в ~1А; 3) Обойтись без выводных и высоких компонентов, трансформатор плохо вписывается; 4) Проще лучше, не хотелось бы выдумывать схему из низковольтного step-down контроллера + стартового линейного регулятора + драйвера + транзисторов. Что можно сделать? Или лучше смотреть flyback?

По моим наблюдениям, чаще всего на высоких dv/dt по ёмкостной связи проходят эти импульсы в сигнальные цепи, нарисуйте паразитные конденсаторы на схеме. По измерениям использую "пружинку" заземления на щупе и отдельное (изолированное) питание осциллографа либо исследуемого устройства.

Отдельный пул свободный блоков под каждый размер. Можно заранее их аллоцировать через malloc (когда блоки мелкие и важна локальность), а можно по мере работы пополнять пул, вместо того чтобы делать free. Когда надо alloc, то соответственно смотрим в пуле, если там пусто то уже делаем malloc.

Не знаю есть ли подобное в GCC, если бы это позволило бы навязать ramfunc атрибут (сделать копию) всем используемым в функции символам, возможно было бы удобно. Но в любом случае компилятор не сможет гарантировать отсутсвие обращений к flash.

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

Репозиторий 1 под схемы-платы-чертежы, репозиторий 2 для кода. В первом проставлются теги (метки ревизий) соответствующие версиям ушедшим в производство, так чтобы всегда можно было найти схему-плату-чертеж для конкретного изделия. Во втором ведётся обычная разработка софта, привязки к железу на уровне контроля версий нет, вместо этого внутри самого софта есть варианты конфигураций, сборка под разные ревизии платы. Так лучше, проще собирать свежие версии софта под старые ревизии железа. Документация живёт вместе с софтом но пока у меня все плохо с ней.

ready_flag это на одном уровне кода (про который говорим), а работа с регистрами на другом (там volatile почти всегда к месту), не надо все в одно мешать. Сделаете тогда может быть все объявления типов с volatile? С флажком самый простой пример, чтобы показать что без и volatile можно сделать то же самое, причём часто все fence() уже есть в коде. Множественные ненужные чтения получаются когда volatile прилепляют ко всему, по методике "если доступ из разных потоков то надо volatile". Вот это я и считаю неверным, а не само использование volatile.

Так они там и есть, это же работа с регистрами IO чтобы включить событие. А даже если нет, то ещё один fence() так же можно поставить (если им и без того не является сам req_new_event), чтобы запись 0 не перенеслась. Это слово не вполне выражает то, что хотят им сказать в задачах синхронизации. В некоторых случаях порождает лишний код множественной записи-чтения там где этого не нужно.

В цикле в main есть fence() или, что более естественно там есть некий os_wait() которые даёт аналогичный результат. Для компилятора вызов os_wait() имеет побочный эффект, а значит от должен сделать все записи глобальных переменных до вызова и прочитать все снова после него. Всегда так делаю. Надо только помнить, что если при компиляции включена LTO, то компилятор может очень глубоко (до дна) заглянуть в os_wait() и сделать какие-то выводы. Лучше заранее убедиться, что там внутри есть аналог fence(), какой-то inline asm с указанием на изменение памяти, например. Либо это отдельный модуль компиляции.

В простом случае, когда достаточно барьера компилятора (процессор не может менять порядок записи в память), fence() ничего не будет делать, ни одной инструкции не будет сгенерировано, это только указание компилятору. Хотя есть вариант и с пустой функцией из отдельного модуля компиляции, если LTO не включена. Событие подразумевалось разовое, повторный вызов обработчика будет только если снова настроить событие вызвав req_new_event(). Можно и FIFO сделать в конфигурации 1-читатель 1-писатель, для этого будет достаточно операции атомарной записи int и fence(). В SMP системе fence() будет содержать инструкции барьера, чтобы остальные процессоры увидели изменения в заданном порядке.

А я правильно понимаю, что трехфазный ККМ это тот же контроллер двигателя только подключенный фазами к сети и работающий на стабилизацию напряжения звена постоянного тока? Не могу ничего найти по словам "PFC vector control".

Обычная синхронизация на флажках, все так же только не надо volatile. int ready_flag; // no volatile, only atomic read/write event_handler() { read(data); memcpy(buf, data, ...); fence(); ready_flag = 1; } main() { do { if (ready_flag == 1) { do_something(buf); ready_flag = 0; req_new_event(&event_handler); } // ... //fence(); os_wait(1); // it has memory fence inside } while (1); }