Я имею в виду, как и почему операционные системы реального времени могут соответствовать срокам, не потеряв их? Или это просто миф (что они не упускают крайних сроков)? Чем они отличаются от обычных ОС и что мешает обычной ОС быть RTOS?Как работают операционные системы реального времени?
Выполнение сроков является функцией приложения, которое вы пишете. RTOS просто предоставляет средства, которые помогут вам с соблюдением сроков. Вы также можете запрограммировать «голый металл» (без RTOS) в большой основной петле и встретить крайние сроки.
Также имейте в виду, что в отличие от ОС общего назначения, RTOS имеет очень ограниченный набор задач и процессов.
Некоторых объектов ОСРВ обеспечивает:
основой приоритет планировщик
Большинство RTOS имеют 32 и 256 возможных приоритетов для отдельных задач/процессов. Планировщик выполнит задачу с наивысшим приоритетом. Когда бегущая задача отдает процессор, следующий приоритетной задачей высокий работает, и так далее ...
наивысший приоритет задачи в системе будет иметь процессор до:
Как разработчик, ваша задача - назначить приоритеты задач таким образом, чтобы ваши крайние сроки были выполнены.
System Clock обработки прерываний
ОСРВ, как правило, обеспечивают некоторый вид системных часов (где-то от 500 мкс до 100 мс), что позволяет выполнять чувствительные ко времени операции. Если у вас есть системные часы 1 мс, и вам нужно выполнять задание каждые 50 мс, обычно есть API, который позволяет вам сказать «В 50 мс разбудить меня». В этот момент задача будет спать до тех пор, пока ОСРВ не разбудит ее.
Обратите внимание, что только что проснувшийся не гарантирует, что вы будете работать точно в это время. Это зависит от приоритета. Если в настоящее время выполняется задача с более высоким приоритетом, вы можете отложить ее.
детерминированного поведение
ОСРВ идет на большие длины, чтобы гарантировать, что есть ли у вас 10 задач или 100 задач, это не займет больше для переключения контекста, определить, что следующая приоритетная задача высокой является, и т. д.
В целом, операция RTOS пытается быть O (1).
Одной из основных областей детерминированного поведения в RTOS является обработка прерываний. Когда сигнализируется строка прерывания, RTOS немедленно переключается на правильную процедуру обслуживания прерываний и обрабатывает прерывание без задержки (независимо от приоритета любой выполняемой в настоящее время задачи).
Обратите внимание, что большинство аппаратных ISR будут написаны разработчиками проекта. RTOS может уже предоставлять ISR для последовательных портов, системных часов, возможно, сетевого оборудования, но любые специализированные (сигналы кардиостимулятора, исполнительные механизмы и т. Д.) Не будут частью RTOS.
Это грубое обобщение, и, как и все остальное, существует большое разнообразие реализаций RTOS. Некоторые RTOS делают все по-другому, но описание выше должно быть применимо к большой части существующих RTOS.
«Эта задача будет завершена», как Windows 3.1! Тогда вы имеете в виду, что ОСРВ не являются превентивными? –
Нет, если вы являетесь наивысшим приоритетом, который вы выполняете до тех пор, пока вы добровольно не сдаетесь, или задачей с более высоким приоритетом, чем вы станете готовой, и в это время (старый) высокий приоритет будет упущен. Я уточню в основном тексте. Благодаря! – Benoit
Дело не в том, что они могут соответствовать срокам, а скорее, что у них установлены фиксированные сроки, тогда как в обычной ОС такой крайний срок нет.
В обычной ОС планировщик задач не является строгим. То есть процессор будет выполнять так много инструкций в секунду, но иногда это может и не делать. Например, задача может быть упреждающей, чтобы позволить выполнять более высокий приоритет (и может быть на более длительное время). В RTOS процессор всегда будет выполнять одинаковое количество задач.
Кроме того, как правило, срок выполнения задач завершается, после чего сообщается о сбое. Это не происходит в обычных ОС.
Очевидно, что для объяснения есть намного больше деталей, но приведенные выше являются двумя важными аспектами дизайна, которые используются в RTOS.
В принципе, вам нужно запрограммировать каждую «задачу» в RTOS, чтобы они завершились за конечное время.
Кроме того, ваше ядро выделяет определенное количество времени для каждой задачи, пытаясь гарантировать, что определенные вещи произошли в определенное время.
Обратите внимание, что это непростая задача. Представьте себе такие вещи, как вызовы виртуальных функций, в OO очень сложно определить эти вещи. Кроме того, RTOS должен быть тщательно закодирован в отношении приоритета, может потребоваться, чтобы задача с высоким приоритетом давала процессор в течение x миллисекунд, что может быть затруднено в зависимости от того, как работает ваш планировщик.
«В принципе, вам нужно закодировать каждую« задачу »в RTOS, чтобы они завершились в течение конечного времени» - тогда это приложение, которое следует называть в реальном времени, а не в ОС. –
Что происходит, когда задача заканчивается? –
задача принудительно выгружается и перезапускается на следующем фрагменте времени. Хорошая ОС реального времени вызовет ошибку или сообщит, что это произошло. – Spence
Важно, что приложения реального времени, а не операционные системы реального времени. Обычно приложения реального времени предсказуемы: многие тесты, проверки, анализ WCET, доказательства, ... были выполнены, которые показывают, что крайние сроки выполняются в любых указанных ситуациях.
Бывает, что RTOS помогают выполнить эту работу (создавая приложение и проверяя его ограничения RT). Но я видел приложения реального времени, работающие на стандартном Linux, полагаясь больше на аппаратную мощность, чем на дизайн ОС.
RTOS предоставляет очень строгие гарантии в отношении важных вещей, таких как время обслуживания прерываний, латентность переключения задач и т. Д. Приложения реального времени не могут быть использованы без надлежащей RTOS. –
Я просто говорю о том, что я видел. И более чем часто проблемы в реальном времени решаются с помощью огромных частот процессора и большого количества времени. – mouviciel
Я не использовал RTOS, но я думаю, что так они работают.
Существует разница между «жестким реальным временем» и «мягким реальным временем». Вы можете создавать приложения в режиме реального времени на не-RTOS, как Windows, но они «мягкие» в режиме реального времени:
В качестве приложения, я мог бы нить или таймер, который я задаю O/S, чтобы запускать 10 раз в секунду ... и, возможно, O/S будет делать это большую часть времени, но нет никакой гарантии, что он всегда сможет ... это отсутствие гарантии - это почему это называется «мягким», , Причина, по которой O/S может оказаться невозможной, заключается в том, что другой поток может заставлять систему заняты чем-то другим. В качестве приложения я могу повысить приоритет потока, например, HIGH_PRIORITY_CLASS, но даже если я это сделаю, у O/S все еще нет API, который я могу использовать для запроса гарантии, что я буду работать в определенное время.
«Жесткий» O/S в реальном времени (я полагаю) имеет API, которые позволяют мне запрашивать гарантированные срезы выполнения. Причина, по которой RTOS может сделать такие гарантии, заключается в том, что она готова отменить потоки, которые занимают больше времени, чем ожидалось/чем они разрешены.
Речь идет не только о планировании - операционная система должна убедиться, что никакие случайные вещи не используются как сборка мусора или дефрагментация адресного пространства в памяти, так что вы знаете, что malloc() всегда будет возвращаться без задержки, поэтому (например) самолет автопилота контролирует не сбой. –
И, предположительно, аппаратные прерывания тоже. – ChrisW
Ваш RTOS разработан таким образом, что он может гарантировать синхронизацию важных событий, таких как аппаратное прерывание и пробуждение спальных процессов именно тогда, когда они должны быть.
Это точное время позволяет программисту быть уверенным в том, что его (скажем) кардиостимулятор будет выводить импульс именно тогда, когда это необходимо, а не через несколько десятков миллисекунд позже, поскольку ОС занята другой неэффективной задачей.
Обычно это гораздо более простая ОС, чем полноценная Linux или Windows, просто потому, что легче анализировать и прогнозировать поведение простого кода. Ничто не останавливает полноценную ОС, такую как Linux, которая используется в среде RTOS, и имеет расширения RTOS. Из-за сложности базы кода он не сможет гарантировать, что его тайминги будут такими же небольшими, как и меньшая ОС.
Планировщик RTOS также более строг, чем планировщик общего назначения. Важно знать, что планировщик не изменит приоритет своей задачи, потому что вы работаете долгое время и не имеете никаких интерактивных пользователей. Большинство ОС сокращают внутренний приоритет этого типа процесса в пользу краткосрочных интерактивных программ, где интерфейс не должен замечать отставание.
Возможно, вам будет полезно прочитать источник типичной RTOS. Есть несколько примеров с открытым исходным кодом там, и следующей дали ссылку в немного быстром поиске:
коммерческой RTOS, хорошо документированная, имеющихся в форма исходного кода и легко работать с µC/OS-II. Он имеет очень разрешительную лицензию на использование в образовательных целях, и (его устаревшая версия) его источник может быть привязан к книге, описывающей ее теорию работы, используя фактическую реализацию в качестве примера кода. Книга MicroC OS II: The Real Time Kernel Jean Labrosse.
Я использовал μC/OS-II в нескольких проектах на протяжении многих лет и могу рекомендовать его.
... ну ...
операционная система, в режиме реального времени пытается быть детерминированным и уложиться в сроки, но все это зависит от того, как вы пишете приложение. Вы можете сделать RTOS очень не в режиме реального времени, если вы не знаете, как писать «правильный» код.
Даже если вы знаете, как правильно писать код: Это скорее попытка быть детерминированным, чем быть быстрым.
Когда мы говорим о детерминизме это
1) детерминизм события
Для каждого набора входных данных следующих состояний и выходы системы известны
2) временная детерминизм
... также известно время отклика для каждого набора выходов
Это означает, что если у вас есть асинхронные события, такие как i nterrupts ваша система, строго говоря, уже не является временной детерминированной. (и большинство систем используют прерывания)
Если вы действительно хотите быть детерминированным, опробуйте все.
... но, возможно, это не нужно быть на 100% детерминированных
«Если ты действительно хочешь быть детерминированным опросом всего». - Что, если вы пропустите событие с более высоким приоритетом между циклами опроса? Не приведет ли это к отказу от ОС в реальном времени для этих событий? –
Конечно, это будет, но вы сделали свой анализ и удостоверились, что все события извне ОС входят в определенные временные рамки (что-то вроде спорадического сервера для ваших входов). В случае неисправности (треснувший кабель) вы должны выбросить события в любом случае. То, что вы уверены в опросе, а не при использовании каких-либо прерываний, заключается в том, что тот факт, что вы используете прерывание, больше не унижает детерминизм. –
Вы пытаетесь сказать, что это эффективно компромисс между латентностью и детерминизмом? IMO модель «события в четко определенных границах» терпит неудачу, когда у вас есть иерархия событий (то есть приоритетные события). Нет причин, по которым совершенно несвязанное событие должно учитывать временные рамки события/задачи низкого приоритета (LP). Задача LP должна быть выгружена, даже если событие HP происходит при t0 + dt. Где dt - бесконечно малый период времени, а t0 - время начала задания LP. –
Учебник/интервью ответ «детерминированный упреждение». Система гарантированно передаст управление в течение ограниченного периода времени, если процесс с более высоким приоритетом готов к запуску (в очереди на готовку) или утверждается прерывание (обычно входное внешнее по отношению к 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-системах наиболее важными параметрами, которые следует позаботиться, являются более низкие задержки и детерминизм времени. Что приятно делать, следуя определенным политикам и трюкам.
Принимая во внимание, что в GPOS, наряду с приемлемыми задержками, критическими параметрами являются высокая пропускная способность. вы не можете рассчитывать на GPOS для детерминизма времени.
У RTOS есть задачи, которые намного легче процессов/потоков в GPOS.
Важно также отметить разницу между мягкой системой реального времени и «жесткой» системой реального времени. – Thomas