Есть два основных вида операционных систем: общего назначения и реального времени. Системы общего назначения — это обычные операционные системы в привычном нам смысле: Windows, Linux и Mac OS. Они решают много задач сразу, но иногда могут зависать или тормозить. Но есть устройства и задачи, где на всё нужна моментальная реакция без права на ошибку или зависание.
В них используют операционные системы реального времени. Про них и поговорим.
Что такое операционная система реального времени (RTOS)
RTOS — это аббревиатура от real-time operating system, операционная система реального времени. Главное отличие таких систем от всех остальных — в скорости обработки внешних сигналов и своевременном реагировании. В RTOS время реагирования и обработки сигнала должно быть таким, чтобы гарантированно успеть сделать всё, что нужно в данный момент. Чтобы было понятнее, поясним на фитнес-браслете.
Задача фитнес-браслета — отслеживать пульс во время тренировок, следить за физической активностью и точно отсчитывать время. А если тренировки сейчас нет — показывать время, управлять музыкой, будильниками и прочим хозяйством.
РАЗРАБОТКА СИСТЕМ УПРАВЛЕНИЯ РЕАЛЬНОГО ВРЕМЕНИ
Представим ситуацию, что у нас браслет показывает время на экране постоянно — движутся стрелки, мигают цифры, всё как в обычных часах. Но как только мы нажимаем кнопку или касаемся экрана, браслет бросает всё и начинает обрабатывать наше нажатие — например запускать секундомер. Это значит, что браслет в режиме реального времени реагирует на все наши действия — без задержек и зависаний. При этом в фоне может идти обратный отсчёт, а датчики будут измерять пульс — всё это не должно мешать сразу реагировать на внешние действия.
Планировщик задач
В основе систем реального времени лежат системные часы и планировщик задач. Цель планировщика — обеспечить выполнение всех задач в нужное время и вовремя среагировать на внешнее событие.
Например, в нашем браслете одновременно работают такие задачи:
- отображение времени на экране;
- секундомер в фоне;
- измерение пульса каждые 2 минуты.
Так как каждая задача должна работать в режиме реального времени, а процессор один, то планировщик распределяет эти задачи так:
- Выполняет одну команду из функции с отображением времени и ставит её на паузу.
- Переключается на секундомер, смотрит, сколько времени прошло, запоминает это и переключается обратно на отображение.
- Показывает время на экране, обновляет положение секундной стрелки и переключается на секундомер, и всё по новой.
- В этот момент планировщик получает уведомление от внутренних часов, что прошло 2 минуты. Он ставит все задачи на паузу, даёт команду датчику измерять пульс и снова переключается на выполнение других задач.
- Теперь планировщик по кругу перебирает уже три задачи: стрелки, секундомер и пульс.
Если это нарисовать в виде схемы, получится так:
Источник: dzen.ru
Лекция «Введение в операционные системы реального времени»
Как устроена RTOS — операционная система реального времени
Есть два основных вида операционных систем: общего назначения и реального времени. Системы общего назначения — это обычные операционные системы в привычном нам смысле: Windows, Linux и Mac OS. Они решают много задач сразу, но иногда могут зависать или тормозить. Но есть устройства и задачи, где на всё нужна моментальная реакция без права на ошибку или зависание.
В них используют операционные системы реального времени. Про них и поговорим.
Что такое операционная система реального времени (RTOS)
RTOS — это аббревиатура от real-time operating system, операционная система реального времени. Главное отличие таких систем от всех остальных — в скорости обработки внешних сигналов и своевременном реагировании. В RTOS время реагирования и обработки сигнала должно быть таким, чтобы гарантированно успеть сделать всё, что нужно в данный момент. Чтобы было понятнее, поясним на фитнес-браслете.
Задача фитнес-браслета — отслеживать пульс во время тренировок, следить за физической активностью и точно отсчитывать время. А если тренировки сейчас нет — показывать время, управлять музыкой, будильниками и прочим хозяйством.
Представим ситуацию, что у нас браслет показывает время на экране постоянно — движутся стрелки, мигают цифры, всё как в обычных часах. Но как только мы нажимаем кнопку или касаемся экрана, браслет бросает всё и начинает обрабатывать наше нажатие — например запускать секундомер. Это значит, что браслет в режиме реального времени реагирует на все наши действия — без задержек и зависаний. При этом в фоне может идти обратный отсчёт, а датчики будут измерять пульс — всё это не должно мешать сразу реагировать на внешние действия.
Планировщик задач
В основе систем реального времени лежат системные часы и планировщик задач. Цель планировщика — обеспечить выполнение всех задач в нужное время и вовремя среагировать на внешнее событие.
Например, в нашем браслете одновременно работают такие задачи:
- отображение времени на экране;
- секундомер в фоне;
- измерение пульса каждые 2 минуты.
Так как каждая задача должна работать в режиме реального времени, а процессор один, то планировщик распределяет эти задачи так:
- Выполняет одну команду из функции с отображением времени и ставит её на паузу.
- Переключается на секундомер, смотрит, сколько времени прошло, запоминает это и переключается обратно на отображение.
- Показывает время на экране, обновляет положение секундной стрелки и переключается на секундомер, и всё по новой.
- В этот момент планировщик получает уведомление от внутренних часов, что прошло 2 минуты. Он ставит все задачи на паузу, даёт команду датчику измерять пульс и снова переключается на выполнение других задач.
- Теперь планировщик по кругу перебирает уже три задачи: стрелки, секундомер и пульс.
Если это нарисовать в виде схемы, получится так:
Жёсткие и мягкие системы
Смысл RTOS в том, чтобы система моментально отзывалась на любые события, независимо от того, что происходит у неё прямо сейчас. В зависимости от скорости реакции такие системы делят на жёсткие и мягкие.
Жёсткие системы гарантируют выполнение любой задачи вовремя, а сам процесс занимает не больше того времени, что прописан в регламентах задач. Например, часть систем автопилотов в авиации работает на таких системах — они должны укладываться в норматив по времени срабатывания в любых нештатных ситуациях. Аварийные системы управления тоже часто работают на RTOS, чтобы успевать вовремя реагировать на происходящее.
При тестировании жёсткой системы задержка выполнения считается ошибкой, и тест проваливается. Даже если потом система сделала всё правильно и вовремя, но не успела вовремя стартовать нужный процесс, тест не пройден и система отправляется на доработку.
Мягкие системы к задержкам относятся чуть проще: это неприятно, но терпимо, если она не превышает определённых значений (например, 0,3 секунды).
Большинство бытовых систем относится к мягким — если фитнес-браслет среагирует на нажатие на 0,1 секунду позже, ничего критичного не произойдёт. Но если от нажатия до реакции проходит пара секунд — беда. Дешёвые китайские умные часы часто тормозят именно по этой причине — чтобы не тратить время и деньги на оптимизацию, в часы ставят стандартный софт и не подгоняют его под конкретный процессор.
Почему RTOS — это надёжно
RTOS по большей части решает проблему зависаний.
Допустим, в системе перемкнуло датчик управления и одна из функций, которая за него отвечает, ушла в бесконечный цикл. В обычной ОС это привело бы к тому, что зависла бы программа или весь компьютер. В случае с RTOS это решается так:
- Планировщик выполняет по очереди команды и доходит до команды с бесконечным циклом.
- Выполняет одну команду оттуда, ставит эту задачу на паузу и идёт к другим задачам.
Получается, что бесконечный цикл тоже выполняется по очереди с другими — это значит, что он не будет мешать работе остальных задач. При этом, если планировщик достаточно умный, в какой-то момент он поймёт, что функция работает неправильно, и либо остановит её, либо перезапустит.
Благодаря тому, что система не зависает даже при попадании в бесконечный цикл, RTOS и получилась такой надёжной системой.
На чём пишут системы реального времени
Главные языки для RTOS — это C и C++ (то есть «Си» и «Си плюс плюс»). Они позволяют учесть особенности процессора и памяти и обеспечить нужное быстродействие.
Ещё RTOS пишут на ассемблерах — когда нужно выжать из железа максимум и сделать супербыструю реакцию на любые события. Но это уже высший пилотаж, и такое встречается редко.
Где применяются RTOS
Системы реального времени применяются везде, где нужна надёжность, скорость или простота.
Например, RTOS управляет системами защиты серверов, кардиостимуляторами, электронной тормозной системой в автомобиле, автопилотом, системами отслеживания биржевых котировок и бронирования билетов. А всё потому, что там нужна моментальная обработка запросов и полное отсутствие сбоев в любых условиях.
С другой стороны, RTOS в простейшем виде стоит в музыкальных брелках, синтезаторах, беспроводных колонках и игрушках — там, где нужно реагировать на действия пользователя, но требования к задержкам не такие критичные.
Апскиллинг, как говорится
Апскиллинг — это, например, переход с уровня junior на уровень middle, а потом — senior. У «Яндекс Практикума» есть курсы ровно для этого: от алгоритмов и типов данных до модных фреймворков.
Получите ИТ-профессию
В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.
Источник: thecode.media
Вся правда об ОСРВ от Колина Уоллса
Эта серия статей посвящена тщательному изучению всех аспектов операционных систем реального времени (ОСРВ). Статьи ориентированы на разработчиков, которым любопытно узнать, как работают ОСРВ и как ими пользоваться. Отправной точкой станет рассуждение о системах реального времени в общем, далее речь пойдет о том, как ОСРВ могут упростить их реализацию и сделать полученный код более надежным.
Заглянув во внутрь ОСРВ, мы посмотрим, как работает планировщик задач. Благодаря многопоточности создается впечатление, что ЦП выполняет несколько операций одновременно. Это не магия, понимание принципов работы планировщика задач доступно даже неопытному инженеру-программисту. Мы поговорим и о других объектах ОСРВ: о взаимодействии между задачами и синхронизации, о режиме реального времени, об управлении памятью и т. д., все будет точно описано и подкреплено примерами кода.
Для разработчика ключевым аспектом ОСРВ является API, набор вызова процедур, предоставляющий доступ к функционалу ОСРВ. В серии буду представлены статьи на эту тему, посвященные тому, как устроен API, какие стандарты доступны и как перейти с одного API на другой.
Ниже список тем, которые мы рассмотрим в ближайшее время:
- Структура программы и режим реального времени
- Операционные системы реального времени
- Задачи и планирование
- Взаимодействие между задачами и синхронизация
- Другие сервисы операционной системы
- Nucleus SE
- Планировщик
- Задачи
- Разделы памяти
- Сигналы
- Группы флагов событий
- Семафоры
- Почтовые ящики
- Очереди
- Каналы
- Системное время
- Программные таймеры
- Прерывания
- Диагностика и проверка ошибок
- Инициализация и запуск
Однако, чтобы объяснить внутреннее устройство ОСРВ, используются примеры кода реального продукта – 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. Статьи показались интересными, переводили их для себя, но, чтобы не «писать в стол» решили опубликовать. Надеюсь, они будут вам также полезны. Если так, то дальше планируем опубликовать все переведенные статьи серии.
Статья 3 опубликована здесь.
Источник: habr.com