Что дает операционная система микроконтроллеру. Встраиваемые системы и ос для них

Я постоянно задаюсь этим вопросом, во время занятий своим хобби, – разработкой домашней системы автоматического контроля (умного дома), основанной на 16-битном микроконтроллере, – действительно ли это верный подход? Полтора месяца назад, я уже писал в своем блоге на тему «Микроконтроллеры против систем-на-чипе» . Так вот, я опять собираюсь писать об этом.

Частично к этому меня побудило появление в продаже Stellaris Launchpad и Arduino Due . Они оба основаны на 32-битных микроконтроллерах, и во многом, очень похожи. Я изучил спецификации (datasheet) к обоим, и хотя они прилично отличаются по цене, они рассчитаны на одну целевую аудиторию. Я задумывался о том, что возможно мне стоит перейти с MSP430 на Stellaris, а может быть даже пересесть на принципиально иную систему, использовать что-то вроде Raspberry Pi, вместо микроконтроллеров.

Оба, Stellaris Launchpad и Arduino Due, очень мощны, но не предназначены для запуска Linux. Они работают либо на исполняемом коде, написанном непосредственно для них, либо под управлением операционной системы реального времени (RTOS), – минималистичной ОС, с очень коротким временем реакции на внешние события. Так же они оба значительно сложнее, чем MSP430 или 8-битные AVR.

C другой стороны, в реальной жизни (за границами интернета), большинство, кого я знаю, используют Raspberry Pi или другие встраиваемые системы на Linux. Использование именно микроконтроллеров, довольно редкий случай, среди тех, кого я встречал. Даже Arduino, гораздо менее популярно, в моем окружении, чем встраиваемый Linux. Как я это понимаю, – зачем кому-то покупать Arduino, когда можно приобрести Raspberry Pi, который может гораздо больше, а стоит столько же или меньше? Под Linux есть огромное количество готового софта, и на нем можно программировать, используя простые скриптовые языки.

Лично для меня, причина, по которой я не желаю использовать Linux, это потому что я ежедневно использую его на работе, и возвращаясь домой, не испытываю удовольствия от необходимости опять работать на Linux-подобных системах. У меня нет проблем с использованием Linux, но его слишком много повсюду, он меня гнетет. Мне гораздо интересней работать с простыми электронными устройствами на 8-ми / 16-битных микрочипах.

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

В моем проекте умного дома, я реально столкнулся с этой проблемой. Я уже сделал драйвер локальной сети для системы контроля на MSP430, и все выглядит очень достойно. По сути, я могу сделать все, что необходимо для системы автоматизации на MSP430. Тем не менее, я задумываюсь, правильно ли то, как я это делаю? Не пытаюсь ли я, есть суп вилкой, когда есть ложка? Может быть, Linux более походящая система? Позвольте, я объясню.

Если остановиться и взглянуть на текущую ситуацию, по технологическим достижениям на ноябрь 2012 года. Я спрашиваю себя, достаточно ли хороши и актуальны микроконтроллеры, по сравнению с системами-на-чипе, использующими Linux?

Если перечислять проекты на встраиваемых системах, которые приходят мне в голову, это: дроны, роботы, домашняя автоматизация, контроллеры моторов, сенсоры, наручные часы, 3D-принтеры и т.п. В каких из этих случаев, встраиваемый Linux подходит больше, чем микроконтроллеры? И почему?

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

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

Например, для проекта умного дома, я могу разработать, дистанционно контролируемый выключатель. Он может включать/выключать свет или что-то еще. В тоже время, я могу пойти в местный магазин электротехники и купить то же самое за $20, произведенное в Китае. Смогу ли я когда-нибудь перебить эту цену, попытавшись продавать собственный выключатель? Не думаю, что это возможно.

Если задуматься, это относится и к множеству остальных вещей, необходимых для домашней автоматизации. Датчики температуры, дыма, движения и т.д., я вполне способен самостоятельно сделать такие же, но вряд ли, из этого можно извлечь финансовую выгоду. Кому интересно покупать такие вещи у меня за $75, когда они могут найти их за $20 в Хозтоварах?

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

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

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

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

С другой стороны, микроконтроллеры могут быть лучшим выбором, чем системы-на-чипе, когда необходимо низкое потребление энергии. В таких системах есть два момента: низкое потребление самой схемы, во время работы, и короткое время старта. Типичным способом экономии батареи для мелких устройств, является само-отключение (shut off). Когда вы выключаете компьютер на Linux, ему нужно приличное время, что бы вернуться к работе, иногда до нескольких минут. Такое время не приемлемо для встраиваемых систем.

Если взять такой микроконтроллер, как MSP430, то он может годами работать от одной батарейки. Stellaris Launchpad и Arduino Due, в принципе то же на такое способны, они потребляют больше энергии чем MSP430, но все-равно очень мало, по сравнению с Raspberry Pi. Еще, MSP430, может моментально стартовать, после выключения.

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

В третьем случае, как я уже говорил, использование микроконтроллера более осмысленно, чем Linux, в операциях требующих моментальной реакции (realtime response). Я имею в виду такие устройства, как 3D-принтеры и станки ЧПУ, я знаю, о чем говорю, так как посвятил много времени их изучению. По своей природе, они требуют высокой точности в работе, которая чуть менее чем полностью зависит от времени реакции на команды.

