Comments 29
В то время как ОС мягкого реальном времени — допускают выполнение задач с превышением указанного времени (только это приведёт к увеличению накладных расходов: потребности в повторной отправке пакетов, подтверждения их получения и т. д.)
Когда слышу про "мягкое реальное время", сразу вспоминается М.А.Булгаков:
«— Осетрину прислали второй свежести, — сообщил буфетчик.
Голубчик, это вздор!
Чего вздор?
Вторая свежесть — вот что вздор! Свежесть бывает только одна — первая, она же и последняя. А если осетрина второй свежести, то это означает, что она тухлая!»
это не совсем так, есть разные задачи с разными требованиями, например время вам вообще не важно - тогда Windows, если вам время важно очень тогда Vxworks, QNX а есть где важно, но если просрочите то катастрофы не будет, но будут убытки, тогда как раз и нужно "мягкое время".
И, кстати, реальное время это точно вовремя, не раньше и не позже, и одно из важнейших если не самое важное - это отсутствие зависания, ни мягкое ни жесткое реальное время их не допускают
но будут убытки, тогда как раз и нужно «мягкое время».Что за убытки?
Вообще-то я работаю с системами реального времени с начала 70-х годов прошлого века (компьютеры HP2100, ОС - RTE(Real Time Executive), языки программирования - FORTRAN и ассемблер). В те дремучие времена предложенных Вами систем и близко не было, а вот реальное время - да, было и без всякой мягкости и жёсткости. Выражение "мягкое реальное время" (не могу назвать это термином, так как не понимаю, что оно означает, вернее понимаю, что не означает ничего) появилось намного-намного позднее как маркетинговый ход, когда реального времени нет, а для продвижения продукта нужно, чтобы как бы было. Меня от этого выражения слегка тошнит (как от осетрины второй свежести :).
Что касается "реальное время это точно вовремя, не раньше и не позже" - не согласен, обычно имеют в виду гарантированное максимальное время реакции.
Насчёт "самое важное - это отсутствие зависания" - согласен, но к рельному времени это отношения не имеет.
Извините, но реальное время это именно точно вовремя, управляя механизмами сработать раньше ничуть не лучше чем сработать позже. По поводу отсутствия зависания - это тоже основополагающая характеристика именно систем реального времени, следующая просто из ее требований гарантии срабатывания не позже чем установлено
Извините, но реальное время это именно точно вовремя, управляя механизмами сработать раньше ничуть не лучше чем сработать позже.
Как раз часто, управляя механизмами, сработать раньше - намного лучше, чем сработать позже. Во многих случаях реакция системы происходит немедленно по наступлению события. Например было бы странно привязывать срабатывание пожарной сигнализации в школе ко времени окончания урока или при обнаружении пусков со стороны партнёров медлить с ударом возмездия. Здесь как раз важно максимальное время реакции, чтобы успеть провести эвакуацию или уложиться в подлётное время.
Что касается зависаний, то не должна зависать любая система (я думаю со мной согласятся многие пользователи). Для этого совсем не обязательно объявлять её системой реального времени, хотя бы и "мягкого".
под зависаниями наверное имелось в виду "freeze", типа как у винды - Отстань!, я в swap :)
Да, конечно есть системы где нужно сработать как можно раньше, но обычно системы управления объектами в реальном времени должны работать точно в указанное время. Классическим примером задачи, где требуется ОС РВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется и робот имеет лишь маленький промежуток времени, когда он может её взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он спозиционируется раньше, то деталь ещё не успеет подъехать, и он заблокирует ей путь. Система управления автомобилем и самолетом тоже требует сработать точно в указанное время, а не как можно раньше.
Очень интересно. Как же операционная система реального времени сработает точно в указанное время, если существуют прерывания, особенно вложенные прерывания? Или ваше "точное время" не очень точное и запаздывание в десяток наносекунд никому не повредит?
В ОС РВ есть понятие "квант времени", все реакции системы гарантируются только с точностью до кванта времени. Размер кванта зависит и от конкретной системы и, естественно, от машины на которой это реализовано. Лучше всего это описано "Введение в QNX Neutrino" (Роберт Кртен) это хоть и старая и про QNX но все основы любой ОС РВ там описаны очень хорошо и понятно, мне и близко так не сказать
В ОС РВ есть понятие "квант времени", все реакции системы гарантируются только с точностью до кванта времени.
Не совсем так. Это верно для прерываний от системного таймера. Для других прерываний (в частности от других таймеров) в нормальной ОС РВ управление передаётся в диспетчер немедленно, ну если оно не заблокировано по той или иной причине. Можно, конечно, просыпаться раз в системный тик и смотреть вокруг себя - а вдруг что-то происходило пока мы спали, но это прямая дорожка к "мягкому" реальному времени.
Извините, но Вы постоянно путаете минимально возможное время и системы жесткого реального времени. ОС РВ дают не минимально возможное время реакции, а дают гарантированное время реакции, а это далеко не одно и тоже. Более того, ОС РВ жесткого времени часто работают в среднем медленнее чем обычные системы и главное не то, что они быстрее а то, что они гарантируют время реакции. И вот именно это гарантированное время (оно в разных системах называется по разному) и есть главная их особенность. Кстати, так не любимые Вами системы "мягкого" времени как раз оптимизированы на минимальное в среднем время отклика, но не дают на него гарантии.
Еще один важный момент - этот самый квант времени жесткой ОС РВ обычно довольно велик, для базовой версии скажем QNX это 10 мксек. Можно задать (и задают) меньшие интервалы, но их соблюдение не гарантируется
Ну и Вы меня извините, про минимально возможное время я нигде не писал. Речь шла о гарантированном максимальном времени реакции.
Пример:
системный тик - 1 сек (специально утрирую),
по внешнему прерыванию запускается высокоприоритетный таск, который гарантированно отрабатывает за 0.35сек
Гарантированное максимальное время реакции - 0.35сек.
Другой пример (из жизни, под FreeRTOS на Cortex M4): системный тик - 1мсек,
по внешнему прерыванию запускается высокоприоритетный таск, который гарантированно отрабатывает за 0.35сек (делает преобразование Фурье).
Гарантированное максимальное время реакции - 0.35сек.
Вывод: Гарантированное максимальное время реакции никак (ну никак!) не зависит от периода системного таймера ("кванта времени ").
этот самый квант времени жесткой ОС РВ обычно довольно велик, для базовой версии скажем QNX это 10 мксек.
Ещё раз извините, Вы тут на три порядка не ошиблись?
Интересно, а как FORTRAN мог использоваться для реального времени? Там же нет никаких привязок ни к количеству циклов ни к прерываниям.
В упомянутые времена не было многозадачности, и реальное время можно было получить только используя либо С либо ассемблер, да и то необходимо было привязываться к таймеру, учитывать прерывания и даже при использовании одного и того же вычислителя можно было получить разные результаты из-за разных кварцев
В упомянутые времена не было многозадачности, и реальное время можно было получить только используя либо С либо ассемблер
Ну Вы даёте! Это утверждение из серии "'электрическую лампочку придумал Ильич" или "партия изобрела самолёты". Посмотрите на PDP8 (1965г.), IBM1800 (1964г.), PDP11(1970г.). Многозадачность имел даже флагман советской вычислительной техники БЭСМ6 (1967г.). Язык С в упомянутые времена только разрабатывался (1969-1973) и применения в народном хозяйстве ещё не получил.
Компьютер HP2100 (1971г.) имел вполне функциональный диспетчер реального времени с приоритетами и вытесняющей многозадачностью, некоторыми средствами коммуникации между задачами, системными вызовами, доступными из FORTRANа. Задачи могли быть как резидентными в оперативной памяти, так и загружаемые с диска (и свопируемыми на диск). Размер и количество задач ограничивались в основном оперативной памятью (32К 16-битных слов). Так как точности системного таймера (10мсек) для решаемых задач хватало, циклы никто не считал. По временной привязке наиболее критичной задачей была та, которая посылала в самодельный синтезатор очередную ноту, Мелодии проигрывались без искажений. Кроме музыки система использовалась для непрерывного приёма данных физического эксперимента, их записи на магнитую ленту, on-line мониторинга аппаратуры и выборочной обработки физической информации, для простого UI c графическим дисплеем и кнопочной клавиатурой, а также дя решения шахматных задач. Всё это крутилось одновременно на одном 16-битном процессоре с циклом 980нсек.
Производитель (Hewlett-Packard) поставлял диспетчер, компилятор с FORTRANа и загрузчик (линкер). Остальное (файловая система на диске, командный интерпретатор, текстовый редактор и др. утилиты) бало самописным (вестимо на FORTRANе) по мотивам многозадачной многопользовательской системы GEORGE4 для компютеров ICL1906A (1970г.).
Извините за много букв, приятно вспомнить молодость.
Зато потребление ресурсов этой системы намного меньше — 0,5 КБ оперативной памяти
Почему то про все rtos пишут что ОЗУ практически не требуется. По факту, если надо крутить например 2 задачи и как то между ними взаимодействовать, то это сразу 5-10 кб ОЗУ. При этом, в случае с freertos при нехватке кучи будет вываливаться исключение без пояснений в чем проблема.
Уже как несколько лет появились стильные модные молодежные rtos: Azure RTOS и Zephyr RTOS, первая от майкрософт, имеет кучу всяких сертификатов безопасности, но платная. Беспатно она доступна только для STM, как я понял они ее решили использовать на замену фриртоса. Вторая поддерживается сообществом linux, бесплатная, но из крупных вендоров ее поддержали Nordic и NXP. Вот про них куда интереснее что то почитать
Почему то про все rtos пишут что ОЗУ практически не требуется. По факту, если надо крутить например 2 задачи и как то между ними взаимодействовать, то это сразу 5-10 кб ОЗУ
Есть csmRTOS, с примерно такими же возможностями, как и фриртос. Которую запускали на 256 байтах ОЗУ. На atmega128 (4 кБ) вполне успешно крутится с десяток задач.
Ну а почему бы и нет? Конечно, можно обойтись и без неё, точно так же, как и без freertos на stm-ах, и всё написать на одном глобальном цикле. Но с осью всё равно немножко поприятнее организовывать межзадачную передачу данных, да и жестко заданная периодичность вызова процессов часто весьма удобна. Так что если небольшая ось без особых проблем влазит в кристалл, то почему бы и не да.
в случае с freertos при нехватке кучи будет вываливаться исключение без пояснений в чем проблема.
Работать с freertos можно не пользуясь кучей, а создавать все статически. Например, для создания таски для этого есть ф-ия xTaskCreateStatic(). Для остальных сущностей - тоже см. ф-ии с суффиксом 'Static'.
Уже как несколько лет появились стильные модные молодежные rtos: Azure RTOS и Zephyr RTOS
Как это часто бывает, "стильные, модные молодежные" содержат больше шероховатостей и недоработок в силу того, что у сообщества было меньше времени набить шишки и отрепортить разработчикам.
Насчет Zephyr - так вообще в плане потребления памяти уступает. Если у вас меньше 150кб ROM, то собрать получится только крайне ограниченную конфигурацию, без сетевых стеков и консолей и прочего.
Да про static понятно, но насколько я знаю в релизах за последние пару лет желательно использовать динамическую память. Например uC OS умеет вменяемые ошибки выдавать в случае проблем.
У Azure RTOS вполне есть шансы занять заметную долю RTOS, ее вместо Freertos начали применять STM. Microchip и Renesas тоже начали применять Azure для новых контроллеров. Плюс у этой RTOS куча всяких сертификатов безопасности и надежности, т.е. эту RTOS вполне можно будет применять для ответственных областей
Я бы предложил не использовать слово микроконтроллер для крупных мощных кристаллов. Как то это вводит в заблуждение. Автору спасибо за статью!
FreeRTOS — операционная система реального времени