системы реального времени работают в тех приложениях

Операционные системы реального времени для начинающих

Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.

Что такое ОСРВ?

Зачем она нам нужна?

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

Обзор 3 известных ОСРВ.

Внимание: дальше идет мое личное мнение.

FreeRTOS

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

Плюсы

Минусы

1)Довольно-таки сложный процесс портирования на новое железо.

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

KeilRTX

До последнего времени эта ОСРВ была коммерческой, но недавно стала открытой. Работает только на архитектуре arm. Оффициальный сайт.

Плюсы

1)Бесплатная
2)Легко портируется на новое железо( в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.

Минусы

1)Работать на в Keil с ней практически нереально
2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.

Мощная коммерческая ОСРВ. Сайт.

Плюсы

Минусы

1)Коммерческая.
2) Сложна в использовании.

Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.

Другие интересные ОСРВ

RTLinux ОСРВ на основе обычного Линукса.
QNX ОСРВ на основе Unix.

Особенности разработки с использованием ОСРВ

Ну во-первых надо понять следующее: ОСРВ- это не Windows. Его нельзя установить. Эта система просто компилируется с Вашей программой.
При написании программ с ОСРВ не используются функции в обычном их понимании. Вместо функций используются процессы( или таски).Отличие в том что процессы, в отличии от функций, являются бесконечными циклами и никогда не заканчиваются(если только кто-то или он сам его не убъет — то есть выгрузит из памяти).
Если включено несколько процессов, то ОСРВ переключает их, выдавая машинное время и ресурсы по очереди. Вот тут то и возникает понятия приоритета процесса- если двум процессам единовременно нужно машинное время, то ОСРВ даст его тому, у кого приоритет больше.
В ОСРВ есть специальные функции задержки- чтобы время зря не пропадало на время задержки одного процесса выполняется второй.
Теперь поговорим о такой вещи как семафор- эта такая штука, которая управляет доступом процесса к ресурсам приложения. Для каждого ресурса есть маркер — когда процессу нужен ресурс — он его забирает и пользуется данным ресурсом. Если маркера нет, то процессу придется ждать, пока его вернут. Приведу пример: разные процессы отправляют информацию по одному UART. Если бы не было семафора, то они бы отправляли байты по очереди и получилась бы неразбериха. А так первый процесс взял маркер на UART отправил сообщение и отдал второму( и так — до бесконечности).

Дополнительные библиотеки ОСРВ.

Часто ОСРВ предлагают различные библиотеки для работы, например, с графикой, интернетом и т.д. Они действительно удобны и не стоит брезгать их использовать. Однако, помните, что без ОСРВ, для которой они написаны, они работать не будут.
Вот примеры:
Для RTX графика интернет Файловая система

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

Источник

Системы реального времени работают в тех приложениях

Несмотря на то, что первые системы реального времени (СРВ) появились в 50-годы XX века, единого определения,принятого всеми специалистами, до сих пор не существует. Приведем несколько определений СРВ.

(Определение специальности 230102)

(Стандарт POSIX 1003.1)

Мартин Тиммерман (Martin Timmerman)

Определение реального времени

Реальное время (real time) – время, в течение которого протекает процесс.

Реальным временем характеризуют такую реакцию объекта на входные сигналы (/данные), при которой он успевает достаточно быстро выработать выходные сигналы (/данные). Относится к системе или режиму работы, в котором вычисления проводятся в течение времени, определяемого внешним процессом, с целью управления или мониторинга внешнего процесса по результатам этих вычислений.

(Программное обеспечение: IEEE 610.12 – 1990)

В некоторых приложениях вводят свои определения систем реального времени.

Понятие реального времени при цифровой обработке аудио данных

Процесс цифровой обработки сигнала называют идущим в “реальном времени”, если анализ (при вводе) и/или генерация (при выводе) данных может быть проведен за то же время, что и анализ и/или генерация тех же данных без цифровой обработки сигнала.