Например, если у вас запущена циркулярная пила, которая отрезает в данный момент кусок дерева или метала, вы не можете остановить процесс, из-за того что компьютеру который ей управляет, понадобилась пауза, что бы скинуть данные из памяти на диск или что-то иное в том же духе. Любой, кто использовал ПК, знаком со случайными подвисаниями, периодически возникающими во время самой обычной работы. А теперь представьте себе, что у вас большой сверлильный станок, под управлением ПК, который вдруг начинает проверять обновления для Windows, во время работы, и дрель, сверлит насквозь стол, на котором стоит, т.к. компьютер потерял над ней контроль.

ПК и системы-на-чипе не предназначены для работы в реальном времени, хоть с Windows, хоть с Linux, но само собой они пытаются к этому приблизиться. Как пример, существует патч реального времени для ядра Linux, и специальный ЧПУ софт, созданный для работы такого рода. Я не достаточно знаком с этим патчем Linux, и не знаю, насколько он гибок, для полного контроля событий реального времени. Но думаю, что это лишь возможная альтернатива, т.к. Linux, какие бы патчи на него не навешали, никогда не побьет микроконтроллеры в этой области, благодаря наличию у них системы прерываний.
В заключение, хочу сказать, что потратил много времени, пытаясь найти области, где применение микроконтроллеров в моих проектах имеет преимущество. И все выглядит так, что пришла эпоха мирового доминирования Raspberry Pi и Beaglebones. Это текущая ситуация в DIY сообществе. В большинстве случаев, быстрее и легче разрабатывать на этих системах, так что зачастую это лучший выбор для большинства проектов.

Для микроконтроллеров остаются только области низковольтных устройств, операций реального времени и устройств низкой стоимости.

Это не зависит от того, что микроконтроллеры могут казаться «веселее» чем ПК. Это то, с чем придется смириться.

Перевод с английского языка оригинального поста

Что приходит на ум когда слышишь операционная система? Наверняка форточки, линукс, макось.. или что нибудь подобное. Верно, и на вопрос зачем она нужна, все уверенно ответят: послушать музыку, поиграть в игру (по интернету!), разговаривая при этом с другом по скайпу. Заодно созерцая, как мигает светодиодик, получив байт с юарта =).

А если копнуть глубже, то прослушивание музыки, пересылка данных по Интернету — это все одиночные процессы, а так как процессор у нас один, то одновременно он может выполнять только одну задачу. Поэтому задачи выполняются поочередно небольшими «порциями», суть ОС делать это незаметно для пользователя: чтобы звук не хрипел и байтики слались и все работало одновременно. При этом, если одна из задач «повиснет», то все остальное продолжало работать.

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

Есть два основных вида ОС: вытесняющая и кооперативная. В первом случае, переключение между задачами будет «жестким», т.е. если квант времени 1мс, то сначала первая задача будет выполняться ровно 1мс, затем вторая ровно 1мс и т.д. Такие оси называются реального времени (ОСРВ). У кооперативных немного попроще, процесс сам должен сказать что «я выполнился», поэтому к ОСРВ их отнести нельзя.

Впердолить вытесняющую на мелкие AVR не получится по причине небольшого количества ОЗУ. Из имеющихся вариантов кооперативок, мне приглянулась mRTOS, почитать подробности сей системы можно на сайте автора (легко гуглится). Главная причина ее использования — простота, наличие готовой версии под CAVR, для понимания общих принципов самое то.

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

Поэтому стоит задать себе несколько вопросов:
1.Сможете ли вы распорядиться грамотно ресурсами?
2. Не предполагается ли в процессе написания прошивки изобретать такой же велосипед, подобный планировщику?
3. Насколько читаем Ваш код? Способны ли Вы через полгода-год открыть его и сходу разобраться?
4. Один ли Вы пишите или группой?

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

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

Теперь заглянем под капот. Для запуска mRTOS к проекту нужно подключить mrtos.c и заинклюдить mrtos.h. Структура кода немного отличается от привычного

#include #include "mrtos.h" //тут тело функции где мы пишем свой супер код void task1() { while (1 ) //задачи в любой ОС построены на базе бесконечного цикла { //тут код Вашей задачи DISPATCH; //функция передачи управления планировщику } ; } //обработчик прерывания таймера 0 interrupt [ TIM0_OVF] void timer0_ovf_isr(void ) { char ii; #asm("cli") TCNT0= 0x9C ; inc_systime() ; for (ii = 0 ; ii< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { //инициализация периферии Init_mRTOS() ; //инициализация ос //тут создаем таски(задачи) здесь создано 3 задачи create_task(task1, 1 , Active) ; //создать задачу (имя задачи, приоритет, статус) create_task(task2, 1 , Active) ; create_task(task3, 1 , Active) ; Sheduler() ; //запуск планировщика while (1 ) ; }

#include #include "mrtos.h" //тут тело функции где мы пишем свой супер код void task1() { while(1)//задачи в любой ОС построены на базе бесконечного цикла { //тут код Вашей задачи DISPATCH; //функция передачи управления планировщику }; } //обработчик прерывания таймера 0 interrupt void timer0_ovf_isr(void) { char ii; #asm("cli") TCNT0=0x9C; inc_systime(); for(ii = 0; ii

Теперь подробнее. количество задач указывается в mrtos.h дефайном APPTASKS N. Задача объявляется внутри task1(){}, task2(){} и тому подобное, внутри while(1) не нужно ничего писать, вызывать функции тоже никак не нужно, все это сделает за вас планировщик. Как видно задача состоит из бесконечного цикла, это нормально так и должно быть, но внутри задачи нужно обязательно отдавать управление планировщику. Либо функцией WAIT, либо DISPATCH. Если этого не сделать, то задача будет выполняться бесконечно.

