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

Question

Я имею в виду, как и почему операционные системы реального времени могут уложиться в сроки, даже не пропуская их? Или это просто миф (что они не пропускают сроки)? Чем они отличаются от обычной ОС и что мешает обычной ОС быть ОСРВ?

Answer 1

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

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

Некоторые из средств, которые предоставляет ОСРВ:

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

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

Большинство ОСРВ имеют от 32 до 256 возможных приоритетов для отдельных задач / процессов. Планировщик запустит задачу с наивысшим приоритетом. Когда запущенная задача отдает ЦП, запускается следующая задача с наивысшим приоритетом и т. Д. *

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

• FreeRTOS
• Экос

Коммерческая ОСРВ, которая хорошо документирована, доступна в виде исходного кода и с которой легко работать - µC / OS-II . Он имеет очень разрешительную лицензию для использования в образовательных целях, и (слегка устаревшая версия) его источник можно связать с книгой, описывающей его теорию работы, используя фактическую реализацию в качестве примера кода. Книга MicroC OS II: ядро ​​реального времени от Джин Лабросс.

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

«По сути, вы должны закодировать каждую« задачу »в ОСРВ так, чтобы они заканчивались за конечное время.»

Это действительно правильно. ОСРВ будет иметь системный тик, определяемый архитектурой, скажем, 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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

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

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

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

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

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

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

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

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

Answer 10

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

Существует разница между "жестким реальным временем" и "мягким реальным временем". Вы можете писать приложения в реальном времени в не-ОСРВ, таких как Windows, но они «мягкие» в реальном времени:

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

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