Например, если анализ 2 секунд звука занимает больше двух секунд (2.01секунды), то это не процесс реального времени, а если 1.99 секунды и меньше, то это обработка в реальном времени.

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

Система реального времени – это не ”быстрая система”. При этом собственно скорость реакции системы важна только относительно скорости протекания внешних процессов, за которыми СРВ должна следить, или которыми должна управлять. Главное, чтобы время было достаточно для данного приложения и гарантированно.

Типичные времена реакции на внешние события в СРВ

1.2 Основные области применения СРВ

Примеры СРВ

1.3 ХАРАКТЕРИСТИКИ СРВ

Основные требования к СРВ

1.4 Классификация СРВ

Системы жесткого реального времени (hard real time system, HRTS)

Системы мягкого реального времени (soft real time system, SRTS).

Системы жесткого реального времени

Системы жесткого реального времени – это такие системы реального времени, в которых предъявляемые временные характеристики обработки событий должны удовлетворяться обязательно и очень строго.
Не допускается никаких задержек реакции системы, так как:
– Может произойти катастрофа в случае задержки реакции;
– Может произойти катастрофа в случае задержки реакции;
– Результаты могут оказаться бесполезны в случае опоздания;
– Стоимость опоздания может оказаться бесконечно велика.

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

Примеры HRTS:
• Бортовые системы управления,
• Системы аварийной защиты,
• Регистраторы аварийных событий,
• Системы безопасности, контроля и управления,
•Системы оцифровки звука/изображения.

Системы мягкого реального времени

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

Признаки систем мягкого реального времени:
– за опоздание результатов приходится платить;
– допускается снижение производительности системы, вызванное запаздыванием реакций.

Примеры SRTS:
• Интерактивные системы
(время реакции на действия пользователя должно быть если не нормированным, то хотя бы предсказуемым и стабильным);
• Работа с пакетами в сети,
• Автомат розничной торговли.

“Да, кого к чертям интересуют разговоры актеров?”
(реакция H. M. Warner (Warner Brothers)
на использование звука в кинематографе, 1927г.)

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

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

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

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

Требования к качеству multimedia определяются человеческим восприятием: например, даже малые паузы в воспроизведении звука очень раздражают, а пропуск кадров в видеоизображении воспринимается более спокойно. Расхождение звука и изображения фиксируется мозгом при задержках 30 мс. Поэтому системыmultimedia должны обеспечивать синхронизацию с достаточно высокой точностью, что характерно для систем реального времени.

Качество сервиса

Воспроизведение цифрового видеопотока
Превышение времени обработки в данном случае не фатально и приводит лишь к отдельным нарушениям последовательности воспроизведения в виде выпадения строк или кадров, уменьшая величину QoS. При определенном количестве или частоте выпадений картинка уже не может отображаться правильно, и хотя система не успевает вычислять результат, к примеру, всего лишь в 30% случаев, величина QoS уже равна нулю, так как окончательный результат неудовлетворителен.

Суммируя вышесказанное о СРВ по этой классификации, можно утверждать:
HRTS – никогда не опоздает с реакцией на событие.
SRTS – не должна опаздывать с реакцией на событие.

Классификация СРВ по природе задач

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

Примеры статических СРВ:
— Автоматические системы управления производством (АСУП),
— Автоматические системы управления технологическим процессом (АСУТП).

На рис.1.1 приведена обобщенная структура АСУТП, как системы реального времени.
Основные группы задач, выполняемые АСУТП:
— мониторинг (сбор данных),
— управление (регулярная подача управляющих команд).

Рис. 1.1. Обобщенная структура АСУТП, как системы реального времени

Типы СРВ по направлению потока данных

Однонаправленные системы – системы, в которых поток данных имеет только одно направление:

Однонаправленные системы осуществляют или ввод или вывод данных из ПК, но не то и другое одновременно. Фаза вывода в них отделена от фазы сбора данных. Такая организация работы реализована в системах сбора, генерации данных. Однако для многих СРВ необходим и ввод и вывод.