Как это работает? Создадим таск мигания светодиодом.

void task1() { while (1 ) { PORTB.0 = ! PORTB.0; WAIT(100 ) ; } ; }

void task1() { while(1) { PORTB.0 = !PORTB.0; WAIT(100); }; }

WAIT это некий аналог delay() только, во время делея микроконтроллер ничего не выполняет и гоняет пустые циклы. Во время же WAIT управление передается другим задачам. Т.е. можно создать кучу тасков миганиями разных светодиодов, с разным WAIT и все они будут мигать с разной частотой. Если задержки не нужны то в конце используетм DISPATCH.

При использовании WAIT важно понимать, что вся система имеет минимальный тик (квант времени), поэтому мы ждем не WAIT(50) 50 милисекунд, а 50 тиков системы. Настройка тика зависит от того, как часто вызывается прерывания таймера0, т.е. если мы настроили прерывание на 1мс, то мы можем предполагать, что наше действие выполнится в течение 1мс. Опыты показали что уменьшить системный тик можно до ~20 мкс при тактовой 16МГц.

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

create_task(task1, 1 , Active) ;

create_task(task1,1,Active);

С приоритетами все довольно таки не просто. Если имеются две задачи с разными приоритетом и задача с большим приоритетом постоянно выполняется, то в задачу с низким приоритетом мы никогда не зайдем. Поэтому нужно организовывать работу так, чтобы все задачи получали доступ. Заострять внимание на этом не будем, припасем на следующий раз. Состояние задачи, Active — запущена, остановлена StopTask.

Итак, для желающих просто мигнуть светодиодом:

#include #include "mRTOS.h" void task1() { while (1 ) { WAIT(1000 ) ; PORTB.0=! PORTB.0; } } // Timer 0 overflow interrupt service routine interrupt [ TIM0_OVF] void timer0_ovf_isr(void ) { char ii; #asm("cli") TCNT0= 0xb2 ; inc_systime() ; for (ii = 0 ; ii< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { DDRB= (1 << DDB7) | (1 << DDB6) | (1 << DDB5) | (1 << DDB4) | (1 << DDB3) | (1 << DDB2) | (1 << DDB1) | (1 << DDB0) ; PORTB= (0 << PORTB7) | (0 << PORTB6) | (0 << PORTB5) | (0 << PORTB4) | (0 << PORTB3) | (0 << PORTB2) | (0 << PORTB1) | (0 << PORTB0) ; // Timer/Counter 0 initialization // Clock source: System Clock // Clock value: 7,813 kHz TCCR0= (0 << CS02) | (1 << CS01) | (1 << CS00) ; TCNT0= 0x83 ; // Timer(s)/Counter(s) Interrupt(s) initialization TIMSK= (0 << OCIE2) | (0 << TOIE2) | (0 << TICIE1) | (0 << OCIE1A) | (0 << OCIE1B) | (0 << TOIE1) | (1 << TOIE0) ; Init_mRTOS() ; create_task(task1, 1 , Active) ; Sheduler() ; while (1 ) ; }

#include #include "mRTOS.h" void task1() { while(1) { WAIT(1000); PORTB.0=!PORTB.0; } } // Timer 0 overflow interrupt service routine interrupt void timer0_ovf_isr(void) { char ii; #asm("cli") TCNT0=0xb2; inc_systime(); for(ii = 0;ii

В качестве бонуса я попробовал сделать полифоническую (двухголосую) мелодию «Dr.Mario chill». Идея в том, что каждая ножка контроллера постоянно инвертируется в отдельном таске, тем самым генерируя частоту. Меняя задежку можно менять высоту ноты.

