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

Ответ 1

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

• Монотонный анализ скорости (RMA) - если вы хотите использовать Rate Monotonic Analysis, чтобы обеспечить сроки выполнения будут выполнены, вы должны использовать упреждающий планировщик

• Знакомьтесь с сроками реального времени - даже без использования RMA с преимущественной RTOS с приоритетом, ваш планировщик может помочь обеспечить соблюдение сроков. Парадоксально, но RTOS обычно увеличивает задержку прерывания из-за критических разделов в ядре, где прерывания обычно маскируются

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

• Использование сторонних пакетов. Многие RTOS предлагают другие программные компоненты, такие как стеки протоколов, файловые системы, драйверы устройств, пакеты GUI, загрузчики и другое промежуточное программное обеспечение, которые помогают вам создавать приложение быстрее, став почти более "интегратором", чем магазин DIY.

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

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

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

Помните, что многопоточная разработка имеет немного кривую обучения. Если вы новичок в RTOS/многопоточной разработке, вам могут быть интересны некоторые статьи о Выбор RTOS, The Perils of Preemption и Введение в превентивную многозадачность.

Наконец, даже если вы не просили рекомендаций... В дополнение к многочисленным коммерческим RTOS, есть бесплатные предложения (FreeRTOS является одним из самых популярных), а Quantum Platform - это платформа, основанная на событиях, основанная на концепции активных объектов, который включает в себя упреждающее ядро. Есть множество вариантов, но я обнаружил, что наличие исходного кода (даже если RTOS не является бесплатным) выгодно, особенно. при отладке.

Ответ 2

RTOS, в первую очередь, позволяет вам организовать параллельные потоки в набор задач с четко определенной синхронизацией между ними.

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

Ответ 3

Повторное использование кода - если вы кодируете драйверы/обработчики протоколов с использованием интерфейса RTOS, они могут легче подключаться к будущим проектам

Отладка. В некоторых IDE (таких как IAR Embedded Workbench) есть плагины, которые показывают хорошие текущие данные о вашем запущенном процессе, такие как загрузка CPU и использование стека

Ответ 4

Обычно вы хотите использовать RTOS, если у вас есть ограничения в реальном времени. Если у вас нет ограничений в режиме реального времени, достаточно обычной ОС. RTOS/ОС предоставляют инфраструктуру времени выполнения, такую ​​как очереди сообщений и задачи. Если вы просто ищете код, который может снизить сложность, обеспечить поддержку низкого уровня и помочь в тестировании, некоторые из следующих библиотек могут сделать:

• Стандартные библиотеки C/С++
• Библиотеки ускорения
• Библиотеки, доступные через производителя чипа, которые могут предоставить техническую поддержку.
• Коммерческие библиотеки
• Библиотеки с открытым исходным кодом

Ответ 5

Дополнительно к упомянутым выше вопросам использование RTOS также может быть полезно, если вам нужна поддержка

• стандартные устройства хранения (SD, Compact Flash, дисководы...)
• стандартное коммуникационное оборудование (Ethernet, USB, Firewire, RS232, I2C, SPI,...)
• стандартные протоколы связи (TCP-IP,...)

Большинство RTOS-систем предоставляют эти функции или расширяемы для поддержки их