amaora

Оба куска склеиваются вместе в один образ и объявляются константы содержащие размеры и адреса, чтобы можно было этот образ разделить и загрузить куда надо. Смотрите как работает загрузка .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); }

Где он обязателен так это регистры IO в которые необходимо несколько раз записать/прочитать так чтобы компилятор это не оптимизировал до одной операции. Для синхронизации может понадобится атомарность и заданный порядок записи, чего volatile не обеспечивает. А чтобы заставить компилятор прочитать значение глобальной переменной снова, а не кэшировать в регистрах, достаточно вызвать функцию имеющую side effect. Обычно это и так уже происходит если во время поллинга флага периодически отдавать управление ОС.

Сделать ещё одну API функцию для проверки флага, внутри использовать volatile.

В вытесняющей ОС надо функцию делать блокирующей, если нет вытеснения то event-driven и callback. А флажок поллить, этот как-то неуклюже выглядит. Впрочем, бывает и так удобно где-то. По поводу volatile, это будет иметь значение только при проверке, то есть достаточно в коде где будет цикл ожидания ее объявлять volatile. Можно даже приводить тип в том выражении где происходит проверка. while(* (volatile sI2CSOp *) &sop.sop != I2CSOP_PROC);

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

Про DD моторы от самокатов 250 Вт. У них подходящий Kv, при скорости 500 об./мин. будет ЭДС около ~30в, то есть редуктор не нужен. Но обратите внимание на магнитные потери (в железе статора, вихревые во всех проводниках, все суммарно) около ~10-30 Вт при номинальной скорости. Потери на сопротивлении обмоток статора ничтожны для требуемой мощности на такой скорости. Поэтому оптимальный по КПД режим будет ниже 500 об./мин.. Так же массогабариты у таких DD не лучшие, вес около 3 кг.

Может переключение слишком быстрое и сквозит через Qrr.

Это на простом уровне. Сложности начинаются когда надо срастить FW с ограничением мощности и с MTPA и чтобы подстраивалось под температурный дрейф параметров двигателя.