Двунаправленные системы – системы, которые осуществляют одновременный ввод-вывод данных:

Система стабильна – если временная задержка управляющего воздействия не приводит к разрушению системы.

Система потенциально нестабильна – задержка реакции системы нарушит ее работоспособность.

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

Классификация СРВ по назначению

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

1.5 Структура СРВ

Источник

Вся правда об ОСРВ от Колина Уоллса

Вся правда об ОСРВ. Статья #1.

Операционные системы реального времени: введение

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

Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.

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

Ниже список тем, которые мы рассмотрим в ближайшее время:

Однако, чтобы объяснить внутреннее устройство ОСРВ, используются примеры кода реального продукта – Nucleus SE.

Вся правда об ОСРВ. Статья #2

ОСРВ: Структура и режим реального времени
Структура программы и режим реального времени

Эта серия статей о встраиваемых системах и, в частности, о программном обеспечении, работающем во встраиваемых системах. Начнем с определения. Что же такое встраиваемая система? В 1986 году, когда я писал первую книгу на эту тему, такого термина еще не существовало. Использовались понятия «выделенная система» или «микросистема», но они, конечно, не отражали всей сути. Через несколько лет в обиход вошло слово «встраиваемая», и все специалисты стали активно его использовать.

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

Операционная система (ОС) всегда стоит на компьютере; в современных встраиваемых системах применяются только некоторые виды ОС. Несмотря на то, что использование ядра преобладает в высокопроизводительных (32- и 64-разрядных) системах, можно извлекать выгоду и из его применения в маломощных устройствах. В центре внимания этих статей – операционные системы, как в общем, так и со спецификой внедрения.

Зачем вообще использовать операционную систему?

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

Другое объяснение кроется в использовании десктопных приложений. С чего вы начнете, если будете писать программное обеспечение для ПК или Mac? Вы включите компьютер, запустите Windows/Linux или macOS и начнете программировать. Наличие операционной системы – это заданное условие, и оно предоставляет ряд полезных сервисов. Навряд ли вы вздумаете начать с нуля, программируя «голое» железо. Поэтому неудивительно, если инженер, у которого есть опыт написания ПО, но для которого встроенное ПО в новинку, будет рассчитывать на наличие операционной системы в разрабатываемой им системе.

Стоит отметить ключевой аспект десктопной ОС, о котором знают пользователи, — пользовательский интерфейс (англ. User Interface, UI). Спросите у кого-нибудь, что такое Windows, и вам ответят, что это окна, меню, диалоговые окна, иконки, но вряд ли упомянут файловую систему, межпрограммную коммуникацию и способность взаимодействовать с другими системами. В этом основное отличие десктопной от встраиваемой системы: в последней может и не быть пользовательского интерфейса, а если он и есть, то он достаточно незамысловатый. Это первое из многих ключевых отличий:

Во-первых, существует выполнение программ в стиле DOS, когда программы выполняются поочередно.

Каждая программа запускается, реализуется и завершается. Мы используем, скажем, программу 1, затем программу 2, затем, возможно, сделаем перерыв, обратимся к программе 3, а потом снова вернемся к программе 2. Второе использование программы 2 начинается заново: запуск не начинается с того места, где мы остановились до этого (кроме тех случаев, когда приложение само не предоставляет такую возможность).

После DOS многое усложнилось, так как Windows стала обычным делом. Выполнение программ в стиле Windows подразумевает запуск нескольких программ в многопоточном режиме.

В таком режиме создается впечатление, что программы работают одновременно, и этой иллюзией управляет Windows. Сначала запускается программа 1, затем в то же время начинает работу программа 2, затем программа 3. Программа 2 завершается, программы 1 и 3 все еще работают. Программа 3 завершается, остается только программа 1. Позднее возобновляется программа 2, а программа 1 завершается, остается только программа 2. Это реалистичный ход событий при использовании Windows обычным пользователем. Операционная система распределяет ресурсы таким образом, чтобы все программы корректно использовали процессор. Это также обеспечивает простую коммуникацию между программами (например, буфер обмена) и управляет пользовательским интерфейсом.

