ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
19 апреля
1012818 Топик полностью
fk0, легенда (18.06.2020 11:00, просмотров: 1077) ответил RxTx на Есть мысль перейти на RTOS для снижения временных затрат на реализацию программной части, отладку и профилировку. Важна поддержка со стороны хоста (PC,IDE) чтобы видеть времянки, логи, состояние. Какие используете RTOS? Есть ли опыт применения ThreadX? Какие RTOS можно выделить в качестве ключевых?
Ага. А с чего будет снижение затрат-то? На борьбу с ОСью не будет не потрачено ничего, особенно на синхронизацию? В одном большом проекте половина багов -- синхронизация (дедлоки, data race и т.п.) А у тебя Valgrind (DRD, Hellgrind) не будет. Ты ж про "синтетический порт" на ПК и слышать небось не хочешь. Мол одной левой и так отладим. Основной функцией ОС является распрделение ресурсов вычислительной системы. И она нужна, если ты это руками сделать не можешь. И в 

частности, распределение памяти, и распределение процессорного времении. Вытесняющая ОС -- преимущественно способ запустить параллельно независимые задачи и повысить время реакции системы (потому, что можно быстренько вытеснить и переключиться на поток способный быстро обслужить данный конкретный сигнал). Способ распределить процессорное время для организации длительных вычислений, например, которые самостоятельно прерываться не умеют. В задачах логического управления, когда их много, они параллельны и все взаимосвязаны RTOS поможет мало. Т.к. синхронизация между задачами станет исключительно сложной. Пример: практически все GUI системы можно сказать являются задачей логического управления. И практически все -- однопоточные, работают в какой-либо событийно-ориентированной системе. Многопоточных нет, потому, что задача синхронизации станет практически не разрешимой. Все события обрабатываются строго синхронно.


И наконец зачем тебе чей-то чужой опыт. Я офигеваю от вопрос "а кто-нибудь так делал?" А если тебе ответят, мол, мы так не делаем и не будем -- и ты не будешь?


Практически в рамках любой RTOS у тебя в отдельные задачи ты сможешь выделить относительно независимые процессы. Основная часть у тебя будет исполняться в некотором главном потоке, скорей в котором будет очередь событий, события из которой, предназначенные совершенно разным подсистемам, ты будешь обрабатывать в цикле. По сути основной цикл управления останется однопоточным. И скорей у тебя появится такая сущность как "планировщик" (не путать с планировщиком уровня ОС), который позволит отправлять события в очередь в наперёд заданное время, или вызывать обработчики в заданное время, между циклами чтения очереди событий, это не важно. Сам факт, что появится некоторая однопоточная система обработки событий предназначенная для использования всеми компонентами системы. В которой будет крутиться основная логика. А дискретные и относительно изолированные задачи могут крутиться в отдельных потоках.

Фактически грубый аналог libevent. И по-другому ты никак не сделаешь, иначе зашьёшься. Это только в демках одна задача мигает одним диодом, а другя другим. Как до дела дойдёт, так не выйдет, потому, что нужно взаимодействие задач и чем оно сложней, тем сложней их синхронизация с одной стороны, с другой дробить на очень маленькие задачи тоже не получится, т.к. место в стеке и число задач у тебя очень ограниченным окажется. Ну и удобство отладки -- СИЛЬНО СЛОЖНЕЙ. Потому, что появится широкий класс багов, с которыми ты ранее не сталкивался.

[ZX]