Существует много причин, по которым вы можете захотеть использовать ОСРВ.Они различны, и степень, в которой они относятся к вашей ситуации, трудно сказать.(Примечание: я склонен думать так: ОСРВ подразумевает жесткое реальное время, которое подразумевает упреждающее ядро ...)
Оценить монотонный анализ (RMA) - если вы хотите использовать Оценить монотонный анализ , чтобы обеспечить соблюдение сроков, вы должны использовать упреждающий планировщик
Соблюдение сроков в реальном времени - даже без использования RMA с приоритетной ОСРВ на основе приоритетов ваш планировщик может помочь обеспечить соблюдение сроков.Как это ни парадоксально, ОСРВ обычно увеличивает задержку прерываний из-за критических секций в ядре, где прерывания обычно маскируются
Управление сложностью - определенно, RTOS (или большинство разновидностей ОС) может помочь с этим.Позволяя проекту быть разложенным на независимые потоки или процессы, и используя службы OS, такие как очереди сообщений, мьютексы, семафоры, флаги событий и т. Д., Для связи и синхронизации, ваш проект (по моему опыту и мнению) становится более управляемым.Я склонен работать над более крупными проектами, где большинство людей понимают концепцию защиты общих ресурсов, поэтому многие ошибки новичков не случаются.Но будьте осторожны, как только вы перейдете к многопоточному подходу, все может стать более сложным, пока вы не решите проблему.
Использование сторонних пакетов - многие ОСРВ предлагают другие программные компоненты, такие как стеки протоколов, файловые системы, драйверы устройств, пакеты графического интерфейса, загрузчики и другое промежуточное ПО, которые помогают вам быстрее создавать приложения, становясь почти более «интегратором», чем магазин «Сделай сам».
Тестирование - да, определенно, вы можете думать о каждом потоке управления как о тестируемом компоненте с четко определенным интерфейсом, особенно если используется согласованный подход (например, всегда блокировка в одном месте в очереди сообщений).Конечно, это не является заменой тестирования модулей, интеграции, системы и т. Д.
Надежность / отказоустойчивость - ОСРВ также может обеспечивать поддержкуMMU процессора (в вашем случае PIC, я не думаю, что это применимо).Это позволяет каждому потоку (или процессу) работать в своем собственном защищенном пространстве;потоки / процессы не могут «окунуться» в память друг друга и растоптать ее.Даже области устройства (MMIO) могут быть недоступны для некоторых (или всех) потоков.Строго говоря, вам не нужна ОСРВ, чтобы использовать MMU (или MPU) процессора, но эти два очень хорошо работают рука об руку.
Как правило, когда я могу разрабатыватьс ОСРВ (или некоторым типом упреждающего многозадачного режима) результат имеет тенденцию быть чище, более модульным, более корректным и более удобным в обслуживании.Когда у меня есть возможность, я использую ее.
Имейте в виду, что многопоточная разработка имеет некоторую кривую обучения.Если вы новичок в RTOS / многопоточной разработке, вас могут заинтересовать некоторые статьи Выбор RTOS , Опасности вытеснения и Введение в вытесняющую многозадачность .
Наконец, даже если вы не просили рекомендаций ... В дополнение ко многим многочисленным коммерческим ОСРВ, есть бесплатные предложения ( FreeRTOS является одним из самых популярных)и Quantum Platform является управляемой событиями средой, основанной на концепции активных объектов , которая включает вытесняющее ядро.Есть множество вариантов , но я обнаружил, что наличие исходного кода (даже если ОСРВ не бесплатна) является преимуществом, особенно.при отладке.