Как работают операционные системы реального времени?

Ответ 1

Сроки собрания - это функция приложения, которое вы пишете. RTOS просто предоставляет средства, которые помогут вам с соблюдением сроков. Вы также можете запрограммировать "голый металл" (без RTOS) в большой основной петле и встретить крайние сроки.

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

Некоторые из возможностей, предоставляемых RTOS:

• Планировщик с приоритетом
• Процедура прерывания системных часов
• Детерминированное поведение

Планировщик с приоритетом

Большинство RTOS имеют от 32 до 256 возможных приоритетов для отдельных задач/процессов. Планировщик выполнит задачу с наивысшим приоритетом. Когда запущенная задача отказывается от CPU, запускается следующая задача с наивысшим приоритетом и так далее...

Задача с наивысшим приоритетом в системе будет иметь процессор до:

• он заканчивается (т.е. он добровольно отказывается от процессора)
• задача с более высоким приоритетом готова к работе, и в этом случае первоначальная задача будет предварительно задана новой задачей (более высокий приоритет).

Как разработчик, ваша задача - назначать приоритеты задач таким образом, чтобы ваши крайние сроки выполнялись.

Процедуры прерывания системных часов

RTOS обычно предоставляет своего рода системные часы (от 500 до 100 мс), что позволяет выполнять операции, зависящие от времени. Если у вас системные часы 1 мс, и вам нужно выполнять задание каждые 50 мс, обычно есть API, который позволяет вам сказать "В 50 мс разбудить меня". В этот момент задача будет спать до тех пор, пока ОСРВ не разбудит ее.

Обратите внимание, что просто пробуждение не гарантирует, что вы будете работать точно в это время. Это зависит от приоритета. Если в настоящее время выполняется задача с более высоким приоритетом, вы можете задержать.

Детерминированное поведение

RTOS подходит к концу, чтобы убедиться, что у вас есть 10 задач или 100 задач, теперь нет необходимости переключать контекст, определять, что следующая задача с наивысшим приоритетом, и т.д.

В целом, операция RTOS пытается быть O (1).

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

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

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

Ответ 2

В RTOS-системах наиболее важными параметрами, о которых следует позаботиться, являются более низкие задержки и детерминизм времени. Что приятно делать, следуя определенным политикам и трюкам.

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

У RTOS есть задачи, которые намного легче, чем процессы/потоки в GPOS.

Ответ 3

Дело не в том, что они могут соответствовать предельным срокам, а скорее, что они имеют фиксированные сроки, тогда как в обычной ОС такой крайний срок нет.

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

Кроме того, как правило, время выполнения задач завершается, после чего сообщается о сбое. Это не происходит в обычной ОС.

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

Ответ 4

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

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

Обычно это гораздо более простая ОС, чем полноценная Linux или Windows, просто потому, что легче анализировать и прогнозировать поведение простого кода. Ничто не останавливает полноценную ОС, такую ​​как Linux, которая используется в среде RTOS, и имеет расширения RTOS. Из-за сложности базы кода он не сможет гарантировать, что его тайминги будут такими же небольшими, как и меньшая ОС.

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

Ответ 5

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

• FreeRTOS
• eCos

Коммерческая RTOS, которая хорошо документирована, доступна в виде исходного кода и удобна в работе, μC/OS-II. Он имеет очень разрешительную лицензию на использование в образовательных целях, и (его устаревшая версия) его источник может быть привязан к книге, описывающей ее теорию работы, используя фактическую реализацию в качестве примера кода. Книга MicroC OS II: Ядро реального времени Jean Labrosse.

Я использовал μC/OS-II в нескольких проектах на протяжении многих лет и могу рекомендовать его.

Ответ 6

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

Бывает, что RTOS помогают выполнять эту работу (создавая приложение и проверяя его ограничения RT). Но я видел приложения реального времени, работающие на стандартном Linux, больше полагаясь на аппаратную мощность, чем на дизайн ОС.

Ответ 7

Я не использовал RTOS, но я думаю, что так они работают.

Есть разница между "жестким реальным временем" и "мягким реальным временем". Вы можете писать приложения реального времени на не-RTOS, например Windows, но они "мягкие" в режиме реального времени:

• Как приложение, у меня может быть поток или таймер, который я прошу O/S запускать 10 раз в секунду... и, возможно, O/S будет делать это большую часть времени, но там нет гарантии, что он всегда сможет... это отсутствие гарантии, поэтому оно называется "мягким". Причина, по которой O/S может оказаться невозможной, заключается в том, что другой поток может заставлять систему заняты чем-то другим. В качестве приложения я могу увеличить приоритет потока, например, HIGH_PRIORITY_CLASS, но даже если я это сделаю, у O/S по-прежнему нет API, который я могу использовать для запроса гарантии, который я буду выполняться в определенное время.

• "Жесткий" O/S в реальном времени (я полагаю) имеет API, которые позволяют мне запрашивать гарантированные срезы выполнения. Причина, по которой RTOS может сделать такие гарантии, заключается в том, что она готова отказаться от потоков, которые занимают больше времени, чем ожидалось/чем они разрешены.

Ответ 8

... хорошо...

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

Даже если вы знаете, как писать правильный код: Это больше о попытке быть детерминированным, чем быть быстрым.

Когда мы говорим о детерминизме, это

1) детерминизм событий

Для каждого набора входов известны следующие состояния и выходы системы

2) временный детерминизм

... также известно время отклика для каждого набора выходов

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

Если вы действительно хотите быть детерминированным опросом, все.

... но, возможно, не обязательно быть 100% детерминированным

Ответ 9

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

Ответ 10

Они фактически не гарантируют соблюдение сроков; что они делают, что делает их по-настоящему RTOS, чтобы обеспечить средства для распознавания и устранения переполнения крайних сроков. "Жесткие" системы RT обычно представляют собой те, в которых отсутствует конечный срок, является катастрофическим, и требуется какое-то отключение, тогда как "мягкая" система RT - это та, где продолжающаяся деградированная функциональность имеет смысл. В любом случае RTOS позволяет вам определять ответы на такие перерасходы. Non RT OS даже не обнаруживает переполнения.

Ответ 11

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

Это действительно правильно. В RTOS будет установлен системный тик, определенный архитектурой, скажем, 10 миллисекунд, причем все задачи (потоки) будут разработаны и измерены для завершения в определенные моменты времени. Например, при обработке аудиоданных в реальном времени, когда частота дискретизации аудио составляет 48 кГц, существует известное количество времени (в миллисекундах), при котором предварительный буфер станет пустым для любой последующей задачи, которая обрабатывает данные. Поэтому использование RTOS требует правильной калибровки буферов, оценки и измерения продолжительности этого времени и измерения латентности между всеми слоями программного обеспечения в системе. Тогда сроки могут быть выполнены. В противном случае приложения пропустят сроки. Это требует анализа обработки данных наихудшего случая во всем стеке, и, как только наихудший случай известен, система может быть спроектирована, например, на 95% времени обработки с 5% бездействием (эта обработка может никогда не произойти в любое реальное использование, поскольку обработка данных в наихудшем случае не может быть разрешенным состоянием во всех слоях в любой момент времени).

Примеры временных диаграмм для разработки сетевого приложения реального времени в операционной системе приведены в этой статье в EE Times, КАЧЕСТВО ПРОДУКЦИИ: Улучшение качества голоса в режиме реального времени в VoIP-телефонии http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design

Ответ 12

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

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

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