Зачем мне использовать RTOS для моего встроенного проекта?

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

• Оценить монотонный анализ (RMA) - если вы хотите использовать Оценить монотонный анализ , чтобы обеспечить соблюдение сроков, вы должны использовать упреждающий планировщик

• Соблюдение сроков в реальном времени - даже без использования RMA с приоритетной ОСРВ на основе приоритетов ваш планировщик может помочь обеспечить соблюдение сроков. Как это ни парадоксально, ОСРВ обычно увеличивает задержку прерывания из-за критических секций в ядре, где прерывания обычно маскируются

• Управление сложностью - определенно, RTOS (или большинство разновидностей ОС) может помочь с этим. Позволяя проекту быть разложенным на независимые потоки или процессы, и используя службы OS, такие как очереди сообщений, мьютексы, семафоры, флаги событий и т. Д., Для связи & amp; синхронизировать, ваш проект (по моему опыту и мнению) становится более управляемым. Я склонен работать над более крупными проектами, где большинство людей понимают концепцию защиты общих ресурсов, поэтому многие ошибки новичков не случаются. Но будьте осторожны, как только вы перейдете к многопоточному подходу, все может стать более сложным, пока вы не решите проблему.

• Использование сторонних пакетов - многие ОСРВ предлагают другие программные компоненты, такие как стеки протоколов, файловые системы, драйверы устройств, пакеты графического интерфейса, загрузчики и другое промежуточное ПО, которое помогает вам создавать приложение быстрее, становясь почти «интегратором», чем магазин «Сделай сам».

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

• Надежность / отказоустойчивость - ОСРВ также может обеспечивать поддержку MMU процессора (в вашем случае с PIC я не думаю, что это применимо). Это позволяет каждому потоку (или процессу) работать в своем собственном защищенном пространстве; потоки / процессы не могут «окунуться» в память друг друга и растоптать ее. Даже области устройства (MMIO) могут быть недоступны для некоторых (или всех) потоков. Строго говоря, вам не нужна ОСРВ, чтобы использовать MMU (или MPU) процессора, но эти два очень хорошо работают рука об руку.

Как правило, когда я могу разрабатывать с ОСРВ (или каким-либо типом упреждающего многозадачного режима), результат имеет тенденцию быть чище, более модульным, более корректным и более легким в обслуживании. Когда у меня есть возможность, я использую один.

Имейте в виду, что многопоточная разработка имеет некоторую кривую обучения. Если вы новичок в RTOS / многопоточной разработке, вас могут заинтересовать некоторые статьи Выбор RTOS , Опасности вытеснения и Введение в вытесняющую многозадачность .

И наконец, даже если вы не просили рекомендаций ... В дополнение ко многим многочисленным коммерческим ОСРВ, есть бесплатные предложения ( FreeRTOS является одним из самых популярных), и Квантовая платформа является управляемой событиями платформой, основанной на концепции активных объектов , которая включает упреждающее ядро. Существует множество вариантов , но я обнаружил, что наличие исходного кода (даже если ОСРВ не является бесплатной) является преимуществом, особенно. при отладке.