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

Question

Прежде всего, мой вопрос будет следующим:

В компании, над которой я работаю на платформе, на которой мы работаем, в настоящее время работает семейство Microchip PIC32, использующее среду MPLAB IDE в качестве среды разработки. Ранее мы также писали прошивку для семейств Microchip dsPIC и TI MSP для этого же приложения. Прошивка довольно проста в том, что код разделен на три основных модуля: управление устройством, выборка данных и связь с пользователем (обычно это ПК пользователя). Управление устройством осуществляется с помощью некоторой комбинации шин шины GPIO и, по меньшей мере, одной части, требующей управления SPI или I2C. Сэмплирование данных прерывается с помощью модуля таймера для поддержки частоты выборки и других шинных линий SPI/I2C и GPIO для управления оборудованием выборки (например, АЦП). В настоящее время связь с пользователем осуществляется через USB с помощью Microchip App Framework.

---

Так что теперь вопрос: учитывая то, что я описал выше, в какой момент я бы рассмотреть вопрос о применении ОСРВ для моего проекта? В настоящее время я имею в виду этих возможных триггерных точек в качестве причины для использования ОСРВ:

• сложность кода? Архитектура/организация базы кода все еще достаточно мала, чтобы я мог хранить все детали в своей голове.
• Многозадачность/Threading? Временное сокращение выполнения модуля с помощью прерываний достаточно для многозадачности.
• Тестирование? В настоящее время мы не проводим много формального тестирования или проверки мимо теста HW smoke (что-то, на что я надеюсь исправить в ближайшем будущем).
• Связь? В настоящее время мы используем пользовательский формат пакета и протокол, который в значительной степени выполняет команды START, STOP, SEND DATA с данными, являющимися двоичным блобом.
• Объем проекта? В ближайшем будущем есть вероятность, что мы получим проект для интеграции нашего устройства в более крупную систему с целью переноса этой системы на массовое производство. В настоящее время все наши проекты представляют собой экспериментальные прототипы с быстрым поворотом около месяца, производя один или два блока за раз.

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

Answer 1

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

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

• Знакомства в режиме реального времени сроки - даже без использования РВД, с приоритетом на основе упреждающего RTOS, ваш планировщик может помочь гарантировать сроки которые встретились. Как это ни парадоксально, ОСРВ, как правило, увеличивает interrupt latency благодаря critical sections в ядре, где прерывания обычно маскируются

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

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

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

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

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

Помните, что многопоточная разработка имеет немного кривой обучения. Если вы новичок в RTOS/многопоточной разработке, вас могут заинтересовать некоторые статьи по Choosing an RTOS, The Perils of Preemption и An Introduction to Preemptive Multitasking.

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

Answer 2

код повторного использования - если вы драйверы код/​​протокольные-обработчики с использованием API ОСРВ они могут подключаться к будущим проектам легче

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

Answer 3

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

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

Answer 4

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

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

Answer 5

В дополнении к пунктам, упомянутых выше, с использованием ОСРВА может быть также полезно, если вам нужна поддержка для

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

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