Не знаю и не слышал о гениях, реализующих motor control loop вне
прерывания (высокоприоритетного, которое прерывало бы участки
критического кода, т.к. из моторного прерывания сервисы RTOS не
вызываются). Так что синего дыма по определению быть не может. Я не проектировал системы жёсткого реального времени, где требуется быстрая АСИНХРОННАЯ реакция. Не было необходимости. Не было таких систем.
То же векторное управление ЭД: при частоте ШИМ 20..100 кГц и управляющем цикле с такой же частотой стоит ли быстрее чем 10..50 мкс реагировать на сигнал ~FAULT от драйвера мотора, если он уже сам всё сделал (отключил силовые ключи)?
Мой подход к проектированию достаточно стандартный: измерение - управляющий цикл - применение воздействий - ожидание следующего системного тика. И где тут нужна RTOS? "Измерители" подготавливают данные в ОЗУ либо по DMA либо копируя их из IP блоков в IRQ.
RTOS, по моему убеждению, нужна только при использовании сторонних библитек (USB, Ethernet, FS), или в приложениях, требующих микросекундных реакций (хотя именно в этом случае можно спроектировать более понятную и лёгкую в поддерживании систему и без RTOS).
Последний десяток лет я стараюсь не использовать RTOS там, где они не нужны. Легче сопровождать ПО и доказывать FDA & Co что оно работает как запроектировано (потому что нет стороннего кода).
Вот тут человек, применяя современный C++, тоже пытается ускорить embedded проекты https://codernet.ru/books/c_plus/real-time_c_2nd_edition/
VVB (02.09.2024 08:34, просмотров: 123) ответил klen на riscv32imAc: попробывал использовать атомарные инструкции для реализации
спинлока ради изучения - интересно и почти понятно :) вроде
работает. может кому будет интересно.