Настоящий

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

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

Для сравнения, мягкий режим реального времени — это такая операция, при которой было бы здорово, если бы контроллер реагировал в течение этого периода времени, но если это займет немного больше времени, это тоже было бы совершенно нормально. Некоторые операционные системы способны работать в режиме жесткого реального времени, тогда как другие — нет. В основном это фактор их фундаментальной конструкции, особенно планировщика.

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

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

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

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

Даже за пределами операционных систем производительность процессоров в реальном времени может существенно различаться. Это становится особенно очевидным при рассмотрении микроконтроллеров и количества циклов, необходимых для обработки прерывания. Например, для популярных микроконтроллеров Cortex-M задержка прерывания составляет от 12 циклов (M3, M4, M7) до 23+ (M1), в лучшем случае. Разделите на скорость процессора, и вы получите четверть микросекунды или около того.

Для сравнения, когда мы смотрим на линейку микроконтроллеров Microchip 8051, мы видим в «Руководстве по аппаратному обеспечению микроконтроллеров Atmel 8051» в разделе 2.16.3 («Время отклика»), что в зависимости от конфигурации прерывания задержка прерывания может быть где угодно. от 3 до 8 циклов. На платформах x86 ситуация снова сложнее из-за несколько запутанной природы прерываний x86. Опять какие-то доли микросекунды.

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

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

Как показывает FreeRTOS, основной целью добавления ОС является добавление поддержки многозадачности (и многопоточности). Это означает модуль планировщика, который может использовать какой-то механизм планирования для разделения процессорного времени на «куски», в которых могут быть активны различные задачи или потоки. Хотя самый простой многозадачный планировщик — это кооперативный планировщик, в котором каждый поток добровольно уступает место другим потокам, у него есть явный недостаток: каждый поток может испортить все другим потокам.