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

Я использую среду IDE NetBeans 7.3, и это то, как я делаю централизацию своего JFrame. Убедитесь, что вы нажмете на панель JFrame и перейдите в панель свойств JFrame, щелкните по строке кода и установите флажок «Создать центр».

26
задан Autodidact 11 February 2009 в 22:11
поделиться

10 ответов

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

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

Некоторые средства RTOS обеспечьте:

  • Основанный на приоритете Планировщик
  • Системная стандартная программа Прерывания по синхроимпульсам
  • Детерминированное поведение

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

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

самая высокая приоритетная задача в системе будет иметь ЦП до:

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

Как разработчик, это - Ваше задание для присвоения приоритетов задачи, таким образом, что сроку успеют.

Системные стандартные программы Прерывания по синхроимпульсам

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

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

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

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

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

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

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

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

29
ответ дан Alex W 25 September 2019 в 07:42
поделиться

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

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

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

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

2
ответ дан Sesh 25 September 2019 в 07:42
поделиться

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

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

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

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

2
ответ дан Adam Hawes 25 September 2019 в 07:42
поделиться

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

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

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

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

0
ответ дан ChrisW 25 September 2019 в 07:42
поделиться

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

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

0
ответ дан mouviciel 25 September 2019 в 07:42
поделиться

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

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

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

-1
ответ дан Spence 25 September 2019 в 07:42
поделиться

You might find it helpful to read the source of a typical RTOS. There are several open-source examples out there, and the following yielded links in a little bit of quick searching:

A commercial RTOS that is well documented, available in source code form, and easy to work with is µC/OS-II. It has a very permissive license for educational use, and (a mildly out of date version of) its source can be had bound into a book describing its theory of operation using the actual implementation as example code. The book is MicroC OS II: The Real Time Kernel by Jean Labrosse.

I have used µC/OS-II in several projects over the years, and can recommend it.

2
ответ дан 28 November 2019 в 07:33
поделиться

... ну ...

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

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

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

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

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

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

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

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

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

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

0
ответ дан 28 November 2019 в 07:33
поделиться

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

0
ответ дан 28 November 2019 в 07:33
поделиться

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

0
ответ дан 28 November 2019 в 07:33
поделиться
Другие вопросы по тегам:

Похожие вопросы: