Операционная система для микроконтроллера. Российская операционная система реального времени для IT-оборудования и Интернета вещей Операционные системы реального времени для микроконтроллеров

Встра?иваемая систе?ма, встро?енная систе?ма (англ. 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-системах.

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

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

Рис. 1.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть два основных вида ОС: вытесняющая и кооперативная. В первом случае, переключение между задачами будет «жестким», т.е. если квант времени 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 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); }; }

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

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

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

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 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 == 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; } } }

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

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

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

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

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

В настоящее время ARM- и Cortex- базируемые микроконтроллеры доступны примерно по той же цене, что и 8-, или 16-битные микроконтроллеры. Предлагаемая ими дополнительная работоспособность означает, что специализированная система отлично справится с работой ОСРВ. Кроме того, возросшая сложность современных приложений позволит извлечь выгоду из проектов, использующих ОСРВ. Однако, микроконтроллер должен иметь по меньшей мере от 16 до 32 КВ флэш-памяти или памяти программ, чтобы можно было успешно использовать ОСРВ.

ВЫБОР ОСРВ

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

ВЫСОКОПРИОРИТЕТНЫЕ / НИЗКОПРИОРИТЕТНЫЕ

Основная проблема в системах реального времени – это время, требуемое для отклика на прерывание и запуска пользовательского кода (задачи), чтобы обработать прерывание. Системы, не использующие ОСРВ, известны как высокоприоритетные/низкоприоритетные (foreground/background) и работают, как показано на рис.1. Приложение вызывает модули для выполнения желаемых операций: низкоприоритетные модули выполняются последовательно в основном цикле программы, а прерывания обрабатывают асинхронные события с высоким приоритетом. Типичные приложения будут выполнять много опросов и программа будет становиться беспорядочной, по мере роста приложения. Без ОСРВ также приходится самому реализовывать такие полезные сервисы как временные задержки и таймеры, необходимые для выполнения программы со множеством конечных автоматов.

рисунок 1

МНОГОЗАДАЧНОСТЬ

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

Когда системе нужно запустить другую задачу по причине наступления более важного события, текущее содержимое регистров процессора сохраняется как часть текущей задачи. Контекст новой (более важной) задачи – перед выполнением ее кода восстанавливается в прежнее состояние. Эту процедуру выполняет так называемый переключатель контекста или переключатель задач. Текущая вершина стека для каждой задачи наряду с другой информацией хранится в структуре данных, называемой блоком управления задачей (Task Control Block), который управляется ОСРВ.

ПЛАНИРОВАНИЕ

Порядок, в котором выполняются задачи, определяется планировщиком (scheduler) или диспетчером (dispatcher). Существует два типа планировщиков: кооперативный (non pre-emptive) и вытесняющий (pre-emptive).

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

рисунок 2

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

рисунок 3

РЕСУРСЫ

Очевидная выгода от использования ОСРВ в том, что она сокращает время выхода на рынок (time to market), поскольку упрощает разработку, не потребляя при этом большого количества ресурсов процессора. uC/OS-II от Micrium, например, использует только от 6 до 24 КВ памяти программ и от 1 до 8 КВ памяти данных на ARM- устройствах. На небольших 8- или 16-битных платформах затраты ещё меньше – только от 4 до 16 КВ памяти программ.

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

КОММЕРЧЕСКИЕ ПРЕИМУЩЕСТВА ОСРВ

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

Коммерческая ОСРВ используется в сотнях, если не тысячах проектов, и базируется на испытанном коде, дающем уверенность в ее работоспособности. uC/OS-II от Micrium имеет сертификат FAA/FDA/IEC, что позволяет использовать ее в авиационной электронике, медицине и других типах приложений, требовательных к безопасности. Даже если устройство не нуждается в надежности ОСРВ, сертифицированных для авиационной электроники, всё таки приятно знать, что ОСРВ прошла расширенное тестирование. uC/OS-II также в высшей степени мобильна и может работать на более чем 45 различных процессорах. Код приложения может быть легко перенесён (портирован) с 8-битной на 32-битную архитектуру и даже на DSP. Пользователь обеспечивается полномасштабной поддержкой и документацией.

Управление временем (time management) – временные задержки и таймеры
- Управление задачами (task management) – создание, удаление, приостановка, возобновление
- Взаимоисключения
- Передача сообщений
- Передача сигналов

Преимущества использования ОСРВ подчеркиваются доступностью полного портфолио компонентов встроенного программного обеспечения (ПО), а также промежуточного ПО, включая стек TCP/IP, стек USB, стек CANbus, UART, файловые системы и графический интерфейс пользователя. Конечно, некоторые компоненты могут потребовать большего быстродействия, чем то, которым располагают low-end процессоры.

Два направления в индустрии коммерческих ОСРВ делают начало работы с ними еще проще. Многие ОСРВ, включая uC/OS-II теперь продаются на основе, не требующей авторских выплат, что гораздо выгоднее, чем использование ОСРВ, которые требуют непрерывной уплаты роялти. Зачастую, ОСРВ входит, в случае приобретения лицензии, во многие стартовые наборы (MCU starter kits).

ЗАКЛЮЧЕНИЕ

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

Что такое ОСРВ?

Зачем она нам нужна?

Обзор 3 известных ОСРВ.

FreeRTOS

Плюсы

Минусы

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

KeilRTX

Плюсы

Минусы

uc/os

Плюсы

Минусы

Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.

Другие интересные ОСРВ

Особенности разработки с использованием ОСРВ

Дополнительные библиотеки ОСРВ.