Комментарии 28
Т.к., например, на немецком, архитектура часто применительно к конкретной практической области рассматривается.
Ну, и англоязычная литература широка и глубока. :)
… требующие и не требующие многозадачности. Что касается решений первого типа, они, как правило, не очень сложные...
Может поменять местами?
Cоздаем массив, например такой:
int16_t rtdb[5];Но работаем с ним только через функции, например так:
void write_rtdb(int16_t* data)
{
if(xSemaphoreTake(mutex_name, (TickType_t)portMAX_DELAY))
{
for(uint8_t i = 0; i < 5; i++)
{
rtdb[i] = data[i];
}
xSemaphoreGive(mutex_name);
}
}Пара моментов:
— в примере, для синхронизации доступа используется мьютекс из FreeRTOS;
— функция чтения тоже должна использовать тот же мьютекс;
— работу с данными можно сделать более оптимально, если это критично.
habr.com/post/308532
Говоря о подходе, я имею ввиду выбор в пользу использование ОС на STM32 и других Cortex. Использование ОС может быть оправдано, когда количество задач переваливает за несколько сотен. И я тут говорю о более менее алгоритмически объемных задачах, а не просто записать какую-либо настройку в регистр.
Мне сложно представить проект, где использование той же FreeRTOS обеспечит реальное преимущество в скорости и тайминге, конечно при условии должного знания архитектуры используемого процессора, языка программирования (в том числе и ассемблера) и уровне оптимизации -O3. Зато повсеместно встречаются обратные примеры, когда вся многозадачность, к примеру, заключается лишь в считывании входов (цифра), выдаче результата на выходы и передаче по какому нибудь интерфейсу, с навешанными OS и HAL, конечно же без оптимизации как таковой.
Например, в статье описано, что на изменение состояния кнопки нужно реагировать максимально быстро. А это сколько? Даже запихнув все задачи из статьи последовательно в while(1) общее время выполнения цикла едва ли превысит несколько миллисекунд, это много меньше времени механического нажатия. На кнопку же, если это принципиально, можно просто поставить EXTI да и все.
По базе данных реального времени. Я бы просто выделил структуру/массив, а все возможные перемещения данных повесил бы на DMA, и думать о перемещении, распределении, достоверности и целостности не приходится вообще.
Основное заявляемое преимущество RTOS в том, что она может выполнять задачи строго нужное время по приоритетам. Но с ней код разбухает (имею ввиду количество машинных инструкций), и это теряет смысл, так как грамотно написав код напрямую, можно добиться гораздо лучших результатов вообще об этом не думая учитывая что перечисленные задачи в статье не имеют строгой привязки ко времени. Также не стоит забывать, что команды безусловных и условных переходов нарушают конвейерность процессора fetch/decrypt/execute, что при каждом вызове задачи и куче добавочных переходов в целом, превращает один такт в три.
В общем, я считаю что гораздо профитнее курить саму архитектуру процессора и научиться грамотно использовать ее фичи. Это принесет и другие плюсы, разработка любой неизвестной ранее периферии будет все проще и быстрее, а также, вопреки расхожему мнению, будет легко перебраться, например, с STM на LPC или Infenion.
И замечу, что я не против ОС вообще и на серьезных проектов использование ее рационально, но серьезные проекты требуют настоящих процессоров, а 99.9% того, что реализуют на МК Cortex Mx даже профессиональные разработчики, совсем не подходит под это и в частности приведенном в статье примере я не вижу оснований для использования ОС.
Использование ОС может быть оправдано, когда количество задач переваливает за несколько сотен.
Co FreeRTOS так точно не получится — на каждую задачу требуется относительно много ресурсов. Я бы сказал, что RTOS рулит там, где есть какие-то долгие и сложные расчёты, которые нужно прозрачно прерывать более короткими и более приоритетными задачами.
Написать код без RTOS, который бы учитывал приоритетность задач, синхронизировал доступ к ресурсам и т.п. можно, но это требует большего профессионализма, нежели, чем использование возможностей, предоставляемых RTOS. Конечно – это не причина, чтобы останавливаться в развитии! Но на определенном этапе может быть вынужденной необходимостью. Вряд ли с первого раза получится сделать «хорошо» без соответствующего опыта.
По части ресурсов, насколько я понимаю, та же FreeRTOS не сильно прожорливая, планировщик, если верить статьям занимает порядка 250 байт в ОЗУ, задача — 64 байта плюс ее стэк. К тому же, мы получаем дополнительные плюшки, опять-таки, если верить интернет источникам (сам не проверял), например, работа с динамическим выделением памяти (malloc, free и т.п.): для ряда МК может вообще отсутствовать, либо быть очень громоздкой, в FreeRTOS есть функции (pvPortMalloc(),vPortFree()), которые позволяют это делать эффективно (но, как уже сказал выше, не тестировал этот момент).
Если решить задачу можно без RTOS и это будет приемлемо по срокам, сложности, требованиям по масштабируемости и времени реакции, то выбор будет в пользу этого решения.
В том и суть, что распространено мнение, что FreeRTOS и ей подобные системы делают построение архитектуры системы удобнее, быстрее и проще. Но если потратить столько же времени на освоение архитектуры МК, то разница будет несущественной.
Написать код без RTOS, который бы учитывал приоритетность задач, синхронизировал доступ к ресурсам и т.п. можно, но это требует большего профессионализма, нежели, чем использование возможностей, предоставляемых RTOS
Я не совсем понимаю вопрос по приоритетам. А какой смысл в вашем примере учитывать приоритет задач. Что поменяется, если при нажатии кнопки вы потратите, допустим 5 миллисекунд на уже выполняемые задачи и затем по очереди попадете в обработку кнопки?
Но на определенном этапе может быть вынужденной необходимостью. Вряд ли с первого раза получится сделать «хорошо» без соответствующего опыта.
Я тоже думаю, что с первого раза не получится сделать так. Но если же не начать так делать, то никогда не получится.
По части ресурсов, насколько я понимаю, та же FreeRTOS не сильно прожорливая, планировщик, если верить статьям занимает порядка 250 байт в ОЗУ, задача — 64 байта плюс ее стэк.
По поводу прожорливости по памяти, я сделал такой вывод, так как все проекты, что мне попадали с OS были раз как минимум раз в 15-20 больше по объему памяти. Если то, что вы написали правда, то это действительно пустяки, и этот минус я для себя снял, спасибо.
мьютексов, семафоров, очередей, и обеспечивать быструю работу с динамической памятью
Только дело в том, что это все понятия более высокого уровня абстракции, к реальному МК отношение не имеющие и придуманные человеком для решения определенных задач.
Возможно, если просто посмотреть на МК под углом того, что там есть хардварно, то может и окажется, что вашей системе, как и подавляющему большинству, это совершенно не требуется.
количество задач переваливает за несколько сотен
Полно вам, это же мегабайты оперативки нужны только на стеки, у микроконтроллеров редко бывает столько. И где может быть задача контроля "сотен алгоритмических процессов", которых нельзя кинуть на рабочую очередь?
ОС может быть оправдано, когда
ОС оправдана, когда мы хотим развязать отдельные модули устройства, не превращая его в запутанный клубок.
о перемещении, распределении, достоверности и целостности не приходится вообще.
Если у вас не атомарная запись/чтение величин, то думать придется. Видите ли, даже голый МК с прерываниями — уже не "однопоточная" система. Голый МК без прерываний тоже может быть не однопоточной системой, поскольку периферия тоже умеет делать что-то сама по себе.
с ней код разбухает
Код вообще разбухает с повышением сложности ПО. От кооперативной многозадачности, которую часто ставят как альтернативу вытесняющей — код разбухает не меньше, а на некоторых архитектурах изобилие ветвлений (switch/case) убивает всю производительность на корню.
перечисленные задачи в статье не имеют строгой привязки ко времени
Потому что 90% статей по ембедедду рассматривают совершенно неправдивые примеры. RTOS применяют когда у нас есть несколько классов задач, выполнение которых явно важнее других задач. Грубо говоря, "RTOS" можно сделать на контроллере прерываний (NVIC), с включенным вытеснением прерываний. Но программная обертка над планировщиком будет поудобнее, нежели ручной контроль приоритетов и порядка выполнения.
безусловных и условных переходов нарушают конвейерность процессора fetch/decrypt/execute
Это говорит лишь о том, что желательно просто снижать частоту поступающих на CPU событий. Использование/неиспользование RTOS тут ничего не решает. Опять же, никто не заставляет на каждый чих заводить по отдельному потоку.
гораздо профитнее курить саму архитектуру процессора и научиться грамотно использовать ее фичи
Счастливые разработчики, которым не приходится вникать в архитектуру процессора и системы, в которой они работают. Я таких среди своих коллег не знаю.
будет легко перебраться, например, с STM на LPC или Infenion.
С Cortex M3 на Cortex M3 — это не "перелазить". Но даже при смене вендора внезапно оказывается, что периферия порой кардинально отличается (а в случае с ST, так и между сериями), так что процесс ее изучения начинается с начала.
совсем не подходит под это
Мы забыли отдельный класс RTOS — операционки с собственными сетевыми стеками/драйверами/POSIX-совместимыми. Внезапно позволяют переносить добрую часть кода между процессорами в случае модернизации. Но FreeRTOS не из этой серии, это просто планировщик
Полно вам, это же мегабайты оперативки нужны только на стеки, у микроконтроллеров редко бывает столько. И где может быть задача контроля «сотен алгоритмических процессов», которых нельзя кинуть на рабочую очередь?
Я и написал в последнем абзаце, что такие задачи на МК обычно не решаются.
ОС оправдана, когда мы хотим развязать отдельные модули устройства, не превращая его в запутанный клубок.
И при чем тут ОС? Никто не мешает НЕ делать запутанный клубок и без нее, ОС — НЕ панацея.
Если у вас не атомарная запись/чтение величин, то думать придется. Видите ли, даже голый МК с прерываниями — уже не «однопоточная» система. Голый МК без прерываний тоже может быть не однопоточной системой, поскольку периферия тоже умеет делать что-то сама по себе.
Есть понятие о том, что такое DMA и как именно оно работает? Понимае того, как именно чтение и запись раскладываются на ассемблере на Cortex, и что реально происходит в МК при прерывании? Осведомленность о «внутреядерной» возможности битовых масок практически для всей используемой периферии и SRAM? Это все к тому, что замечание не к месту, без понимаю сути процессов обсуждать нету смысла.
Потому что 90% статей по ембедедду рассматривают совершенно неправдивые примеры. RTOS применяют когда у нас есть несколько классов задач, выполнение которых явно важнее других задач. Грубо говоря, «RTOS» можно сделать на контроллере прерываний (NVIC), с включенным вытеснением прерываний. Но программная обертка над планировщиком будет поудобнее, нежели ручной контроль приоритетов и порядка выполнения.
Вот тут плюс. Тоже хотел бы посмотреть на реальную систему подобного рода, в которой RTOS реально спаситель, а не просто прихоть программиста.
Это говорит лишь о том, что желательно просто снижать частоту поступающих на CPU событий. Использование/неиспользование RTOS тут ничего не решает. Опять же, никто не заставляет на каждый чих заводить по отдельному потоку.
Тоже, что и вопросе про атомарность, переходы используются далеко не только в потоках, когда будет понимание того, как часто они используются- вопрос сам отпадет.
Счастливые разработчики, которым не приходится вникать в архитектуру процессора и системы, в которой они работают. Я таких среди своих коллег не знаю.
Вопрос в уровне «вкуривания». Я не говорю, что нужно задротить абсолютно любую мелочь, но когда ты знаешь все реальные процессы, происходящие в твоем МК, разрабатывать ПО становиться много легче.
Но даже при смене вендора внезапно оказывается, что периферия порой кардинально отличается (а в случае с ST, так и между сериями), так что процесс ее изучения начинается с начала.
А вот и нет. Контроллеры очень похожи между собой, в т.ч. и разные ядра(даже на просто си именно ядро ты вообще почти не видишь). Отлично зная одно, без труда освоишь и другое. Также, когда постоянно копаешься в даташитах, найти что-то нужное в новом — легко. и еще, После STM32f2xx структура периферии устоялась, например, перетаскивая CAN1&2 и USB, я просто скопировал модули и получил рабочую систему…
С Cortex M3 на Cortex M3 — это не «перелазить».
И ради чего это придирка? Я такого и не писал. Могу также ответить: Если для тебя это новость, то даже у STM32 ядро не только CORTEX-M3.
Пример:
-Есть асинхронные задачи, требующие реакции в пределах, допустим, 10 мкс.
-В системе есть атомарные функции (условно «потоки»), занимающие более 10 мкс.
При таком раскладе просто необходимо делать вытеснение и переключение контекстов, требуется реалтайм-планировщик.
Если же системе достаточно реакции в 1 мс, и при этом в ней 10 «потоков», любой из которых выполняется менее чем за 100 мкс — нет никакого смысла городить планировщик из FreeRTOS. Вполне достаточно в основном цикле просто «ездить» по кольцу своих задач.
Для разработчика знать ОСРВ и уметь ей пользоваться — несомненный плюс.
Но не нужно это применять, только чтобы помигать светодиодом.
Прежде чем разрабатывать архитектуру встроенного приложения ответьте себе на простой вопрос — в вашем описании приложения нигде не написано, что оно должно работать в реальном времени. Так какого вы применяете ОСРВ и даже рассказываете про какие-то базы данных реального времени? Только потому, что "реальное время" — это модно? И раз эмбеддед, то обязательно real-time хардкор?
Вы, похоже, даже не понимаете, что такое работа в реальном времени и чем простое встроенное приложение отличается от такого же, но работающего в реальном времени.
А минус за что?
Определитесь для начала насчет ваших задач:
Поставим задачу более четко, пусть в рамках нашего приложения необходимо:
- Считывать данные с датчиков на шине RS-485/Modbus.
- Считывать данные с датчиков на шине I2C.
- Считывать данные с дискретных входов.
- Управлять релейным выходом.
- Обслуживать пользовательский интерфейс (дисплей + клавиатура).
- Предоставлять доступ к данным по шине RS-485/Modbus.
- Сохранять данные на внешний носитель.
Какие из этих задач должны выполняться в реальном времени, а какие — нет и допустим ли для задач реального времени жесткий или мягкий реалтайм? И почему — по каким критериям вы отнесли каждую задачу к тому или иному виду выполнения — периодичность, дедлайны, латентность отклика на события?
У вас, кстати, написано, что приложение управляющее, а сама управляющая задача в списке не представлена.
Ну а потом уже рассуждайте об архитектуре.
Если у вас есть информация об ОС для МК, которая позволяет решать вопросы синхронизации, работы с приоритетами задач, предоставлять возможность использования мьютексов, семафоров, очередей,
Если у вас есть потребность в данной функциональности, то значит у вас есть задачи, требующие реального времени, только вы о них не знаете или не пишите. Поэтому я советую еще раз подумать об этом — требуют у вас задачи реального времени или нет.
Например, "предоставлять доступ к данным по шине RS-485/Modbus" — если ваше устройство является "слейвом", то у вас сразу появляется непременное требование реального времени — вы должны быть способны принимать сообщения от мастера в любой момент времени, обрабатывать принятые команды в течении установленного Modbus стандартом времени и выдать ответное сообщение согласно стандарту и все это независимо от того, чем еще в данный момент занимается ваше устройство.
А вот например "Сохранять данные на внешний носитель" — какая там разница, будет это сделано за 10мс или 300мс, правда? Т.е. тут выполнение в реальном времени не требуется.
Определитесь с другими задачами также. Вы тогда не только узнаете зачем вам ОСРВ (ну и зачем в МК только ОСРВ и применяют), но и получите более важный результат — избежите ошибок в проектировании архитектуры своего встраиваемого устройства, которые потом могут принести много проблем и сопутствующего переписывания всей программы.
Публикации
Проектирование архитектуры embedded-приложения