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

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

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

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

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

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

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

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

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

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

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

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

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

• коде
• eCos

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

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

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

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

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

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

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

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

... что ж...

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

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

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

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

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

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

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

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

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

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

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

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

"в принципе, вы должны закодировать каждую "задачу" в 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

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

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

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