Некоторым портативным устройствам требуется больше гибкости, чем может предложить DOS, но с учетом ограниченных ресурсов, требуются более низкие, чем у Windows, накладные расходы. В итоге, имеем выполнение программ в стиле iOS, а именно:

Программы запускаются поочередно, но их состояние автоматически сохраняется, чтобы можно было продолжить с этого же места при закрытии. Например, запускается программа 1, затем приостанавливается для использования программы 2, затем, например, устройство на какое-то время выключается. При возобновлении загружается программа 3 (состояние программы 2 сохранилось автоматически), а потом пользователь возвращается к программе 2, продолжая работу в ней. Я понимаю, что модель выполнения iOS приложения гораздо сложнее, чем описанное выше, тем не менее, это описание — лишь краткое изложение первичного восприятия пользователя.

Большинство встроенных приложений не соответствует ни одной из вышеперечисленных моделей. Как правило, устройство запускает программу при включении питания и продолжает работать только с этим ПО неопределенное количество времени. Структура подобного кода должна быть тщательно продумана.

Модели встраиваемых программ

Десктопные системы практически все одинаковые. С точки зрения прикладной программы, все персональные компьютеры с Windows идентичны. Встраиваемые системы уникальны: каждая отличается от других. Отличия могут быть техническими: тип процессора, объем памяти, количество периферийных устройств. Приоритетные аспекты приложений также могут отличаться скоростью выполнения, потреблением энергии, защищенностью и надежностью. Могут быть и коммерческие отличия, влияющие на ценообразование: объемы производства и выбор между заказным или стандартным аппаратным обеспечением.

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

В зависимости от требований приложения, встраиваемое ПО может обладать различными структурами разного уровня сложности, например:

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

Если требуется что-то посложнее, можно попробовать разместить некритичную по времени часть кода в основном цикле, а чувствительную ко времени — в обработчике прерываний (англ. Interrupt Service Routines, ISR). Действия обработчика прерываний в основном достаточно короткие, выполняющие только критически важные задачи и отмечающие участки основного цикла для завершения работы при первой же возможности. Трудности могут возникнуть, когда понадобится распределять работу между основным циклом и обработчиком прерываний (а также между несколькими разработчиками).

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

Что такое реальное время?

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

«Операционная система реального времени — это система, в которой корректность вычислений зависит не только от логической корректности вычислений, но также от времени, за которое будет достигнут результат.

Если не выполняются временные ограничения системы, считается, что произошел системный сбой».

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

Операционная система реального времени необязательно очень быстрая, «реальное время» не всегда означает «реально быстрое время». Это означает, что любое необходимое действие будет выполнено своевременно. То есть, достаточно быстро, но в то же время и не слишком быстро (то есть, достаточно медленно).

ОСРВ (при правильном использовании) обеспечивает очень точный контроль за распределением времени процессора на выполнение задач и, следовательно, делает приложения полностью детерминированными. Единственное, что может испортить эту картину, – это прерывания. Есть ОСРВ, которые полностью контролируют прерывания. Их работа заключается в том, чтобы управлять обслуживанием прерываний в рамках работы планировщика задач. Несмотря на то, что это должно было бы приводить к предсказуемому поведению, этот механизм достаточно сложно устроен и заключает в себе высокие накладные расходы.

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

Когда мы работали над нашей собственной операционной системой реального времени ОСРВ МАКС (ранее уже публиковал статьи о ней), наша команда «наткнулась» на блог Колина Уоллса (Colin Walls), эксперта в области микроэлектроники и встроенного ПО компании Mentor Graphics. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.

Источник