Многообразный мир embedded systems и место Embox в нем

    Проекту Embox уже исполнилось 9 лет, но многие не понимают, что это такое и с чем его едят зачем он нужен. Некоторые из тех, кто слышал о проекте и знают, что это операционная система, считают, что Embox — это “отечественная ОС”. Действительно, задумывался Embox как попытка сделать “свою” ОС с “блекджеком и шлюпками”, но главное — это “блэкджек и шлюпки”. То есть, во главу угла ставились некие характеристики или их сочетание, которых не хватало в других проектах.

    Конечно, писать универсальную ОС даже с какими-то фишками никто не собирался. Слоган Embox — “Essential toolbox for embedded development” — подразумевает, что проект нацелен на embedded systems. Однако данное понятие очень широко, к нему относят: интернет вещей (IoT) и роботов, различные малинки (RaPi) и бортовые системы, ардуинки и АСУ-ТП, …. Список, как вы понимаете, можно продолжать очень долго, в нем есть места, где прекрасно живет Linux, а есть места, где Linux избыточен и используются различные маленькие RTOS. В данной статье я хотел бы поговорить об embedded-мире во всем его многообразии, ну и о месте Embox в нем.

    Одноплатные компьютеры


    Промышленные компьютеры


    Начнем с одноплатных компьютеров. Многие из них выполнены в промышленном исполнении. Большинство построены на процессорах с архитектурами ARM и x86. Многие думают, что x86-процессоры не используются в данном сегменте, а все ограничивается малинками, биглбордами, бананами и так далее. Но задолго до RaPi были другие одноплатные машины, нацеленные на сегмент промышленных PC, так называемый форм фактор PC/104. Они уступали по производительности обычным десктопам, ведь предназначались для задач, в которых надежность превалирует над функциональностью. По той же причине Linux не часто использовался в качестве ОС для этих аппаратных платформ, там были различные проприетарные ОС со свойствами реального времени (VxWorks, QNX, LynxOS и так далее ). Я не написал «ОСРВ» (к коим я отношу все три приведенных ОС) из тех соображений, что довольно часто на этих аппаратных платформах располагался Windows CE и его развитие Windows Embedded. И отнести весь этот зоопарк к ОСРВ у меня язык не поворачиваются.

    Потребительские одноплатники


    Малинки же задали совсем другой тренд. Они, по сути, нацелены не на промышленные системы реального времени, а на потребительский сегмент, в котором ценится соотношение цена/функциональность, а по этому параметру малинки (и аналоги) существенно опережают своих конкурентов. Ведь при покупке за условные 30-50 долларов, вы получаете полноценный системник, с помощью которого вы легко средствами Linux сделаете устройство с довольно сложным функционалом. Это очень полезно для прототипирования или DIY. Плюс, конечно, малинку можно использовать как PC или маленький сервер. Поэтому часто в качестве ОС используются готовые дистрибутивы Linux, в первую очередь, конечно, Raspbian — Debian для Raspberry Pi, ну или дистрибутив со смешным для русскоязычных названием Pidora — Fedora для RaspberryPi. Для других аналогичных платформ также есть готовые дистрибутивы, предоставляемые как производителями оборудования, так и сообществами (производителями) ОС. Согласитесь, когда нужно сделать прототип, проще всего взять готовое, наставить пакетов, написать функционал на python. В результате быстро получить работающий прототип. Пример — робот, который распознает линию с помощью OpenCV.

    Linux в embedded-устройствах


    Но мир embedded гораздо шире, чем стандартные ARM-овые одноплатники. Более того, они составляют относительно маленькую часть устройств, и их основной вклад — это популяризация и упрощение входа в разработку устройств подобного класса. Серийные устройства создаются на базе тех же процессоров (систем на кристалле) или аналогичных, но платы проектируются под задачу (проект, устройство). Следовательно, стандартные дистрибутивы, как минимум, избыточны, ведь в них зачастую используется какой-нибудь менеджер пакетов, и можно легко доставить очень много всего интересного (но ненужного для решения конкретной задачи). Embedded-устройства же обычно поставляются с законченной функциональностью, и даже называется это firmware (прошивка). Для создания прошивок существует другой класс Linux-дистрибутивов. Подобные дистрибутивы позволяют “установить” нужные пакеты статически — собрав их в корневую файловую систему, а не динамически — с помощью менеджера пакетов из репозитория. Обычно эти дистрибутивы могут собираться не только прикладные приложения, и библиотеки, но и ядро в заданной конфигурации. А часто еще и кросс-компилятор, ведь компилировать на самом устройстве, как минимум не эффективно.

    Yocto project


    На сегодняшний день самым известным подобным дистрибутивом (проектом по созданию дистрибутивов) является Yocto project . Он в свою очередь основан на еще одном известном проекте OpenEmbedded, который является своеобразной системой сборки для дистрибутивов Linux. Если хочется использовать Raspberry Pi не как готовый маленький системник, а как кастомизируемое устройство с Linux, то прекрасным вариантом будет использовать Yocto или его аналоги. Лично я сильных преимуществ в использовании нестандартных дистрибутивов Linux со стандартными железками не вижу, но если планируется разработка похожих устройств или есть желание осваивать сами технологии, то подобный подход выглядит наиболее перспективным. Ведь пока разрабатывается специализированная железка, программисты могут разрабатывать и отлаживать свои части системы (алгоритмы, драйвера, библиотеки, …). Что сильно снижает время разработки, а следовательно и пресловутый TTM (time to market).

    OpenWRT


    Еще одним известным проектом по созданию прошивок на основе Linux является OpenWRT. Уверен, что те, кто развлекается с кастомизацией роутеров, про него слышали. На основе этого проекта для различных роутеров делаются прошивки, которые представляют из себя один бинарник, включающий и ядро, и корневую файловую систему. Использование firmware (а не универсальных дистрибутивов) в embedded-системах связано с идеей о том, что функциональность конечной системы известна на момент ее разработки, то есть даже если обновляется версия роутера, прошивка меняется целиком со всей функциональностью (или заменяется часть этой прошивки специальным образом). Устанавливать, например, офисные пакеты, обычно не нужно, а часто вообще запрещено, поскольку это может внести свою неопределенность. Такой подход позволяет кроме всего прочего существенно сэкономить на аппаратной части. Те же роутеры, например, имеют куда менее мощный процессор и куда меньший объем памяти, чем универсальные железки.

    Системы реального времени


    Возвращаясь к теме промышленных вычислителей необходимо обсудить термин — “система реального времени”. Многие считают, что системы реального времени более быстрые. Это заблуждение. Вероятно, связано оно с историческими предпосылками. Ведь сам термин возник, когда машины были медленные. И пользователь замечал, что реакция системы может отставать от его действий. Термин “реальное время” означал, что система должна была быть отзывчивой на любые воздействия, в том числе действия оператора. Но на современных вычислительных машинах пользователь (оператор) вряд ли заметит торможение. В подавляющем большинстве случаев, при нажатии на менюшку, иконку, кнопку, мы сразу увидим перерисовку экрана, если конечно все в порядке (интернет есть, процесс не завис и т.д.). А вот если случилось что-то непредвиденное, например, связь пропала, мы увидим, чем отличаются (должны отличаться) системы реального времени. Обычный смартфон мы просто перезагрузим. Но если эта система управляет электростанцией, то сами понимаете, такое не всегда возможно. Отсюда делаем вывод, что система реального времени должна предсказуемо, а не быстро, реагировать на любое событие или совокупность событий, вне зависимости от своего состояния и окружения.

    Linux в системах реального времени


    Естественно, были (есть и будут) попытки сделать из Linux систему реального времени. Самая известная — это RTLinux, изначально это был патч к Linux, заменяющий оригинальный “полностью честный планировщик”, точнее вставляющий собственный, который одной из задач ставил планировщик Linux. Данный планировщик работал по статическим приоритетам задач, соответственно работал гораздо предсказуемее. Но это был уже не Linux, точнее функциональность Linux была не в режиме реального времени.

    ARINC-653


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

    uCLinux


    Попытки применить Linux во встроенных системах начались давно. Одной из первых была попытка использовать Linux в системах, где нет аппаратной поддержки виртуальной памяти (MMU). Данный проект назывался uCLinux и его вкладом в ядро Linux стал режим NOMMU или MMU-less.

    Linux в системах реального времени


    Подводя небольшой итог под попытками использования Linux в системах реального времени, нужно ответить на вопрос, почему же так происходит. То есть с одной стороны Linux не особо (на данный момент и в чистом виде) приспособлен для систем реального времени, а с другой — постоянно происходят попытки сделать это. Причем это происходит за счет внесения ограничений (замена планировщика, внесение гипервизора, ограничения на использование виртуальной памяти и так далее). Ответ, на мой взгляд, таится в наличии у Linux гигантской кодовой базы. Это и драйвера, это и функциональные приложения и библиотеки. Очевидно, что если хочется создать надежную систему, следует как можно больше использовать готовые части, ведь разработка новых, будь то функциональная логика или драйвер, всегда содержит вероятность внесения ошибки. А поскольку к современным системах реального времени предъявляют достаточно высокие требования по функционалу, то переиспользование готового функционала из Linux становиться все более соблазнительным. Иными словами, доработка Linux до системы реального времени уже не кажется такой уж затратной по сравнению с разработкой функциональности, пусть и на основе операционной системы реального времени, ведь надежностью должна обладать вся система, а не только ее часть в виде ядра операционной системы.

    Windows в embedded-устройствах


    Хочу ненадолго вернуться к Windows. На заре моей карьеры у меня случилась дискуссия с более опытным разработчиком о том, что Windows нельзя использовать в надежных системах. На что он возразил, что если протестировать уже законченную систему с необходимым функциональным программным обеспечением, и запретить любые изменения: обновления, установку ПО и т. д., то система будет достаточно надежной для многих задач, в том числе и для той, которую мы решали. Сейчас у меня нет сомнений, что мой оппонент был прав, а не я. Более того, даже древний MS-DOS очень долгое время использовался в промышленных системах. Дело в том, что многозадачность, которая кажется такой необходимой, вносит неопределенность. А если запускать ПО, которое полностью контролирует всю систему, то можно добиться куда большей детерминированности поведения. Иными словами, если в системе крутиться неопределенное количество задач, то добиться определенности в работе всех функций системы, вряд ли удастся. Поэтому самым простым способом для увеличения предсказуемости системы является ограничение ее функциональности, а следовательно — отказ от универсальности во время исполнения. Что мы, собственно, и наблюдаем в упомянутых выше примерах использования Linux в системах реального времени.

    Микроконтроллеры


    Пример с MS-DOS в качестве базовой ОС для промышленных систем реального времени приводит нас к мысли, что если использовать только свое ПО, то можно добиться предсказуемого поведения всей системы. И это действительно так! Правда, нужно сделать оговорку, что это возможно только если функциональность системы небольшая и четко зафиксированная. Если вся функциональность системы заключается в управлении мотором с помощью GPIO и получением (передачей) ограниченного набора команд по UART-интерфейсу, то не обязательно использовать ОС, можно создать прошивку (то, что называется bare-metal). Этот подход достаточно часто используется в микроконтроллерах. Но поскольку и микроконтроллеры стали большим (32-битный ARM с несколькими кБ ОЗУ против 8 битных AVR-ок с сотней байт ОЗУ), то и запросы по функционалу выросли. Сейчас при разработок прошивок используют как минимум ПО от производителей, которое позволяет использовать какие-то готовые примеры для работы с микроконтроллером, например STM32Cube.

    RTOSes


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

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

    FreeRTOS


    Наверное, одной из самых популярных проектов RTOS сейчас является FreeRTOS. Некоторые говорят, что это не полноценная ОС, а только планировщик. Но если учесть приведенные выше рассуждения о bare-metal, большое количество поддерживаемых микроконтроллеров и то, что написано и интегрировано много прикладного ПО, то небольшой функционал выглядит скорее как достоинство, чем недостаток. Это и позволило стать де-факто стандартом для микроконтроллеров, как написано на сайте проекта.

    Contiki


    Contiki — RTOS, разработанная Адамом Данкелсом (Adam Dunkels), создателем таких известных TCP/IP стеков, как lwIP и uIP. Я бы сказал, что вокруг сетевого стека и построена вся ОС. Наличие поддержки IPv6 и небольшие требования по ресурсам делает этот проект интересным для создания различного рода беспроводных устройств.

    RTEMS


    RTEMS Real-Time Executive for Multiprocessor Systems. Изначально разрабатывалась для военных, акроним расшифровывался как Real-Time Executive for Missile Systems, а затем Real-Time Executive for Military Systems. Довольно старый, но еще живой открытый проект. Яркий представитель подхода libOS. Когда разрабатываемое ПО линкуется с уже собранной ОС, которая представляет из себя не только ядро, но и все доступные службы. Компилируется и поставляется в качестве библиотеки к компилятору, что довольно удобно на ранних стадиях разработки.

    eCos


    eCos Embedded Configurable Operating System. Так же довольно старый проект, ранее очень популярный. Основная идея — сделать очень конфигурируемую ОС, то есть включать в ядро только то, что нужно.

    Другие RTOSes


    Список можно продолжать довольно долго. Об еще одном проекте NuttX упомяну ниже. А тем, кому интересен более подробный список советую посмотреть википедию. Для микроконтроллеров я бы еще отметил ChibiOS/RT, MicroC/OS (µC/OS), Nut/OS, RIOT. Но конечно, все зависит от задачи.

    Arduino


    Думаю разговор об embedded был бы неполным без упоминания Arduino. Ведь как и RaPi они очень распространены и сильно способствовали популяризации микроконтроллеров. Сам я довольно скептически отношусь к теме arduino, поэтому пропущу критику фанатов данной технологии. А вот по поводу того, что это очень интересная технология, могу привести пример хлебопечки, описанный на хабре. Очень приятное решение. Ну или уже приведенный пример с роботом, распознающим линию по openCV, да там также используется arduino.

    Микроядро


    Я еще ни разу не упомянул о концепции микроядра, которая, как многие знают, делает систему надежной и предсказуемой. Это с одной стороны правда, а с другой, как всегда, не совсем. Точнее, конечно правда, но вера в то, что данная концепция (архитектура), сразу превратит вашу систему в систему жесткого реального времени — заблуждение. Это скорее такой маркетинговый слоган: «мы система реального времени потому, что построены по принципу микроядра». Но ведь принцип микроядра всего лишь позволяет упростить разработку ПО, так как большинство частей выносится в пользовательское пространство. Но что делать, если у вас сломался какой то сервер, необходимый для работы? Вы его перезагрузите, но на это требуется время, а если у вас его нет? К тому же, классическая микроядерная архитектура имеет и свои недостатки! Она, например, медленная, поскольку происходит очень много системных вызовов (передач сообщений между серверами и прикладным ПО). Иначе бы все давно перешли на чистую микроядерную архитектуру, а кто, например, видел проекты на L4, а они есть. Ну, и конечно, многие помнят спор Линуса Торвальдса с Эндрю Таненбаумом.

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

    Место Embox в мире embedded systems


    Я уже довольно много рассуждал о разных аспектах embedded-мира, но так и не добрался до места Embox в нем. Ну что же, могу сказать, что в описанных выше примерах, возможно и нет необходимости применять Embox. Более того, обычно мы пользователей спрашиваем, зачем им нужен Embox? Если применение Embox не дает никаких преимуществ, мы советуем попробовать, что-нибудь из списка выше или ещё что-то (например, Android). Но есть ряд случаев, в которых применение Embox дает ощутимый выигрыш.

    Система для разработки оборудования


    Начну с первого применения Embox. Он тогда еще даже не был Embox-ом, а представлял из себя некий Си и ассемблерный код, который позволял очень быстро запуститься и выполнить утилитарный код. В тот момент это был проект для помощи инженерам в отладке аппаратуры, разрабатываемой на ПЛИС-ах. Он умел очень быстро запускаться, гораздо быстрее, чем аналогичный код, написанный с помощью уже упомянутого RTEMS. Это важно, поскольку он использовался еще и на этапе потактовой симуляции. Плюс его стали применять и на реальном “железе”, для этого был написан небольшой интерпретатор, который умел вызывать пользовательские команды. Позже данное направление получило развитие, и был портирован интерпретатор языка TCL, поскольку он привычен для разработчиков ПЛИС. А так как в определенной конфигурации команды имеют прямой доступ к оборудованию (ко всему адресному пространству), то разработчики получили возможность делать достаточно сложные тесты.

    Сертифицируемый Linux


    Одним из первых сторонних применений было довольно специфическое требование на сертифицированность кода. Было некое устройство, обладающее ограниченным функционалом, включающим в себя: работу с сокетами (UDP), файловой системой, и еще некоторый функционалом. Весь функционал был реализован заказчиком как ПО на базе Linux. Данное устройство было не x86 и не ARM. Имело свою периферию. Требовалось сертифицировать код, который используется в устройстве, поскольку сертифицированные дистрибутивы там не могли быть использованы. Попытка обрезания ядра Linux, привела к порядка 500 тыс. строк кода, плюс ещё были проблемы с #ifdef и другими макросами. И заказчик, оценив стоимость сертификации данного изделия, попросил рассмотреть другие варианты. Embox на тот момент уже имел сетевой стек, файловую систему и было принято решение доработать его с учетом требований сертификации. Так у нас появился язык описания модулей Mybuild, мы в какой то степени решили проблему с макросами, некоторые другие проблемы. В итоге мы добились того, что в конечном образе у нас находится только используемый (заявленный в конфигурации) код, а его для конкретной задачи обычно требуется не очень много.

    Linux без Linux


    Направление с сертификацией вообще довольно популярно. Достаточно часто заказчики имеют код под Linux, но по каким-то причинам не могут использовать на своем устройстве данную ОС. У Embox же есть возможность достаточно легко переносить прикладное ПО из открытых проектов под Linux. Таким образом были портированы ряд популярных проектов, даже Qt (embedded-версия) или уже описанный на хабре SIP-телефон . При этом, поскольку при использовании Embox включаются только требуемые модули, ресурсов для запуска требуется куда меньше.

    Идея запускать POSIX-приложения на системах с небольшими ресурсами является основной для ещё одного открытого проекта — NuttX. В каких-то моментах данный проект превосходит Embox, в каких-то — наоборот. Примеры с Qt и SIP-телефоном, насколько я знаю, NuttX не по зубам. Но проект действительно очень интересен.

    Также стоит отметить, что часть RTOS тоже добавляют прослойку POSIX. Например, FreeRTOS или RTEMS, который на сегодняшний день полностью соответствует POSIX Profile 52, означающему «один процесс, много потоков, файловая система». На RTEMS даже делают успешные эксперименты по запуску Qt на микроконтроллерах

    Безопасный Linux


    Если несколько с другой стороны взглянуть на статическую сборку образа маленьких RTOS, то есть всю функциональность определить на момент создания, то можно заметить, что получается естественная защита от вредоносного кода, то есть вирусов. Конечно, в Linux можно сделать очень хорошую систему безопасности, но всё-таки основные проблемы с безопасностью связаны с человеческим фактором (слабые пароли, утеря пароля, повышение прав пользователя и т.д). То есть, при получении рутовых прав, вся защита, по сути, становится не актуальной и можно установить, что угодно куда угодно. В случае же статической сборки злоумышленник может пользоваться только уже имеющимся функционалом. Да, он, возможно сможет получить статистику или сделать какую-то настройку, но, согласитесь, это куда меньшее зло, чем в случае установки вредоносных программ. Плюс, на универсальных системах стоимость системы защиты, скажем так, не нулевая. В нашем же случае это достается гораздо дешевле, поскольку заложено уже на этапе проектирования.

    Linux реального времени


    Я довольно много посвятил вопросу использованию Linux в качестве системы реального времени. Объяснил почему этого трудно достичь, а также почему попытки предпринимаются. Так вот, вернемся к уже приведенной ссылке на статью о роботе с распознаванием линии по OpenCV. Если заглянули по ссылке, то возможно обратили внимание, что OpenCV крутится на RaPi, а управление моторами происходит на отдельной плате Arduino. На это есть пара причин: первая — планировщик, вторая — то, что управление происходит из пользовательского режима, а в нем у Linux нет доступа к оборудованию. Как вы наверное догадались, в Embox обе проблемы можно решить гораздо проще чем в Linux. И на одной плате с достаточными ресурсами можно и OpenCV запустить, и моторами управлять.

    Было несколько устройств, которые сочетали в себе функциональность Linux и работу в реальном времени. Пример — станок ЧПУ, который управлялся по веб-интерфейсу, коротко описанный мной в статье. Ну и если мы делаем роботов на нескольких платах, то это мультиагентные системы.

    Internet of Things


    Embox, как и фактически все RTOS для микроконтроллеров, имеет низкие требования по ресурсам. Вот уже описанный на хабре пример игрушки на stm32vl-discovery. Запускался Embox даже на 16-разрядном MSP-430 c 512 байтами ОЗУ. Но если взглянуть, например, на код из статьи с игрушкой, можно заметить, что там используются не стандартные POSIX-потоки, а собственная реализация бесстековых потоков (light threads). Естественно, если пойти дальше и реализовать весь код самостоятельно, уверен, можно добиться и лучшего результата по затратам памяти. Но “умные” датчики это только одна из частей IoT. Они передают данные на какие то более мощные узлы. И делают они это по какому-то протоколу. Но если на этом узле тоже будет запущен Embox, и код библиотеки, реализующий протокол общения, будет общим, то это упростит разработку. Ведь во-первых, код общий, и даже если есть ошибка в реализации протокола, то она нивелируется тем, что один и тот же код будет работать на обеих сторонах общения. А во-вторых, код можно отладить на платформе с большими ресурсами, что куда более привычно и просто.

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

    Заключение


    Данная статья раскрывает лишь небольшой сегмент в многообразном embedded мире. Не упомянуты такие важные темы как бытовая техника, автомобили, приборостроение, АСУ-ТП. Но как я уже сказал в начале, в статье я хочу всего лишь “поговорить” об особенностях embedded. Надеюсь, статья была достаточно интересной, и прочитав ее, вы узнали что-то новое! И давайте обсудим особенности данной сферы в комментариях.

    P.S. Ну и да, Embox не только “embedded”, но еще и “opensource”. Так что, приглашаем использовать проект и конечно участвовать в нем!
    Embox
    79,00
    Открытая и свободная ОС для встроенных систем.
    Поделиться публикацией

    Похожие публикации

    Комментарии 74

      +1
      Многие считают, что системы реального времени более быстрые. Это заблуждение.… Ведь сам термин возник, когда машины были медленные. И пользователь замечал, что реакция системы может отставать от его действий. И пользователь замечал, что реакция системы может отставать от его действий. Термин “реальное время” означал, что система должна была быть отзывчивой на любые воздействия, в том числе действия оператора.

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

      Имеются ли примеры коммерческого применения ОС?
        0
        Спасибо! Абсолютно с Вами согласен. Вы выразили мысль лучше чем я!

        Моя мысль заключалась в том, что быстрота на каком то участке не показатель. Если у вас процесс где нужно время реакции 10 секунд, то непонятно зачем мерить время переключения процесса в микросекундах. Пусть он переключается раз в 100 миллисекунд, но зато надежно!
          0
          Имеются ли примеры коммерческого применения ОС?

          Да имеются!
          О нескольких, про которые можно писать, рассказывали на хабре. Но часто коммерческие работы под NDA. Следовательно, не можем о них рассказывать.
          0
          Embox, как и фактически все RTOS для микроконтроллеров, имеет низкие требования по ресурсам.


          Вы путаете Embedded OS и RTOS, между ними нет строгого знака равенства. Отсюда и весь посыл статьи заведомо ошибочен.
            0
            Извините, но я не понимаю почему посыл статьи ошибочен? В чем его ошибочность?

            И где я путаю ОСРВ и ОС для встраиваемых систем?
            Если Вы имеете в виду, что не нужно путать ОС для микроконтроллеров (RTOS) со встроенными OC (например yocto), то возможно Вы не прочитали статью, в ней разные варианты рассмотренны.
              +1
              Например, вот тут:

              И отнести весь этот зоопарк к ОСРВ у меня язык не поворачиваются.


              Все перечисленные как раз строго относятся к классу RTOS, а вот относятся ли они к Embedded OS или нет уже вопрос. И дальше по тексту просматривается устойчивая подмена Embedded OS термином RTOS.
                –1
                Позвольте, ну зачем же Вы выдираете фразу из контекста и затем заявляете, что дальше просматривается… То есть обобщаете ее на всю статью.

                Вас не смущает, что приведенная Вами фраза в разделе «Промышленные компьютеры»! А потом есть раздел «Linux в embedded-устройствах», а затем «Системы реального времени» и «Linux в системах реального времени»?

                Я попробую еще раз сформулировать мысль:
                Embedded очень широкий! Есть разные задачи в данной очень широкой сфере. Соотвественно есть и свои ОС. В этой очень широкой сфере можно выделить, в том числе «системы реального времени». У них соотвественно есть свои ОС, которые называются RTOS (обычно). Еще есть различные микроконтроллеры, на их основе также могут создаваться как системы с требованиями реального времени, так и системы, где просто требуются маленькие ресурсы (например для снижения стоимости или энергопотребления).

                Все еще, не вижу противоречий!
                  +1
                  Вы категорически неправы. Даже в последнем сообщении:

                  В этой очень широкой сфере можно выделить, в том числе «системы реального времени».


                  СРВ не есть подмножество Embedded. СРВ/ОСРВ — это исключительно ранжирование по предсказуемости реагирования на критические события. Можно свериться хоть с A.S. Tanenbaum «Modern operating systems», хоть с той же википедией в крайнем случае. Embedded же — это в первую очередь о количестве ресурсов и способах управления ими. Это как мягкое и холодное — концептуально не пересекающиеся множества, которые на практике где-то пересекаются, а где-то совершенно не обязаны. Отсюда, например, большая неточность в формулировке «где Linux избыточен и используются различные маленькие RTOS», где явно должно быть «Embedded OS» вместо «RTOS».

                  Возвращаясь к процитированному мной выше. Конкретно LynxOS, QNX и VxWorks лично вы на каких основаниях не можете отнести к RTOS, они замечены в нелояльности к предсказуемости реакции?
                    0
                    СРВ не есть подмножество Embedded


                    Хм, возможно я понял в чем наши разногласия.
                    Я вовсе не утверждал, что системы реального времени полностью входят в embedded systems!
                    Я утверждал, что если взять все множество embedded systems то в этом множестве будет часть которая требует свойств реального времени (то есть предсказуемости)

                    Конкретно LynxOS, QNX и VxWorks лично вы на каких основаниях не можете отнести к RTOS

                    Лично я не понимаю, почему Вы приписываете мне утверждения, которых я не делал!
                    Все таки прочитайте тот абзац, там прямо написано к кому есть притензии. К приведенным ОС как раз нет притензий в предсказуемости реакции. Но поскольку используются на данных аппаратных платформах разные ОС, в том числе например Windows CE (который, кстати, тоже заявлен как реального времени), то из этих соображений и написал, то что написал!

                      –1
                      что если взять все множество embedded systems то в этом множестве будет часть которая требует свойств реального времени (то есть предсказуемости)


                      Совершенно верное утверждение. Но по тексту с обсуждаемыми терминами вы обходитесь слишком вольно, противопоставляя одно другому. Пример противопоставления я уже приводил — «где Linux избыточен и используются различные маленькие RTOS».

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


                      Давайте разберем процитированное:
                      1. Проблем с предсказуемостью нет => (терминологически) они ОСРВ.
                      2. На тех же платформах используется WinCE => (цитата) «И отнести весь этот зоопарк к ОСРВ у меня язык не поворачиваются»

                      На основе родственности аппаратных ресурсов с WinCE вы делаете какие-то выводы относительно real-time-овости первых. Логика совершенно странная. Она могла бы еще присутствовать, если бы заключение делалось относительно принадлежности их к классу Embedded OS. О чем я изначально и сообщил — подмена Embedded OS на RTOS по тексту.
                        0
                        И все таки, не понимаю, как приведенные Вами отдельные куски противоречат общему смыслу статьи?

                        Давайте разберемся с приведенными цитатами.
                        «где Linux избыточен и используются различные маленькие RTOS»

                        На мой взгляд данная цитата никак не означает, чтов статье рассматриваются только ресурсы. А означает что в мире embedded есть и такая сторона, но ниже раскрываются и другие. В том числе параметры для систем реального времени, как один из сегментов (но не полностью включенный в embedded).

                        Следущее утверждение, что я исходя из родственности аппаратных ресурсов с WinCE, делаю заключение что QNX не является ОСРВ. Но я еще раз перечитал, но такого утверждения не вижу. Ибо весь зоопарк, я не хочу относить к ОСРВ, но как это означает что конкретно QNX это касается?
                        Ну давайте по другому. Есть зоопарк, там есть лошади, но сказать что это конюшня, я не хочу.

                        Вообще зачем было сначала приводить список, а потом делать пояснение почему я не хочу его называть ОСРВ? Мне кажется, только по одной причине, что в списке ОСРВ!

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

                          –1
                          Есть зоопарк, там есть лошади, но сказать что это конюшня, я не хочу.

                          Исходя из ниже процитированного также следует

                          Не стал рассматривать участников данного списка в разделе Системы реального времени, поскольку они проприетарные

                          Что у вас в зоопарк попадают не по принадлежности объекта к области интересов зоологии, а по наличию у него волосатой лапы среди руководства зоопарка. Но это конечно же лирика.

                          В целом логика у вас специфичная и на мой скромный профессиональный вкус весьма сомнительная.
                            +1
                            Что у вас в зоопарк попадают не по принадлежности объекта к области интересов зоологии, а по наличию у него волосатой лапы среди руководства зоопарка. Но это конечно же лирика.

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

                            В целом логика у вас специфичная и на мой скромный профессиональный вкус весьма сомнительная.

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

                            По поводу упомянутого Вами сравнения Linux маленькими RTOS, это опять же досадное совпадение, просто различные ОС для микроконтроллеров, называют RTOS, для отделения от классических RTOS в том числе QNX, я употребил эпитет «маленькие».

                            На мой взгляд, для указания на возможные несостыковки в логике стоит указывать в не столь категоричной форме. Просто возможно Вы чего то не поняли или не учли!
                              0
                              На мой взгляд, для указания на возможные несостыковки в логике стоит указывать в не столь категоричной форме

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

                              Up:…
                                0
                                категоричная форма, это ваши
                                Вы категорически неправы.

                                Хотя дальше идет утверждение которого я не делал!
                                Вот это, обычно, как раз признак непрофессионализма!
                                  0
                                  Там есть точная цитата. Или «афтар не читатель, афтар писатель»?
                                  0
                                  То есть Вы не указали не на одну ошибку, а только на свои домыслы. Ну вот Вы так поняли, но это не означает, что я это утверждал!
                                    0
                                    Я указал на достаточное количество неточностей по тексту. Составлять рукопись непротиворечивым однозначно трактуемым образом — дело автора, а не мое. Неспособность изложить свою мысль в данном аспекте сами понимаете что значит.

                                    На ошибки в логике в том числе с математической точки зрения ниже даны указания. Причем не все, а лишь малая достаточная часть.
                                  0
                                  Если можно, для полноты картины и дабы развеять впечатление о том, что вас заклинило на QNX. Проприетарные Integrity, OS-9, oc2000 (aka VxWorks), ОС «Эльбрус» — RTOS али !RTOS?

                                  А вот дальнейшая дискуссия по терминологии теряет всякий смысл, поскольку мой мозг безуспешно пытается усмотреть в этих утверждениях намеки на ассоциативность:

                                  Я не написал «ОСРВ» (к коим я отношу все три приведенных ОС)

                                  И отнести весь этот зоопарк к ОСРВ у меня язык не поворачиваются.
                                    0
                                    согласен дискуссия теряет всякий смысл ведь когда я изучал логику из высказываний
                                    A принадлежит N
                                    B принадлежит N
                                    R принадлежит N
                                    B не принадлежит R
                                    что A не принадлежит R
                                    где: A — это приведенные в списке ОС
                                    B — это windows
                                    R — множество RTOS
                                    N — множество embedded OS
                                      0
                                      R принадлежит N

                                      множество RTOS принадлежит множество не RTOS

                                        0
                                        Ой ну поймали конечно
                                        не «не RTOS» а embedded OS — если Вам так угодно
                                          0
                                          Операция «множество принадлежит множеству» не определена. Единственное о чем тут можно утверждать, что R ∩ N ≠ Ø.
                                            0
                                            дел
                                              0
                                              Вот и я о том же.
                                              Почему же Вы решили, что я написав, то что написал, имею в виду, нечно другое?
                                        0
                                        Мне кажется, что Вы, то ли читать не умеете, то ли не хотите.
                                        Я не понимаю почему Вы решили, что я в статье классифицирую ОС? Или я должен по вашему это сделать? Может если у Вас накопился богатый материал по данной теме, Вам стоит написать собственную статью? В ней Вы опишите какие ОС являются реального времени, а какие нет.

                                        Я же допустил себе высказать сомнения по поводу правильности выбора в качестве ОС для промышленных систем windows. но даже это свое утверждение я поставил объявил ложным (предвзятым) в разделе про windows.
                                          0
                                          Не меня заклинило на QNX, а Вас, напомнить про прерыдущее ваше утверждение, которое я вовсе не делал? Из статьи про портирование на Эльбрус
                                            0
                                            Усмирите свой генератор теорий заговоров. Я много о чем и с кем веду дискуссии, в том числе научные. Здесь же была дискуссия на тему корректного использования терминологии, а вы почему-то в который раз пытаетесь все сократить до единственного представителя класса. Не понимаю зачем, конкретно QNX и ОС «Эльбрус» обсуждали там и полно.

                                            Может если у Вас накопился богатый материал по данной теме, Вам стоит написать собственную статью? В ней Вы опишите какие ОС являются реального времени, а какие нет.

                                            Классики теории ОС уже все до нас написали (параграфы 1.4.6 и 1.4.8; параграфы 13.1 и 10.2) и для переосмысления этих положений нужны веские основания. «я художник, я так вижу» — это не к точным наукам, увы.
                                              0
                                              Предлагаю Вам усмирить свой генератор приписанных утверждений!

                                              Вы никак не можете понять, что до сих пор, не привели ни одного факта, который я бы не верно истолковвал. Единственное что Вы тут пишите, что в данном конкретном случае, вот если выдрать вот эти часть предложения, то оно будет не полным!
                                              Вы утверждаете, что я где то по тексту употребил не правильный термин, но не одно приведенное высказывание, не означает того что Вы мне приписываете!

                                              Если считаете, что какие то конкретные формулировки неточные, предложите свои, поэтому я и предложил написать статью. Предложение не писать, поскольку уже есть Таненбаум, ну как то странно. Ведь разъяснение его позиции своими словами, только улучшит понимание.

                                              Пока же никакой конструктивной информации я от Вас, к сожалению, не получил.
                                              Фразы, «вы категорически не правы», или «весь посыл статьи ошибочен», я не рассматриваю как конктруктивный
                                                +1
                                                Вы безнадежны. Второй день уже указываю вам на один огромный косяк по тексту, который даже лично вы выразили в рамках мат. логики:

                                                B не принадлежит R
                                                что A не принадлежит R

                                                Оба этих утверждения есть ложь. Это есть неоспоримая ошибка в логике и тексте. Для всего профессионального сообщества это неоспоренные факты. Более того, вы же сами об этом пишите в отредактированном тексте статьи:

                                                (к коим я отношу все три приведенных ОС)

                                                Процитированное — это явное, однозначное и неоспоримое противоречие с вашим же утверждением:

                                                B не принадлежит R

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

                                                  Спасибо, на указание на огромный косяк по тексту, думаю у читателя с мозгами, нет сомнений в том делал я такие заявления или нет.
                                                0
                                                Если Вы хотите подискутировать на тему правильно ли называть RTOS маленькие ОС для микроконтроллеров, то это не ко мне, я всего лишь использовал общепринятую терминалогию. Например FreeRTOS содержит RTOS в своем названии.
                                                Но это еще могло бы вылиться в какую то осмысленную дискуссию.
                                                А то пока это
                                                — вы неправы
                                                — почему
                                                — вы назвали то то и то то так то
                                                — позвольте, но я этого не говорил
                                                — нет говорили
                                                — где
                                                — ну я так понял
                                                  0
                                                  я всего лишь использовал общепринятую терминалогию. Например FreeRTOS содержит RTOS в своем названии.


                                                  Это не термин, это наименование. Facepalm
                                                    0
                                                    То есть Вы считаете, что все кто называет подобные ОС для микроконтроллеров RTOS, не правы?
                                                    Вот например сайт https://www.osrtos.com/ там список OpenSourceRTOS
                        +4
                        Вспоминая лекцию Максима Червинского(RIP),
                        ОСРВ — это такая ОС, в которой корректность выполнения задачи характеризуется не только логической корректностью, но временем выполнения этой задачи.
                        ftk.narod.ru/download/os/rtos-training-v1.5.pdf
                          0
                          Согласен.
                          В статье я попытался немного раскрыть тему и подумать о том как этого добиться. На мой взгляд нужно контролировать всю систему, все задачи в ней. То есть само по себе применение ОСРВ не гарантирует того, что вся система будет предсказуемой, но может помочь разработчику достичь этого.
                          +2
                          Самого главного нет в Embox — директории DOC.
                          Без документации система не юзабельна.
                            0
                            Спасибо, что напомнили :)
                            Мы решили вместо директории c документацией завести репозиторий. Там уже есть русская и английская версия quick_start, первую версию руководства пользователя выкатим в ближайшее время (надеюсь на ближейших выходных). Потом приглашаем всех задавать вопросы и высказывать пожелания чего не хватает. А то задача оказалось сильно сложнее чем думали.
                              0
                              Смартфоны тоже embedded, есть даже выражение Embedded Android.
                              А вот та же Rasbpian это не embedded система.
                                0
                                А вот та же Rasbpian это не embedded система.

                                Почему?
                                  0
                                  Ну наверное потому что там обычный линукс с пакетным менеджером и десктопом.
                                  Или по вашему убунту для ARM это тоже embedded?
                                  Rasbpian это десктопный линукс, это вроде как очевидно должно быть.
                                    0
                                    Мы говорим об аппаратной платформе или о программно-аппаратной платформе?
                                      0
                                      Rasbpian это десктопная операционная система и мы говорим о ней.
                                      На малине можно запустить Embedded Linux, например Yocto.
                                        0
                                        Так это же в статье есть.
                                        То есть в статье не сказано ничего про характеристики ОС, но сказано, что на малине часто используют такие то системы.
                                          0
                                          Я просто сказал, что Rasbpian обладает всеми признаками десктопной системы, но при этом не обладает признаками эмбеддед системы.
                                          Поэтому Rasbpian это десктопная система.
                                          Да и малина это больше одноплатный ПК, нежели эмбеддед.
                                          0
                                          Неправильно я поставил вопрос, хотя ответа на мой первый вопрос не прозвучало.
                                          Почему Rasbpian или Debian нельзя использовать во встраиваемых (embedded) система?
                                            0
                                            Их можно использовать в эмбеддед, но это десктопные системы.
                                            Сову можно натянуть на глобус, на виндоуз ХР можно запустить веб сервер для энтерпрайз и развернуть всю свою серверную инфраструктуру, но от этого она не станет серверной ОС.
                                            Обычно в эмбеддед у тебя нет гигабайта ОЗУ, 4х ядер по 1+ГГц, видеоадаптера и многих гигабайт дискового пространства.
                                            Поэтому эмбеддед системы обычно другие, по другому построены.
                                              0
                                              Тут я с Вами не соглашусь.
                                              Вот ребята MenMicro, Fastwel, RTD и многие другие делают сплошной embedded, а там и Xeon, и AMD Radeon, и Jetson, и многое другое.
                                                0
                                                Вы хотете сказать, что если сейчас я возьму свой MacBook, пропишу ему скрипт в автозагрузку и засуну всё это в ящик, то macOS тут же превратится из десктопной системы в embedded?
                                                И можно будет запилить статью на хабр, что богатый и разнообразный мир эмбеддед систем…
                                                  +1
                                                  Про Mac сказали Вы, но, если сделать некое специализированные решение (как минимум выкинуть всё лишнее) для конкретной задачи и оно будет удовлетворять заданным требованиям, то такое возможно.
                                                  Живет же прекрасно Window Embedded на каких-нибудь Core7.
                                                  Мир embedded многогранен…
                                    0
                                    Присоединяюсь к вопросу, Почему?
                                    А вот та же Rasbpian это не embedded система.


                                    С android во встроенных системах согласен. Но при на то он и многообразный, чтобы затрагивать очень много всего! А обо всем этом написать в одной статье вряд-ли возможно. Поэтому я не затронул не только андроид, который часто используется для медиа-систем автомобилей, но и такой проект как ITRON. Который является по сути дела стандартом де-факто для автомобилей (уже систем управления).
                                      0
                                      «Raspbian — основанная на Debian операционная система для Raspberry Pi.»
                                      Debian — не embedded система.
                                        0
                                        Поэтому часто в качестве ОС используются готовые дистрибутивы Linux, в первую очередь, конечно, Raspbian — Debian для Raspberry Pi, ну или дистрибутив со смешным для русскоязычных названием Pidora — Fedora для RaspberryPi.


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


                                        Мне кажется, что тут как и в ветке с путаницей что такое RTOS, непонятно, что такое RTOS. В статье я сделал только приведенное Вами утверждение. Ничего не говоря о том к какой категории относиться данная ОС. И если считать что от того что ОС предназначена для встроенной железки, она становиться embedded, то да она embedded, но можно считать и иначе!

                                          0
                                          Не, под эмбеддед линукс обычно подразумеваются вполне конкретные особенности операционной системы, такие как отсутсвие оконного менеджера, применение busybox, компактный размер и упаковку всей системы в «прошивку».
                                          Raspbian построена как обычный десктопный линукс, а не как эмбеддед.
                                          Сама малина это тоже просто одноплатный PC, на котором в том числе можно сделать эмбеддед систему.
                                          Вот возмите какую нибудь плату под тот же ARM, но без видео — вы на неё не поставите Raspbian, да и не будите даже пытаться, потому что это не эмбеддед ОС.
                                          Классификация примерно на тех же основаниях по которым системы делят на серверные и десктопные.
                                          На Raspbian и малине можно сделать вполне обычный PC, на котором можно разрабатывать и компилировать программы, серфить в интернете, работать с офисными приложениями, играть, смотреть фильмы — делать все то что обычно делают с десктопом.
                                          Потому что это десктопная система, а не эмбеддед.
                                          Поставьте туда Yocto и вы сможете делать только то что было заложено разработчиком.
                                          Т.е. из универсальной системы она превратится в узкоспециализированную.
                                          PS: и вообще то что такое RTOS это очень даже понятно, это вполне конкретный класс ОС и всегда можно указать почему одна ОС является RTOS, а другая — нет.
                                    +1
                                    В очередной раз хочу упомянуть, что классификация есть проявление работы интеллекта.

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

                                    Понимание того, что есть система реального времени может различаться у исследователя и практика. Потому что им в их работе удобно другое чуть-чуть другое понимание этого термина. Хотя говорят они об одном и тоже объективном явлении.

                                    В зависимости от решаемой мной задачи, вирус может быть формой жизни, а может не быть ей. Это конечно не то знание, которым стоит ломать стройную картину миру студентам вузов и прочим лицам, пытающимся сформировать непротиворечивую картину мира, но с какого-то уровня понимания, все же стоит держать в голове, что это все это просто слова.
                                      0
                                      Спасибо. Я это и хотел показать в статье, что мир embedded многообразный и там требуются разные свойства. Я старался в разных разделах, объяснять о чем в данный момент говорим. И уж точно не хотел делать ранжирование ОС по «RTOS не RTOS». Поскольку даже в университете, как я считаю, уже нужно пытаться понимать смысл вещей и явлений, а не говорить. Вот это операционная система реального времени а эта embedded OS.
                                        0
                                        А все потому что вы ушли от рассмотрения времени в RTOS.
                                        Поставьте критерием время переключения контекста любой задачи в 1 мкс на 100 МГц процессоре с float-point сопроцессором с детерминированностью в 0.1 мкс и все станет на свои места.
                                        Вы четко увидите где RTOS, а где нет.
                                          0
                                          Приведенные выше требования Вы считаете критерием RTOS-ности?

                                          Но почему именно 1мкс и 100 МГц?

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

                                          То есть, конкретные требования для разных систем разные. Ну а процессор, можно заменить на более быстрый, скажем 1ГГц
                                            0
                                            Ну так это определение же ставит вас в тупик в который вас тут все время направляют.
                                            Вон в MATLAB есть десктопный движок с временем гарантированного отклика в 1 мс.
                                            Будем считать теперь Windows Home Edition является RTOS?
                                            Для управления заводами не нужна RTOS, для управления современным автомобилем тоже. Это гетерогенные системы, в их масштабе об одной RTOS говорить бессмысленно. Нужно четче обрисовывать область применения RTOS.
                                            О RTOS можно говорить только в контексте современных технологических рубежей.
                                            И эти рубежи можно описать цифрами.
                                            Я дал оценку этих цифр исходя из своего опыта.
                                            У процессора с 1 ГГц будет многоуровневый кэш и о детерминированности в 0.1 мкс в этом случае говорить не приходится.
                                            Есть процессоры с TСM на 600 МГц, там соответственно время переключения не должно превышать 0.5 мкс (учтем занятость шин DMA и прочие издержки)
                                              0
                                              Ну так это определение же ставит вас в тупик в который вас тут все время направляют.

                                              Не знал, не знал, спасибо, что сообщили :)

                                              Нужно четче обрисовывать область применения RTOS.

                                              Мне казалось я говорил об embedded системах. Когда стал говорить об Системах реального времени, тут же стал объяснять контекст в котором я об этом говорю. И это поверьте не случайно.

                                              Будем считать теперь Windows Home Edition является RTOS?

                                              То есть по вашему мнению, разница все таки во времени. 1мс недостаточно, нужно 1мкс?
                                              Или проблема в том, что
                                              У процессора с 1 ГГц будет многоуровневый кэш и о детерминированности в 0.1 мкс в этом случае говорить не приходится.

                                              То есть десктопные системы по определению не реального времени? на малинке например невозможно добиться реального времени. Ну или VxWorks установленный на какую нибудь PC-шку будет не RTOS?
                                                0
                                                На малинке можно добиться реального времени, но не с RTOS, а с маленькой стэйт машиной влезающей в его кэш.
                                                Так же и c PC.
                                                Я говорю о современном реальном времени, т.е. 1 мкс на переключение задач с соответствующим детерминизмом.
                                                Говорю же, забазируйтесь на абсолютнов времени и все станет яснее.
                                                За образец держите ThreadX.
                                                Кстати странно почему ее игнорируете, она ж даже в малике есть.
                                                  0
                                                  Я говорю о современном реальном времени, т.е. 1 мкс на переключение задач с соответствующим детерминизмом.

                                                  Так значит Ваше определение RTOS: «время переключения задач 1 мкс»? С соотвествующим детерминизмом — это как? Чтобы оно было постоянным? то есть много раз переключаем и оно все равно не выходит за 1 мкс?

                                                  Я спрашиваю поскольку хочу понять. А то фраза «забазируйтесь на абсолютнов времени и все станет яснее. » Оставляет пространсво для разногласий. И уж точно предложение: «За образец держите ThreadX. „
                                                    0
                                                    Да, мое определение -> 1+-0.1 мкс
                                                    Оно сразу отсекает CPU с многоуровневыми кэшами, MMU, всякие малинки с линуксами, Windows-ы и прочие OS-ы и процессоры приложений.
                                                    Не то что бы такое определение было всегда, а только теперь оно кристаллизуется, когда ARM стал делать ядра заточенные под RTOS.
                                                      0
                                                      Спасибо. Понятно.
                                                        0
                                                        Для этого делают метрику worst case interrupt latency с отключенным кэшем и прочими опциями процессора, вносящими недетерменированность. Если опции не отключаются, то нагружают проц по максимуму, чтобы кэш всё время промахивался и.т.п. и измеряют WCIL
                                                        Вопрос, будет ли измеренная метрика удовлетворять вашим требованиям, если нет, то выбирается другой процессор.
                                                  +1
                                                  Для управления заводами не нужна RTOS, для управления современным автомобилем тоже. Это гетерогенные системы, в их масштабе об одной RTOS говорить бессмысленно. Нужно четче обрисовывать область применения RTOS.


                                                  Для управления некритических систем в автомобиле ОСРВ не нужна, но что касается критических систем, то там только ОСРВ и работает. Например система впрыска топлива, ABS и.т.п.
                                                    0
                                                    Тут опять можно попасть впросак. В впрыске и ABS может стоять также несколько операционных систем.
                                                      0
                                                      Несколько ОСРВ на одну функциональность? Т.е. несколько ОСРВ на впрыск?
                                                      Одна ОСРВ на впрыск, одна на на АБС, да такое возможно, даже крайне вероятно, т.к. эта система критическая, то тут уместно на каждую критическую функцию по отдельному модулю со своим контроллером подключенному к CANBus. В ARINC-653 это обязательное требование spatio-temporal partitioning
                                                        0
                                                        В ABS на сидящей на полевой шине может быть один процессор коммуникационный, один основной и один на приеме и предобработке сигналов, у каждого своя RTOS. Однопроцессорные решения давно в прошлом.
                                                        Даже в простейших модуля ввода-вывода ПЛК стоит по три процессора.
                                                        Поэтому когда говорят о RTOS надо сужать их применение до сверхлокальных задач.
                                                        Какие там заводы или автомобили. Отдельные лампочки, моторчики или даже просто контакторы — вот ниша настоящих RTOS.
                                                          0
                                                          Да, логично, spatio-temporal partitioning повсеместно.
                                                          Ха-ха, настоящие ОСРВ еще в телефонах есть, в baseband процессоре что по вашему работает? ОСРВ жесткого времени. В Wi-Fi роутерах/адаптерах, вобщем много, где есть ОСРВ.
                                          0
                                          Данный планировщик работал по статическим приоритетам задач, соответственно работал гораздо предсказуемее. Но это был уже не Linux, точнее функциональность Linux была не в режиме реального времени.

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

                                            Что тогда требуется Linux, помимо честного планировщика что бы быть RTOS?

                                            В этом то и проблема, что нужно смотреть от задачи. Только здесь накидали несколько определений RTOS. Я же пытался показать понятие, а не дать строгое определение, как например, переключение задач 1 мкс.
                                            Для определенных задачь, допиленного ядра и урезанной функциональности должно хватать. Суть проблемы, в том что Linux по определению универсальный, и с огромной функциональностью, проследить все состояния которого не представляется возможным.
                                              +1
                                              Попытался раскрыть тему о том что же такое rtos в статье

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

                                            Самое читаемое