Подтвердить что ты не робот

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

Сначала будет рассмотрен фон, особенности моего вопроса:

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 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-систем предоставляют эти функции или расширяемы для поддержки их