void task2(void ) { while (1 ) { if (mute == 0 ) //если разрешено играть { if (note_ch2[ n_n] == 0 ) //если пауза то ждем, ничего не играем { PORTB.4 = 0 ; WAIT(5 ) ; } else { PORTB.4 = ! PORTB.4; //если не пауза то дрыгаем ногой с нужной частотой WAIT(note_ch2[ n_n] ) ; } } } }

void task2(void) { while(1) { if(mute == 0) //если разрешено играть { if(note_ch2 == 0) //если пауза то ждем, ничего не играем { PORTB.4 = 0; WAIT(5); } else { PORTB.4 = !PORTB.4; //если не пауза то дрыгаем ногой с нужной частотой WAIT(note_ch2); } } } }

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

void task3(void ) { while (1 ) { WAIT(1500 ) ; //играем минимальную длительность ноты for (mute = 0 ; mute < 500 ; mute++ ) //обрываем ноту, чтобы не сливались { PORTB.3 = 0 ; PORTB.4 = 0 ; } ; mute = 0 ; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if (n_n == n_max) //если сыграли все то идем по кругу { n_n = 0 ; } } }

void task3(void) { while(1) { WAIT(1500); //играем минимальную длительность ноты for(mute = 0; mute < 500; mute++) //обрываем ноту, чтобы не сливались { PORTB.3 = 0; PORTB.4 = 0; }; mute = 0; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if(n_n == n_max) //если сыграли все то идем по кругу { n_n = 0; } } }

Чтобы смешать два канала использовал простенькую схемку.

Итого небольшой кусочек

Для желающих прошивка

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

Примеры встроенных систем

Робот, такой как марсоход , показанный на рисунке 1.1 , является встроенной системой. Сотовый телефон, PDA , или портативный мультимедиа плеер, показанные на рисунке 1.2 , являются встроенными устройствами. Даже электрическая зубная щетка, показанная на рисунке 1.2 , является встроенной системой. Небольшой микроконтроллер в зубной щетке обеспечивает программируемое управление скоростью и индикацию состояния заряда батареи. Высококачественные автомобили могут содержать около ста встроенных микроконтроллеров. Типичное домовладение среднего класса имеет около пятидесяти встроенных устройств. Для каждого ПК в мире имеется более сотни встроенных устройств. В общей сложности, встроенные устройства составляют большую часть мирового производства микропроцессоров.

Рис. 1.1.

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

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

Рис. 1.2. Таблица 1.1. Примеры встроенных систем

Авиационные & Военные системы	Автопилоты самолетов, авионика и навигационные системы, системы автоматической посадки, системы наведения, управление двигателем.
Биомедицинские системы	Cистемы компьютерной томографии и ультразвукового исследования, мониторинг пациентов, кардиостимуляторы.
Автомобили	Управление двигателем, антиблокировочные тормозные системы, противобуксовочная тормозная система, управление подушками безопасности, управление системой обогрева и кондиционирования воздуха, навигация GPS, спутниковое радио, системная диагностика.
Коммуникация	Коммуникационные спутники, сетевые маршрутизаторы, коммутаторы, концентраторы.
Потребительская электроника	телевизоры, духовки, посудомоечные машины, плееры DVD, стереосистемы, системы безопасности, управление поливом газонов, термостаты, фотокамеры, радиочасы, автоответчики, декодеры кабельного телевидения, другие устройства.
Устройства в/для компьютера	Клавиатуры, мыши, принтеры, сканеры, дисплеи, модемы, устройства жестких дисков, устройства DVD, графические платы, устройства USB.
Электронные инструменты	Системы сбора данных, осциллографы, вольтметры, генераторы сигналов, логические анализаторы .
Промышленное оборудование	Управление лифтами, системы наблюдения, роботы, станки с ЧПУ, программируемые логические контроллеры, промышленные системы автоматизации и управления.
Офисные машины	факс-аппараты, копиры, телефоны, калькуляторы, кассовые аппараты.
Персональные устройства	сотовые телефоны, переносные плееры MP3, видео-плееры, персональные цифровые помощники (PDA), электронные наручные часы, портативные видеоигры, цифровые камеры, системы GPS.
Роботы	Промышленные роботы , автономные транспортные средства, космические исследовательские роботы (например, роботы- марсоходы )
Игрушки	системы видеоигр, игрушки роботы типа "Aibo", "Furby", и "Elmo".

Операционные системы реального времени

Системы реального времени должны отвечать на внешние параметры ввода и создавать новые результаты вывода за ограниченное время, как показано на рисунке 1.3 . Время ответа должно быть ограничено. Очень длительное время ответа может привести к отказу систем реального времени.

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

Рис. 1.3.

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

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

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

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

Операционные системы часто классифицируют по их характеристикам реального времени. Операционная система реального времени должна быть тщательно спроектирована, чтобы поддерживать приложения реального времени. Недавнее исследование приходит к выводу, что 95% приложений реального времени требуют ограниченного времени ответа в диапазоне от 0.5 до 10 мсек. Только 10% отклонение (колебание от 50 микросекунд до 1 мсек) во времени ответа может быть допустимо. Согласно таким требованиям большинство операционных систем общего назначения не являются системами реального времени. Согласно этим критериям встроенная ОС, такая как Windows XP, может рассматриваться в лучшем случае только как мягкая ОС реального времени . Для Windows XP существуют некоторые инструменты сторонних поставщиков, которые улучшают время ответа.

Операционные системы для встроенных систем

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

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

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

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

Эта статья посвящена операционной системе реального времени (ОСРВ), которая называется SYS/BIOS (ранее известна как DSP/BIOS) от компании Texas Instruments, и ее использованию на 16-разрядных микроконтроллерах MSP430 со сверхнизким энергопотреблением. В статье приводятся общие рекомендации по использованию ОСРВ, а также указывается в каких случаях использование ОСРВ является расточительным или попросту непрактичным.

Вы планируете использовать менее 1 КБ SRAM и 2 КБ флеш-памяти? Ваше приложение будет выполнять лишь какую-то одну задачу, не связываясь с внешним миром, и при этом вы не планируете повышение его функциональности? Тогда, возможно, вам следует завершить на этом чтение статьи и продолжить работу над проектом. Советы в этой статье вряд ли вам пригодятся и только отнимут часть драгоценного времени до вывода продукта на рынок.

По каким-то причинам в мире встроенного программного обеспечения снова и снова можно наблюдать ситуацию, когда для нового проекта создание соответствующего ПО начинается с нуля. А ведь нам уже не одно десятилетие должно быть известно, что ключом к повышению эффективности является именно повторное использование. И хотя стандарты оформления кода в объектно-ориентированном программировании могут обеспечить преимущества повторного использования, посмотрим правде в глаза: много ли вы видели до сих пор кодов на C++, скажем, на платформах 16-разрядных микроконтроллеров? Большая часть кода написана на С и по-прежнему имеется целый ряд низкоуровневых ассемблеров, но лишь меньшинство по-настоящему выражается на языке C++.

И еще один момент, на который я хочу обратить ваше внимание, прежде чем мы погрузимся в технические подробности. Вы согласны с той мыслью, что новый проект представляет хорошую возможность избавиться от этого старого, огромного, испещренного ошибками ввиду исторических причин спагетти-кода? Кода, на копирование и устранение ошибок которого исследователи и разработчики потратили за последние годы массу усилий, и при этом лишь немногие из них знают (но не могут объяснить), как вообще этот монстр способен выполнять свои функции? Вы, скорее всего правы насчет того, что новый проект – это отличная возможность начать все сначала, но задавали ли вы себе вопрос, как коду в принципе удалось так долго проработать? При изменяющихся требованиях на стадии создания ПО, необходимости в новых промежуточных элементах, без соблюдения единых указаний по оформлению кода и стандартизированных определений интерфейса, без инфраструктуры отладки и анализа для увеличения тестового покрытия. Таким образом, если ваше целевое приложение будет выполнять как минимум 3–4 различные задачи включая, возможно, работу в реальном времени, а также предполагается его связь с той или иной внешней частью в системе, вам следует всерьез рассмотреть вариант использования ОСРВ.

На рынке есть множество решений ОСРВ как в коммерческом секторе, так и от некоммерческих разработчиков бесплатного ПО с открытым исходным кодом. Увы, сказать специалисту по разработке ПО, что одна ОСРВ лучше другой или одна система хороша, а другая не очень, достаточно сложно. Тем не менее, существует ряд основных общих требований к ОСРВ, которые могут помочь разработчикам ПО определить функции и возможности той или иной ОСРВ. Наконец, необходимую оценку функций можно провести только с учетом фактического конечного приложения. Таким образом, повторюсь, успешность разработки ПО в большой степени зависит от того, насколько хорошо вы знаете и понимаете целевое приложение; объектно-ориентированное программирование и операционные системы реального времени не заменят грамотную разработку требований и проектирование систем.

Коммерческий аспект системы SYS/BIOS

В целом, существует два критерия выбора ОСРВ. С одной стороны это технические характеристики ОСРВ, с другой – коммерческий аспект реализации. В случае с системой SYS/BIOS коммерческий вопрос не является проблемой. Для системы SYS/BIOS не требуется дополнительных затрат, поскольку она предоставляется бесплатно и с открытым исходным кодом компанией Texas Instruments под лицензией BSD для ПО с открытым исходным кодом и таким образом не требует какой-либо платы за разрешение на использование.

Технические характеристики системы SYS/BIOS

На веб-странице в Википедии Texas Instruments приводится следующее техническое описание системы SYS/BIOS: «SYS/BIOS представляет собой масштабируемое ядро реального времени. Оно разработано для использования приложениями, в которых требуется планирование и синхронизация или инструментирование в реальном времени. Система SYS/BIOS обеспечивает вытесняющую многопоточность, аппаратную абстракцию, анализ в реальном времени и инструменты конфигурирования. Система SYS/BIOS разработана для минимизации требований к памяти и ЦП в целевом приложении» ()

Рис. 1 Графическое конфигурирование

В этих предложениях упомянуты все ключевые факторы: масштабируемость, переносимость, оперативные средства, работа в реальном времени и предоставление инструментов разработки и анализа. Важным аспектом является размер или объем занимаемой памяти. Благодаря оптимизированным технологиям конфигурирования система SYS/BIOS способна снизить свои требования к объему флеш-памяти на микроконтроллерах MSP430 до менее 4 КБ. В зависимости от конфигурации (равна заданным используемым элементам) в коде ядра SYS/BIOS скомпилированы лишь необходимые функции. SYS/BIOS поставляется как часть интегрированной среды разработки Code Composer Studio (CCS) версий 4 и 5. Статическое конфигурирование системы SYS/BIOS можно провести внутри среды CCS с помощью удобного графического инструмента конфигурирования. Можно выбирать, какие программные модули необходимо включить, изменять значения параметров по умолчанию для настройки работы целевого приложения, а также создавать оперативные средства ОСРВ, такие как потоки и семафоры. Для более крупных и динамичных систем все эти функции могут выполняться с помощью оперативных API на языке Си. Динамическое конфигурирование SYS/BIOS обеспечивает гибкость приложения, тогда как статическое может повысить производительность и снизить объем занимаемой памяти.

При этом системы, хорошо работающие на 32-разрядных платформах, будут также совместимы с определенным рядом 16-разрядных микроконтроллеров. Пересечение платформ достаточно велико, и обе из них могут успешно использовать ОСРВ в качестве программного основания. Новые функциональные узлы дают возможность увеличить количество элементов, повысить сложность, а также разместить больший объем памяти на кремниевом кристалле того же формата. В то же время повышаются и скоростные характеристики процессоров, и все это может быть успешно абстрагировано с помощью подходящего решения ОСРВ. Обеспечивая определенный уровень аппаратной абстракции, система SYS/BIOS дает возможность, например, писать все процедуры обработки прерываний на Си, что позволяет легко переносить код между микроконтроллерами, микропроцессорами ARM и цифровыми сигнальными процессорами от компании Texas Instruments. В плане оперативных средств в системе SYS/BIOS предусмотрен широкий выбор типов потоков для множества ситуаций применения. Выбирая соответствующие типы потоков, можно управлять приоритетами выполнения и характеристиками блокировки. Кроме того, система SYS/BIOS предлагает различные структуры для поддержки связи и синхронизации между потоками, такие как семафоры, почтовые ящики, события, логические элементы и обмен сообщениями переменной длины. Время исполнения в той или иной ОСРВ, как правило, зависит от задержки прерывания, времени переключения контекста и некоторых других показателей производительности ядра. Так, чтобы обеспечить надежное соблюдение приложениями заданных сроков в реальном времени, практически все проблемы ядра SYS/BIOS обеспечивают детерминированную работу. Последнее, но не менее важное: в интегрированную среду разработки Code Composer Studio встроен набор инструментов, который помогает пользователю находить и устранять проблемы во время работы. Средство просмотра динамических объектов (ROV) и анализ в реальном времени (RTA) являются инструментами визуализации данных на основе Eclipse, которые собирают данные встроенных средств инструментирования, записываемые системой SYS/BIOS, например для отображения графов последовательности выполнения. При этом инструментирование для отладки может быть настроено или полностью убрано из окончательной версии кода продукта для максимизации производительности и минимизации объема занимаемой памяти.

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

Типичное приложение на основе MSP430, в котором важно потребление энергии, следует по стандартной блок-схеме кода. В отчете о применении «Методы программирования MSP430» (SLAA294) Texas Instruments подробно описано, как эффективно использовать возможности экономии энергии микроконтроллеров MSP430 путем применения соответствующих методов программирования. На рисунке 2 в общем показана стандартная блок-схема кода высшего уровня для приложений на основе MSP430 со сверхнизким энергопотреблением.

Рис. 2 Блок-схема кода высшего уровня

Структура кода управляется прерываниями, поскольку это обеспечивает наибольшие возможности для выключения питания устройства. Пока не получено прерывание, устройство бездействует, максимизируя таким образом энергоэффективность. Для того чтобы понять, как реализованы показанные процедуры обработки прерываний (ISR), имеет смысл вспомнить способ работы микроконтроллера MSP430 в режимах низкого энергопотребления. Режимами питания управляют биты внутри регистра состояния (SR) ЦП. Преимуществом этого является то, что режим питания, активированный до выполнения ISR, сохраняется в стек как часть начальной обработки прерывания. Когда по завершении выполнения процедура ISR перезагружает это значение, ход выполнения программы возвращается к этому сохраненному режиму питания. Оперируя при этом сохраненным значением SR на стеке изнутри процедуры ISR, можно перенаправлять ход выполнения программы после ISR в другой режим питания. Этот механизм является неотъемлемой частью работы MSP430 с низким энергопотреблением, поскольку обеспечивает быстрое включение устройства в ответ на прерывание. Система SYS/BIOS для MSP430 дает возможность легко использовать этот стандартный метод программирования и, кроме того, предоставляет модуль питания, который может использоваться для автоматического перевода ЦП в режим холостого хода при отсутствии готовых к выполнению потоков. Когда модулю питания разрешена такая операция, он автоматически вставляет в цикл холостого хода SYS/BIOS функцию, которая активирует указанный режим низкого энергопотребления. ЦП будет оставаться в этом режиме до запуска аппаратного прерывания, которое переведет ЦП в активное состояние.

Рис. 3 Подавление тиков прерывания

Говоря об энергосбережении для MSP430, стоит упомянуть еще об одной передовой технологии ОСРВ. Как и многие другие ОСРВ, система SYS/BIOS предоставляет различные службы времени для запуска тех или иных событий в определенные моменты времени. С этой целью на микроконтроллерах MSP430 система SYS/BIOS использует доступные периферийные таймеры. Используя функции встроенного таймера со сверхнизким энергопотреблением, система SYS/BIOS автоматически устраняет ненужные прерывания в виде тиков таймера для максимизации времени холостого хода, и следовательно, сниженного энергопотребления ЦП. Возможность подавления каждого из выполняемых прерываний с помощью этой технологии напрямую экономит рабочее энергопотребление. На рисунке 3 представлена типичная реализация ОСРВ в сравнении с интеллектуальной технологией подавления тиков SYS/BIOS. В стандартной реализации процедуры обработки прерываний отсылаются, даже если нет необходимости в запуске какого-либо события, тогда как система SYS/BIOS интеллектуально настраивает периферийный таймер MSP430 для запуска прерываний только в том случае, когда необходимо выполнение тех или иных действий для дальнейшей обработки.

С учетом всего вышесказанного теперь, возможно, самое время рассмотреть использование системы SYS/BIOS для своего следующего проекта на основе MSP430 – или любого другого процессора от TI, который подходит под требования вашего приложения.

Об авторе

Вольфганг Луч – инженер-инструментальщик в области микроконтроллеров MSP430 для компании во Фрайзинге, Германия. Имеет степень магистра в области электротехники Университета прикладных наук в Лейпциге, Германия. На протяжении восьми лет работы в Texas Instruments участвовал в разработке множества микросхем MSP430 и работал над инструментами для MSP430, такими как бюджетные средства разработки eZ430. Специализируется на программировании микроконтроллеров MSP430 через интерфейс JTAG, программировании флеш-памяти, а также архитектурах и принципах встроенной эмуляции.

Встра?иваемая систе?ма, встро?енная систе?ма (англ. embedded system) - это специализированная компьютерная система, в которой сам компьютер обычно встроен в устройство, которым он управляет.

Характерные особенности:

• Очень малое энергопотребление, порядка от 0,5 до ~20 ватт
• Маленькие размеры
• Отсутствие больших систем отвода тепла (охлаждения). Зачастую ЦПУ не охлаждается вообще или используется небольшой радиатор.
• ЦПУ и системная логика, а также некоторые другие ИС, часто совмещены на одном кристалле (System On Crystal = SOC)

Основой построения встроенных систем могут служить одноплатные или однокристальные микроконтроллеры , специализированные или универсальные ЦПУ, ПЛИС. Интересной особенностью некоторых видов встроенных систем является использование довольно устаревших процессоров семейства x86 (например i386, i486, Pentium) и их клонов из-за малого энергопотребления и низкой стоимости (порядка 1-5 долларов США). Также многие виды встроенных систем используют ЦПУ архитектуры ARM.

На данный момент достаточно большое количество фирм (в тои числе в России) производит одноплатные компьютеры на основе микроконтроллеров и ЦПУ с RISC архитектурой. Среди них Advantech, AAEON, Advanced Micro Peripherals (AMP), Ampro Computers, Diamond Systems, iBASE, InnoDisk, Fastwel (Россия), Lippert, Octagon Systems, RTD Embedded Technologies, Tri-M Systems — Engineering, SanDisk, STEC. Примерами встроенных систем могут служить банкоматы, авионика, КПК, телекоммуникационное оборудование и тому подобные устройства.

Некоторые встроенные системы используются в массовых количествах (например, устройства RFID). Встроенные системы являются привлекательной целью для создателей вредоносного кода из-за своей распостранённости и относительной беззащитности. Постепенно возникает вредоносный код для встроенных систем (Cabir, RFID-вирус); к счастью, этот процесс пока затрудняется разнородностью встроенных устройств, отсутствием доминирующего ПО, и ограниченной функциональностью некоторых видов устройств. С другой стороны, задача антивирусных компаний и исследователей компьютерной безопасности также осложнена этими обстоятельствами, а также маломощностью встроенных систем, зачастую не позволяющей пользоваться распостранённым антивирусным ПО.

Основными производителями CPU для встраваемых систем являются VIA technologies, Transmeta Corporation, Infineon Technologies.

Операционные системы для встраеваемых систем

Во встраеваемых системах для управления используются операционные системы реального времени (ОС РВ) .

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

Иногда различают системы «жёсткого» и «мягкого» реального времени . ОС «жёсткого» реального времени гарантирует выполнение каких-то действий за определённый интервал времени, ОС «мягкого» реального времени, как правило, успевает выполнить действия за заданный промежуток времени, но полностью не гарантирует этого. Большинство программного обеспечения ориентировано на «мягкое» реальное время.

Для подобных систем характерно:

• гарантированное время реакции на внешние события (прерывания от оборудования);
• жёсткая подсистема планирования процессов (высокоприоритетные задачи не должны вытесняться низкоприоритетными, за некоторыми исключениями);
• повышенные требования к времени реакции на внешние события или реактивности (задержка вызова обработчика прерывания не более десятков микросекунд, задержка при переключении задач не более сотен микросекунд)

Классическим примером задачи, где требуется ОСРВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется, и робот имеет лишь маленький промежуток времени, когда он может её взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он спозиционируется раньше, то деталь ещё не успеет подъехать, и он заблокирует ей путь.
Windows CE (она же WinCE) - это вариант операционной системы Microsoft Windows для наладонных компьютеров, мобильных телефонов и встраиваемых систем. Windows CE не является «урезанной» версией Windows для настольных ПК и основана на совершенно другом ядре. К основным недостаткам системы можно отнести полное отсутствие нужных программных приложений. Поддерживаются архитектуры x86, MIPS, ARM и процессоры Hitachi SuperH.

Основные конкуренты WinCE - это VxWorks, eCos, OSE, QNX, LynxOS, Symbian OS, OS-9 , а также различные производные Linux (например, uClinux ) и, наиболее известный, PalmOS . Некоторые производители устройств также изготавливают свою собственную систему.

Windows CE оптимизирована для устройств, имеющих минимальный объём памяти: ядро Windows CE может работать на 32 КБ памяти. С графическим интерфейсом (GWES) для работы Windows CE понадобится от 5 МБ. Устройства часто не имеют дисковой памяти и могут быть сконструированы как «закрытые» устройства, без возможности расширения пользователем (например, ОС может быть «зашита» в ПЗУ). Windows CE соответствует определению операционной системы реального времени.

На базе Windows CE основано множество платформ, включая Handheld PC, Pocket PC, Pocket PC 2002, Pocket PC 2003, Pocket PC 2003 SE, Smartphone 2002, Smartphone 2003, Windows Mobile, а также множество промышленных устройств и встроенных систем. Приставка Sega Dreamcast имела поддержку Windows CE. Самой Windows CE в изначальной поставке не было, но она могла запускаться на приставке с CD. Некоторые игры использовали данную возможность.

Часто названия Windows CE, Windows Mobile, Pocket PC используют как взаимозаменяемые. Это не совсем правильно. Windows CE 3.0 - это модульная операционная система, которая служит основой для устройств нескольких классов. Любой разработчик может купить инструментарий (Platform Builder), который содержит все эти компоненты и программы, позволяющие построить собственную платформу. При этом такие приложения, как Word Mobile / Pocket Word, не являются частью этого инструментария.

Windows Mobile лучше всего представлять себе как набор платформ, основанных на Windows CE. В настоящее время в этот набор входят платформы: Pocket PC, SmartPhone и Portable Media Center. Каждая платформа использует свой набор компонентов Windows CE, плюс свой набор сопутствующих особенностей и приложений.

Windows CE .net - это кодовое название Windows CE версии 4.2.

Windows Embedded CE 6.0 (кодовое имя «Yamazaki») является шестой версией операционной системы Windows Embedded, ориентированной на предприятия, изготавливающие промышленные контроллеры и устройства бытовой электроники. В Windows Embedded CE 6,0 полностью переделано ядро, которое поддерживает свыше 32000 процессов, по сравнению с 32 в предыдущих версиях. С 32 Мб до 2 Гб поднялось выделяемое для процессов виртуальное адресное пространство.

Windows Embedded CE 6.0 был выпущен 1 ноября 2006 года.
Windows CE 6.0 R2 был выпущен 15 ноября 2007 года.
Windows Embedded CE 6.0 также является основой для Windows Mobile 7 (кодовое имя «Photon»).

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

Как микроядерная операционная система , QNX основана на идее работы основной части своих компонентов, как небольших задач, называемых сервисами. Это отличает её от традиционных монолитных ядер, в которых ядро операционной системы - одна большая программа, состоящая из большого количества «частей», каждая со своими особенностями. Использование микроядра в QNX позволяет пользователям (разработчикам) отключить любую ненужную им функциональность, не изменяя ядро. Вместо этого, можно просто не запускать определённый процесс.

Система достаточно небольшая, чтобы в минимальной комплектации уместиться на одну дискету, вместе с этим она считается очень быстрой и должным образом «законченной» (практически не содержащей ошибок).

QNX Neutrino , выпущенная в 2001 году, перенесена на многие платформы, и сейчас способна работать практически на любом современном процессоре, используемом на рынке встраиваемых систем. Среди этих платформ присутствуют семейства x86, MIPS, PowerPC, а также специализированные семейства процессоров, такие, как SH-4, ARM, StrongARM и xScale.

Версия для некоммерческого использования доступна для скачивания на веб-сайте разработчика.

LynxOS - Unix-подобная операционная система реального времени, разработанная для встраиваемых систем, совместимая со стандартами POSIX и, в последнее время, с операционной системой GNU/Linux. LynxOS используется преимущественно в авиации, системах управления промышленными процессами и в области телекоммуникаций.

ChorusOS - микроядерная операционная система реального времени, разработанная для встраиваемых систем. В 1997 году Sun Microsystems купила Chorus systems, компанию, создавшую ChorusOS. В августе 2002 года Основатели Chorus Systems организовали новую компанию VirtualLogix и занялись разработкой встраиваемых систем, используя Linux и ChorusOS.

Nucleus - операционная система реального времени, созданная Accelerated Systems, подразделением по встраиваемым системам компании Mentor Graphics для различных процессорных платформ. Получила распространение в телевизионных декодерах, мобильных телефонах, и других переносных и карманных устройствах. Nucleus используется Garmin International в GPS-модуле, предназначенном для гражданской авиации.

OS-9 - многозадачная, многопользовательская операционная система реального времени, разработанная Microware Systems Corporation.
Используется для интерактивных и встраиваемых систем. В наши дни OS-9 принадлежит компании RadiSys Corporation расположенной в штате Орегон (США).

VxWorks - операционная система реального времени (ОСРВ), разрабатываемая компанией Wind River Systems (США).
Как и большинство других ОСРВ, VxWorks включает в себя многозадачное ядро с вытесняющим планировщиком и быстрым откликом на прерывания, средства межпроцессного взаимодействия и синхронизации, а также файловую систему и сетевую подсистему (стек протоколов TCP/IP). В комплект поставки входят средства для кросс-компиляции, мониторинга производительности (WindView), удаленной символьной отладки, а также эмуляции различных процессоров. Дополнительно поставляется значительное количество различных стеков протоколов, графических подсистем, и др. как от самой Wind River Systems, так и от третьих фирм. Множество поддерживаемых VxWorks встраиваемых платформ является одним из самых обширных среди ОСРВ.

Последняя версия интегрированной среды разработки Wind River Workbench (поставляющаяся с VxWorks версий 6.x, впрочем как и 5.x) построена на основе среды Eclipse. Предыдущая проприетарная среда разработки называлась Tornado.

Использование:

• Аппарат Mars Reconnaissance Orbiter на орбите Марса (используется система VxWorks)
• Зонды Spirit и Opportunity, а также аппарат Mars Reconnaissance Orbiter используют VxWorks на платформе POWER. Система используется и в других космических миссиях, например Deep Impact.
• Планируется использование в новейших авиалайнерах Boeing 787 .
• Коммуникационное оборудование многих компаний (например, Nortel, 3COM, Alcatel и др.).
  
• Linksys WRT54G (ver.5,6,...), NetGear WGR614 (ver. 5,6,7)
• Некоторые PostScript-принтеры.
• Медицинское оборудование компании Siemens AG (в частности, магнитно-резонансные томографы).
• Последние системы интерфейсов BMW iDrive

ОС2000 - Операционная система реального времени (ОС РВ) разработанная НИИСИ РАН по заказу МО РФ для микропроцессоров MIPS и Intel.
Эта ОС РВ предназначена для разработки программного обеспечения для систем (программно-аппаратных комплексов), работающих в режиме жёсткого реального времени.
Поддержка устройств:

• сетевые устройства Ethernet (протоколы NFS, FTP, Telnet), для Intel-версии поддержка ограничена ISA- и PCI-картами фирмы Realtek, NE2000-совместимых карт.
• накопительные устройства - флоппи- и жёсткие диски (файловые системы vfat и tar)

Имеется поддержка графической клиент-серверной подсистемы X Window System, ипользуемой в Unix-системах.