Комментарии 14
К сожалению, ни о чём. Постов про FreeRTOS на хабре предостаточно.
RTOS не обязательно компилируется вместе с исполнимым проектом: часть RTOS могут динамически загружать программы.
QNX — это не UNIX и никогда им не была, если не ошибаюсь. Она стала POSIX-совместимой в 4 версии. Потом были улучшения совместимости с Linux и FreeBSD, которые произошли в QNX Neutrino.
Бывает мягкое и жесткое RT. Современные mainstream OS в той или иной степени являются системами с мягким realtime (например, воспроизведение звука, декодирование видео или изохронная передача данных являются задачами мягкого реального времени).
Дальше разбирать лень.
RTOS не обязательно компилируется вместе с исполнимым проектом: часть RTOS могут динамически загружать программы.
QNX — это не UNIX и никогда им не была, если не ошибаюсь. Она стала POSIX-совместимой в 4 версии. Потом были улучшения совместимости с Linux и FreeBSD, которые произошли в QNX Neutrino.
Бывает мягкое и жесткое RT. Современные mainstream OS в той или иной степени являются системами с мягким realtime (например, воспроизведение звука, декодирование видео или изохронная передача данных являются задачами мягкого реального времени).
Дальше разбирать лень.
+21
Статья вызывает ощущение, что такие явления как планировщик, приоритет процессов, семафоры, применяются только в ОСРВ. Если поменять «ОСРВ» на «Многозадачные ОС общего назначения», то в разделе про особенности появится не так уж много неточностей. Так является ли все это особенностями ОСРВ?
Взять даже слова о функциях. Если верить статье, вместо них используются процессы. И дальше идет описание процессов, самых обычных, всем известных. Но если это действительно процесс в привычном понимании, то о каких функциях шла речь? И отличается ли этот процесс чем-то от процесса в ОС общего назначения?
И да, не стоило разбивать статью на части.
Взять даже слова о функциях. Если верить статье, вместо них используются процессы. И дальше идет описание процессов, самых обычных, всем известных. Но если это действительно процесс в привычном понимании, то о каких функциях шла речь? И отличается ли этот процесс чем-то от процесса в ОС общего назначения?
И да, не стоило разбивать статью на части.
+5
[оффтоп]Оформление заголовков[/оффтоп]
Вообще не упоминули главного в операционных системах реального времени, как и в любых программах реального времени — функции в них выполняются за промежуток времени, который меньше, чем поступление новых данных. Если же она не успела, то тут два варианта — либо обработать эти данные, но пропустить следующие (или сложить в буфер, но тогда появится задержка), либо оборвать текущую операцию и обрабатывать новые данные.
Ну и «реагирующая на внешние события» — не совсем так. Как правило, в таких системах, как вы верно заметили, крутится вечный цикл, который и снимает показания датчиков. Внешних событий особо таки нет, разве что как раз прерывания (по таймеру, в основном).
Мне вот, к слову, стало интересно, как он может реагировать на внешние события в момент их поступления не по прерываниям?
Вообще не упоминули главного в операционных системах реального времени, как и в любых программах реального времени — функции в них выполняются за промежуток времени, который меньше, чем поступление новых данных. Если же она не успела, то тут два варианта — либо обработать эти данные, но пропустить следующие (или сложить в буфер, но тогда появится задержка), либо оборвать текущую операцию и обрабатывать новые данные.
Ну и «реагирующая на внешние события» — не совсем так. Как правило, в таких системах, как вы верно заметили, крутится вечный цикл, который и снимает показания датчиков. Внешних событий особо таки нет, разве что как раз прерывания (по таймеру, в основном).
Мне вот, к слову, стало интересно, как он может реагировать на внешние события в момент их поступления не по прерываниям?
+1
Вообще не упоминули главного в операционных системах реального времени, как и в любых программах реального времени — функции в них выполняются за промежуток времени, который меньше, чем поступление новых данных.Это не свойство ОСРВ. Первичное свойство RTOS — предсказуемое время реакции на событие. Допустим, при ниспадающем фронте на ноге необходимо выполнить какое-либо действие гарантированно за время не более, чем 10ms (если говорить про жесткий realtime, в мягком — желательно выполнить не более чем). А успели или нет обработать данные — вопрос вторичный. Например, может быть пропуск цикла из-за того, что выполнялась более приоритетная задача.
Как правило, в таких системах, как вы верно заметили, крутится вечный цикл, который и снимает показания датчиков. Внешних событий особо таки нет, разве что как раз прерывания (по таймеру, в основном).В части систем контроллер спит большую часть времени (для снижения энергопотребления), пробуждаясь по внешнему событию: обработка происходит по прерыванию. Кроме того, прерывания часто позволяют реализовать приоритеты обработки.
В части процессоров, например, АЦП может запускаться таймером без участия ядра и вызывать прерывание по готовности результата (чтобы не заниматься busy-wait'ом).
Системный таймер при использовании ОС с вытеснением потоков (preemptive) есть всегда, чтобы передавать управление ядру и, соответственно, планировщику. Та же FreeRTOS может использовать кооперативную модель, тогда таймер (как и планировщик =)) не нужен.
+2
Первичное свойство RTOS — предсказуемое время реакции на событие
На мой взгляд — это одно и то же. Зная время реакции мы можем подобрать квантование данных по времени таким образом, чтобы наша функция укладывалась в эти промежутки (и, соответственно, зная, с какой частотой нам нужно обрабатывать данные, мы можем подобрать процессор и алгоритм, чтобы он успевал их обрабатывать). Нельзя назвать программу программой реального масштаба времени, если она обрабатывает данные минуту, а они поступают каждую секунду, даже если нам точно известно время реакции на событие.
P.S. Промахнулся. Это ответ к habrahabr.ru/post/208780/#comment_7190210
0
Хотя, каюсь, немного не так понял вопрос. Действительно — уложиться в отведенный промежуток времени задача программы (функции), а не ОС. Задача ОС — дать предсказуемое время выполнения этой функции. Что-то с утра еще не проснулся.
0
Да, ради этого иногда используются naked функции, считают за сколько тактов процессор передаст управления обработчику прерывания.
Например, в ARM Cortex-M вход и выход в/из обработчика прерываний — максимум 12 циклов (при отсутствии задержек выборки инструкции), если сработало несколько — переключение между обработчиками — не более 6 циклов. За это время ядро успевает: сохранить состояние регистров на стэк, выполнить выборку, дешифровку и поставить на исполнение первую инструкцию обработчика.
Например, в ARM Cortex-M вход и выход в/из обработчика прерываний — максимум 12 циклов (при отсутствии задержек выборки инструкции), если сработало несколько — переключение между обработчиками — не более 6 циклов. За это время ядро успевает: сохранить состояние регистров на стэк, выполнить выборку, дешифровку и поставить на исполнение первую инструкцию обработчика.
0
НЛО прилетело и опубликовало эту надпись здесь
Если это вводные слова к циклу — то ничего, более-менее. Если это первая из двух, где в таком же объеме и формате нам расскажут про мьютексы, да еще и практика будет… Тогда, извините, но это ни о чем. Это констатация факта о существовании ОСРВ.
Авансом поставил плюсик, надеясь на лучшее. Хотелось бы в частности почитать, в каких случаях какую ОСРВ предпочесть, и зачем она таки нужна, особенно если можно обойтись без многозадачности. А то из поста следует, что поддержка многозадачности — единственная причина. Ибо «Во-вторых она очень легкая и почти не требует ресурсов» — а без нее вообще не надо на нее ресурсов, и «почти» — это сколько в граммах? «В-третьих все вышесказанное мы можем получить практически на любом железе» — и что? Если можно — не значит нужно. «В-четвертых: просто поиграться» — мне бы поработать, и я задумался было — а оно мне надо? А то до сих пор обходился, а вдруг с ОСРВ реально лучше будет? Ответа не получил.
Авансом поставил плюсик, надеясь на лучшее. Хотелось бы в частности почитать, в каких случаях какую ОСРВ предпочесть, и зачем она таки нужна, особенно если можно обойтись без многозадачности. А то из поста следует, что поддержка многозадачности — единственная причина. Ибо «Во-вторых она очень легкая и почти не требует ресурсов» — а без нее вообще не надо на нее ресурсов, и «почти» — это сколько в граммах? «В-третьих все вышесказанное мы можем получить практически на любом железе» — и что? Если можно — не значит нужно. «В-четвертых: просто поиграться» — мне бы поработать, и я задумался было — а оно мне надо? А то до сих пор обходился, а вдруг с ОСРВ реально лучше будет? Ответа не получил.
+1
Ну и в рамках коммунистической программы ликвидации безграмотности: сайт оФициальный. Простите, что не в личку
+1
GNU/Linux тоже можно использовать как ОСРВ, но это отдельная тема
0
С мягким RT? Если с жестким и это не RTLinux — расскажите подробнее.
0
Имел ввиду с мягким RT.
C жестким RT нашел еще один проект Advanced Real-Time Linux (ART-Linux).
Не являюсь специалистом по ОС и тем более по ОСРВ, поэтому подробнее не будет.
Сам желаю увидеть статью о RTLinux на хабре.
C жестким RT нашел еще один проект Advanced Real-Time Linux (ART-Linux).
Не являюсь специалистом по ОС и тем более по ОСРВ, поэтому подробнее не будет.
Сам желаю увидеть статью о RTLinux на хабре.
0
>1)Довольно-таки сложный процесс портирования на новое железо.
Хотел бы я тогда посмотреть на легкий процесс. У FreeRTOS, по-моему, самый простой процесс портирования, который только возможен — у нее вообще отсутствует HAL для периферии, есть только абстракция на таймер, собственно, это и есть единственная ее часть, которую нужно портировать.
Хотел бы я тогда посмотреть на легкий процесс. У FreeRTOS, по-моему, самый простой процесс портирования, который только возможен — у нее вообще отсутствует HAL для периферии, есть только абстракция на таймер, собственно, это и есть единственная ее часть, которую нужно портировать.
+2
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Операционные системы реального времени для начинающих