Встра?иваемая систе?ма, встро?енная систе?ма (англ. 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-системах.
Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.
Что такое ОСРВ?
Если мы посмотрим в Википедию, то увидим аж 4 определения.Если же говорить вкратце - то ОСРВ - это операционная система, реагирующая на внешние события в определенный промежуток времени. Отсюда мы и можем понять основное предназначение ОСРВ - приборы, в которых необходима быстрая реакция на события (однако ни в коем случае не путайте работу ОСРВ с прерываниями).
Зачем она нам нужна?
На то есть довольно много причин.Во-первых ОСРВ поддерживает многозадачность, приоритеты процессов семафоры и многое другое.
Во-вторых она очень легкая и почти не требует ресурсов.
В-третьих все вышесказанное мы можем получить практически на любом железе (например, FreeRTOS запускается даже на 8-битных AtMega).
Ну и в-четвертых: просто поиграться и получить удовольствие.
Обзор 3 известных ОСРВ.
Внимание: дальше идет мое личное мнение.FreeRTOS
Одна из самых популярных ОСРВ на сегодняшний день. Портирована на огромное количество железа. Оффициальный сайт .Плюсы
1) Бесплатная2) Портирована на большое количество железа
3) Мощный функционал
4) Есть различные библиотеки: графика, интернет и другое.
5) Хорошая документация.
Минусы
1)Довольно-таки сложный процесс портирования на новое железо.Вывод: Это действительно профессиональная ОСРВ с хорошей документацией. Будет хороша для новичка, если на его железо уже есть порт.
KeilRTX
До последнего времени эта ОСРВ была коммерческой, но недавно стала открытой. Работает только на архитектуре arm. Оффициальный сайт .Плюсы
1)Бесплатная2)Легко портируется на новое железо(в пределах архитектуры arm).
3) Есть различные библиотеки: графика, интернет и другое.
Минусы
1)Работать на в Keil с ней практически нереально2) Немного урезанный функционал
3) Поддерживается только arm.
4)(на личном опыте) Проигрывает многим ОСРВ по скорости.
Вывод: идеально подойдет для новичка и мелких проектов.
uc/os
Мощная коммерческая ОСРВ. Сайт .Плюсы
1) Огромное количество функций и библиотек.2) Поддерживает много железа
Минусы
1)Коммерческая.2) Сложна в использовании.
Вывод: назвать ее ОСРВ для новичка можно с большой натяжкой.
Другие интересные ОСРВ
RTLinux ОСРВ на основе обычного Линукса.QNX ОСРВ на основе Unix.
Особенности разработки с использованием ОСРВ
Ну во-первых надо понять следующее: ОСРВ- это не Windows. Его нельзя установить. Эта система просто компилируется с Вашей программой.При написании программ с ОСРВ не используются функции в обычном их понимании. Вместо функций используются процессы(или таски).Отличие в том что процессы, в отличии от функций, являются бесконечными циклами и никогда не заканчиваются(если только кто-то или он сам его не убъет - то есть выгрузит из памяти).
Если включено несколько процессов, то ОСРВ переключает их, выдавая машинное время и ресурсы по очереди. Вот тут то и возникает понятия приоритета процесса- если двум процессам единовременно нужно машинное время, то ОСРВ даст его тому, у кого приоритет больше.
В ОСРВ есть специальные функции задержки- чтобы время зря не пропадало на время задержки одного процесса выполняется второй.
Теперь поговорим о такой вещи как семафор- эта такая штука, которая управляет доступом процесса к ресурсам приложения. Для каждого ресурса есть маркер - когда процессу нужен ресурс - он его забирает и пользуется данным ресурсом. Если маркера нет, то процессу придется ждать, пока его вернут. Приведу пример: разные процессы отправляют информацию по одному UART. Если бы не было семафора, то они бы отправляли байты по очереди и получилась бы неразбериха. А так первый процесс взял маркер на UART отправил сообщение и отдал второму(и так - до бесконечности).
Дополнительные библиотеки ОСРВ.
Часто ОСРВ предлагают различные библиотеки для работы, например, с графикой, интернетом и т.д. Они действительно удобны и не стоит брезгать их использовать. Однако, помните, что без ОСРВ, для которой они написаны, они работать не будут.Вот примеры:
Для RTX
ОСРВ МАКС - бесплатная российская операционная система реального времени для мультиагентных когерентных систем.
МАКС воплощает классический функционал операционных систем данного типа и обладает рядом преимуществ, позволяющих значительно ускорить разработку встраиваемого ПО при создании новых устройств на основе микроконтроллеров. Особенно ярко преимущества новой ОС проявляются в вопросах организации взаимодействия множества устройств.
ОСРВ МАКС включает:
- Полнофункциональное ядро ОСРВ.
- Полный комплект исходных кодов.
- Документацию.
- Демо-приложения.
Или скачайте стабильную версию в составе среды разработки «MACS Master» на базе Eclipse
Поддержка средств разработки
|
Eclipse + GCC. |
ОСРВ МАКС - это:
Планировщик:
- динамическое создание и удаление задач,
- поддержка режимов вытесняющей и кооперативной многозадачности,
- выбор режима выполнения задач - привилегированного или непривилегированного.
- бинарные и считающие семафоры,
- рекурсивные и нерекурсивные мьютексы с поддержкой наследования приоритетов,
- события,
- очереди сообщений.
- для защиты стека процессов от переполнения,
- для защиты памяти по нулевому адресу,
- для защиты портов периферии от непривилегированного доступа.
- активизация пользовательских задач-обработчиков из предопределённого универсального обработчика прерываний, не требующего дополнительной настройки,
- возможность назначить несколько задач-обработчиков для одного прерывания,
- управление последовательностью обработки через приоритеты задач-обработчиков.
- измерение времени выполнения секций кода от точки до точки или в области видимости автоматической переменной,
- возможность автоматической настройки (повышение точности измерения за счет вычисления задержек собственной работы),
- формирование статистики замеров с группировкой секций по разделам (полное время выполнения всех секций с учётом и без учёта вложенности, минимальное/среднее/максимальное время выполнение секции, среднеквадратичное отклонение).
- синхронизация контекста задач между устройствами,
- обмен сообщениями внутри группы устройств.
Устройства под управлением микроконтроллеров используются для решения широкого спектра задач. ОСРВ МАКС - универсальная платформа для разработки встраиваемых приложений, и сфера её применения связана с целесообразностью использования микроконтроллеров в той или иной задаче.
Робототехника, БПЛА
- Система управления
Электроника управления устанавливается непосредственно на самом роботе и реализует алгоритмы, позволяющие ему решать поставленную задачу.
- Система телеметрии
Обеспечивает связь между роботом и удалённым терминалом, даёт возможность оператору получать сведения о состоянии робота и отправлять команды.
- Система позиционирования
Дополнительные внешние устройства позволяют роботам ориентироваться в помещениях и на открытой местности, находить путь до места назначения и к базовым станциям.
- Управление электропитанием и освещением
Обеспечение бесперебойного электроснабжения здания, контроль расхода электроэнергии, автоматическое включение/отключение освещения в зависимости от присутствия людей в помещении и контроль уровня освещённости (регулирование яркости света в разное время суток).
- Управление климатом
Поддержание комфортного микроклимата в помещении (регулирование температуры и влажности, вентиляция и очистка воздуха) осуществляется в зависимости от предпочтений пользователя, присутствия людей в помещении, а также внешних факторов (погода, время суток).
- Системы мониторинга и безопасности
Видеонаблюдение и контроль доступа в помещения, отслеживание событий, угрожающих безопасности жилища (взлом, возгорание, протечка воды) и автоматическое оповещение о них владельцев и соответствующие службы (охрана, противопожарная служба).
С развитием технологий бытовые приборы становятся более функциональными и удобными в использовании. Например, в настоящее время потребителю уже доступна техника, управляемая централизованно со смартфона или планшета вместо отдельных пультов ДУ. «Умная» техника требует всё меньше внимания со стороны человека, что даёт возможность пользователю значительно экономить время и деньги (роботы-пылесосы самостоятельно занимаются уборкой, функции отложенного старта и автоотключения контролируют время работы устройства и тем самым оптимизируют расход электроэнергии). Бурно развивающиеся технологии Интернета вещей (Internet of things, IoT) предполагают и вовсе полную автономность устройств, что порождает высокие требования к их программной начинке, а со стороны разработчиков этих устройств растет интерес к ОС, уже «из коробки» предоставляющих сервисы и протоколы взаимодействия, позволяющие обеспечить эту автономность.
Технологии Интернета вещей предполагают полную автономность устройств. Это порождает высокие требования к их программной начинке. Со стороны разработчиков этих устройств растет интерес к ОС, предоставляющих уже «из коробки» сервисы и протоколы взаимодействия, позволяющие обеспечить эту автономность.
Поддержка Mesh-сетей
- Надёжность и отказоустойчивость сети
Узлы сети соединяются друг с другом, образуя большое количество связей. Между узлами может формироваться несколько маршрутов следования трафика. При наличиии избыточных маршрутов выход из строя одного из промежуточных узлов не нарушит функционирование всей сети. Информация будет динамически перенаправлена по другому маршруту.
- Самоорганизация
Структура сети формируется автоматически по мере подключения/отключения узлов. При необходимости каждый узел может самостоятельно получить информацию о доступности узла назначения и построить оптимальный маршрут для обмена данными.
- Увеличение дальности связи
Каждое из устройств может обладать небольшой дальностью связи. Однако территориальное распределение множества соединённых друг с другом устройств позволяет обеспечить гораздо большее покрытие.
- Оптимальная конфигурация распределённой системы
Аппаратные ресурсы каждого устройства системы выбираются исходя из его функционального предназначения. Нет необходимости в мощных компьютерах для решения простых задач, например, идентификации объектов или измерения параметров внешней среды. Эти функции могут быть выполнены небольшими автономными модулями, что снижает стоимость распределенной системы.
- Автономное функционирование системы
Взаимодействуя друг с другом, устройства способны принимать решения и выполнять задачи без участия человека, что позволяет снизить затраты на обслуживание системы.
- Масштабируемость
Ввод и вывод устройств из сети происходит безболезненно и автоматически. Сеть «сама разберется», какое устройство в ней появилось и как его задействовать.
- Датчики, сенсоры, преобразователи
- Системы «умного дома», «умного города»
- Интернет вещей (Internet of things, IoT)
- Промышленная автоматика, управление
- Робототехника
- Медицинское оборудование
- Ж/д транспорт
- Потребительская электроника
- Системы связи
Я разработал немногим более 10 электронных устройств и вполне обходился в их низкоруровневой работе без операционной системы. Ситуация поменялась, когда функционал следующего девайса резко расширился. Кроме того, появилась необходимость в задаче, которая вызывается через заданные интервалы времени, причем точность вызова влияет на результат. Также стало понятно, что написать все ПО за выделенное время не получится, и оно будет создано позже. После недолгих размышлений я понял, что в проект необходимо включить операционную систему реального времени (ОСРВ или RTOS).
В отличие от ПК, где ОС – это больше слой для работы с системными ресурсами, для микроконтроллера ОСРВ – это в первую очередь планировщик задач, собственно он и играет главную роль в «реальном времени». На данный момент для меня важно обеспечить так называемое «псевдопараллельное» выполнение задач. То есть существует несколько задач с одинаковым приоритетом и важно вызывать их в заданном порядке через заданные интервалы времени.
Нагляден следующий пример: в проекте Евробот 2011 в системе присутствовало 18 периферийных устройств. 2 электронных платы можно было по функционалу объединить в одно. Снизилась бы их стоимость, повысилась надежность (уменьшили число компонентов в системе), увеличилось количество свободного места в корпусе. Обстоятельство осложняет то, что число задач растет пропорционально и тут уже не обойтись без ОС. Также ОСРВ помогает избежать возможных простоев работы процессора, например, во время преобразования АЦП вы можете заблокировать эту задачу и выполнять другие, тем самым правильно распределяя работу устройства. Важно и то, что теперь устройство не упадет из-за сбоя в задаче, вместо этого возможно сохранение частичной работоспособности (хотя это и может привести к непредсказуемым результатам). За счет чего мы обеспечиваем рост этих показателей? По сути, мы выжимаем из МК все возможное, эффективно используя его вычислительные возможности.
После недолгих поисков выбор пал на freeRTOS. Эта ОСРВ распространяется в исходниках на С и портирована на 27 архитектур. Последнее обстоятельство для меня – решающее. Оно снизит трудозатраты при работе с МК других производителей. Сейчас же меня больше интересует порт для AVR.
Наличие ОСРВ freeRTOS в проекте съедает у вас около 9.8 Кб памяти программ и 1.8 Кб ОЗУ. К примеру для ATmega32 и компиляторе WinAVR это 60% и 85% соответственно. Уже для этой модели создать девайс с большим функционалом сложно – не хватит памяти. Но эта проблема отпадает при использовании новых моделей AVR. Это совершенно нипочем для Mega2560 с ее 256Кб памяти программ и 8 Кб ОЗУ. Тенденция будущих МК только сопутствует успеху ОСРВ.
Бегло пробежавшись по рунету, я с удивлением обнаружил, что нет документации на ОС на русском языке. Да какое тут! Оригинальная документация распространяется за дополнительную стоимость. Ситуацию упростила статья Андрея Курница ([email protected]) из журнала «Компоненты и технологи». По согласию с автором я буду использовать материалы статьи в переработанном варианте. Его статья вполне может послужить документацией на русском языке. Но оригинал недоступен в печатном виде, сайт журнала лежит, поэтому материал придется немного переработать. В целом, автор сделал отличную статью и нет смысла еще раз пройтись по теории, она будет полностью опубликована здесь. Оригинал статьи будет приложен в конце публикации. Также я заметил, что у пользователей возникли трудности при компиляции ОСРВ. Это связано с тем, что используется внешний makefile, в котором прописаны пути к папкам. Поэтому я приложу готовый проект в виде шаблона для AVR Studio и AVR Eclipse. К сожалению, родной makefile не выводит отладочную информацию, такую, как степень занятости ОЗУ и памяти программ, это пришлось пофиксить, добавив соответствующий стандартный вызов.
Итак, кратко про необходимость, в вашем проекте желательно использовать ОСРВ, если необходимо:
Организовать мультизадачность и поочередное выполнение задач
Обеспечить запуск задачи через строго определенные интервалы времени
Передать информацию от одной задачи к другой
Добавлять по мере необходимости новые задачи
Преимущества ОСРВ перед М К:
- Многозадачность. ОСРВ предоставляет программисту готовый, отлаженный механизм многозадачности. Каждую задачу в простом случае можно программировать отдельно, всю работу разбить между несколькими членами команды. Не нужно заботиться о переключении между задачами, это сделает планировщик.
- Временная база. Необходимо отмерять интервалы времени. ОСРВ должна иметь этот инструмент. Он позволит выполнять действия через строго выделенные интервалы времени.
- Обмен данными между задачами. Для этого в ОСРВ используется очередь.
- Синхронизация. Если разные задачи используют один и тот же ресурс, например последовательный порт, то можно использовать мьютексы и критические секции. Если необходимо выполнять задачи в строгой последовательности или при наступлении определенного события, то можно использовать семафоры или сигналы для синхронизации задач.
Недостатки ОСРВ :
1. Резкое увеличение потребной памяти программ для реализации ядра
2. Увеличение потребной ОЗУ для хранения стека каждой задачи, семафоров, очередей, мьютексов и других объектов ядра системы.
3. Задержки при переключении между задачами на сохранение контекста.
Описание freeRTOS :
FreeRTOS – это бесплатная ОС жесткого реального времени с открытым исходным кодом. Преимущественно написана на С, но присутствуют ассемблерные вставки. Она была разработана компанией Real Time Engineers ltd специально для встраиваемых систем. Недавно начал развиваться проект «SafeRTOS»- доработанный, документированный, протестированный и прошедший сертификацию на соответствие стандарту безопасности IEC 61508 вариант FreeRTOS. Этим проектом занималась немецкая компания и теперь safeRTOS используется в аэрокосмической промышленности и медицинской технике. Также существует проект openRTOS - коммерческая версия с гарантией производителя.
Основные характеристики freeRTOS :
1. Планировщик поддерживает 3 типа многозадачности:
Вытесняющую
Кооперативную
Гибридную
2. Размер ядра составляет 9.8 Кб в скомпилированном виде для AVR. (WINAVR)
3. Основа ядра – 4 файла на С.
4. Поддерживает задачи и сопрограммы. Сопрограммы специально созданы для МК с малым объемом ОЗУ.
5. Богатые возможности трассировки.
6. Есть возможность отслеживать переполнение стека.
7. Нет программных ограничений на количество одновременно выполняемых задач.
8. Нет ограничения на количество приоритетов задач.
9. Нескольким задачам может быть назначен одинаковый приоритет
10. Развитые средства синхронизации «задача-задача» и «задача-прерывание»:
Очереди
Двоичные семафоры
Счетные семафоры
Рекурсивные семафоры
Мьютексы
11. Мьютексы с наследованием приоритета.
12. Поддержка модуля защиты памяти для Cortex-M3
13. Поставляется в отлаженном виде с демо-проектами для различных платформ и компиляторов.
14. Бесплатна. Можно использовать в проектах без раскрытия исходного кода в соответствии с расширенной лицензией GPL.
15. Документация платная, но доступна в онлайн здесь.
16. Время переключения контекста для AVR с кварцем на 16Мгц составит всего 20.8 мкс. Именно столько нужно для сохранения данных в стек задачи и вызов следующей. (Интересное замечание, если сравнить это с PIC18xxx, то контроллер от AVR делает это быстрее в 4 раза!!!, скорее всего это связано с качеством компилятора)
Вытесняющая многозадачность означает, что выполняющаяся задача с низким приоритетом перекрывается готовой задачей с более высоким приоритетом. Переключение между задачами происходит через равные кванты времени. Поэтому прежде, чем выскопоприоритетная задача начнет выполнение, должен закончиться текущий квант времени, когда выполняется низкоприоритетная.
Таким образом, время реакции FreeRTOS на внешние события в режиме вытесняющей многозадачности-не больше одного кванта времени планировщика, который можно задавать в настройках. По умолчанию он равен 1 мс.
Если готовы к выполнению несколько задач с одинаковым приоритетом, то в таком случае планировщик выделяет каждой из них по одному кванту времени, по истечении которого управление получает следующая задача с таким же приоритетом, и так далее по кругу.
Кооперативная многозадачность отличается от вытесняющей тем, что планировщик самостоятельно не может прервать выполнение текущей задачи, даже готовая к выполнению задача с большим приоритетом. Каждая задача должна самостоятельно передать управление планировщику. Таким образом, высокоприоритетная задача будет ожидать, пока низкоприоритетная завершит свою работу и отдаст управление планировщику. Время реакции системы на внешнее событие становится неопределенным и зависит от того, как долго текущая задача будет выполняться до передачи управления. Кооперативная многозадачность применялась в семействе ОС Windows 3.x.
Вытесняющая и кооперативная концепции многозадачности объединяются вместе в гибридной многозадачности, когда вызов планировщика происходит каждый квант времени, но, в отличие от вытесняющей многозадачности, программист имеет возможность сделать это принудительно в теле задачи. Особенно полезен этот режим, когда необходимо сократить время реакции системы на прерывание. Допустим, в текущий момент выполняется низкоприоритетная задача, а высокоприоритетная ожидает наступления некоторого прерывания. Далее происходит прерывание, но по окончании работы обработчика прерываний выполнение возвращается к текущей низкоприоритетной задаче, а высокоприоритетная ожидает, пока закончится текущий квант времени. Однако если после выполнения обработчика прерывания передать управление планировщику, то он передаст управление высокоприоритетной задаче, что позволяет сократить время реакции системы, связанное с внешним событием.
С чего на чат ь?
Начать разработку микроконтроллерного устройства, работающего под управлением FreeRTOS, можно с загрузки ее последней версии .
Дистрибутив FreeRTOS доступен в виде обычного или самораспаковывающегося ZIP-архива. Дистрибутив Содержит непосредственно код ядра (в виде нескольких заголовочных файлов и файлов с исходным кодом) и демонстрационные проекты (по одному проекту на каждую среду разработки для каждого порта). Далее следует распаковать архив в любое подходящее место на станции разработки.
Несмотря на достаточно большое количество файлов в архиве, структура директорий на самом деле проста. Если планируется проектировать устройства на 2-3 архитектурах в 1-2 средах разработки, то большая часть файлов, относящихся к демонстрационным проектам и различным средам разработки, не понадобится.
Подробная структура директорий приведена на рисупке.
Весь исходный код ядра находится в директории /Source.
Содержимое:
1.tasks.c - реализация механизма задач, планировщик
2. queue.c - реализация очередей
3. list.c - внутренние нужды планировщика, однако функции могут использоваться и в прикладных программах.
4. croutine.c - реализация сопрограмм (может отсутствовать в случае, если сопрограммы не используются).
Заголовочные файлы, которые находятся в директории source/include
1. tasks.h, queue.h, tist.h, croutine.h - заголовочные файлы соответственно для одноименных файлов с кодом.
2. FreeRTOS.h -содержит препроцессорные директивы для настройки компиляции.
3. mpu_wrappers.h - содержит переопределения функций программного интерфейса (API-функций) FreeRTOS для поддержки модуля защиты памяти (MPU).
4. portable.h -платформозависимые настройки.
5. projdefs.h -некоторые системные определения
6. semphr.h - определяет API-функции для работы с семафорами, которые реализованы на основе очередей.
7. StackMacros.h - содержит макросы для контроля переполнения стека. Каждая аппаратная платформа требует небольшой части кода ядра, которая реализует взаимодействие FreeRTOS с этой платформой. Весь платформенно-зависимый код находится в поддиректории /Source/Portable , где он систематизирован но средам разработки (IAR, GCC и т.д.) и аппаратным платформам (например, AtmelSAM7S64,MSP430F449). К примеру, поддиректория /Source/Portable/ GCC/ATMega323 содержит файлы port.c и portmacro.h, реализующие сохранение/восстановление контекста задачи, инициализацию таймера для создания временной базы, инициализацию стека каждой задачи и другие аппаратно-зависимые функции для микроконтроллеров семейства mega AVR и компилятора WinAVR (GCC).
Отдельно следует выделить поддиректорию /Source/Portable/MemMang , в которой содержатся файлы heap_l.c, heap_2.c, heap_3.c , реализующие 3 различных механизма выделения памяти для нужд FreeRTOS, которые будут подробно описаны позже.
В директории /Demo находятся готовые к компиляции и сборке демонстрационные проекты. Общая часть кода для всех демонстрационных проектов выделена в поддиректорию /Demo/Commo n.
Чтобы использовать FreeRTOS в своем проекте, необходимо включить в него файлы исходного кода ядра и сопутствующие заголовочные файлы. Нет необходимости модифицировать их или понимать их реализацию.
Например, если планируется использовать порт для микроконтроллеров MSP430 и GCC-компилятор, то для создания проекта -с нуля» понадобятся поддиректории /Source/ Portable/GCC/MSP430_GCC и /Source/Portable/ MemMang . Все остальные поддиректории из директории /Source/Portable не нужны и могут быть удалены.
Если же планируется модифицировать существующий демонстрационный проект (что, собственно, и рекомендуется сделать в начале изучения FreeRTOS), то понадобятся также поддиректории /Demo/msp430_GCC и /Demo/Common . Остальные поддиректории, находящиеся в /Demo, не нужны и могут быть удалены.
При создании приложения рекомендуется использовать makefile (или файл проекта среды разработки) от соответствующего демонстрационного проекта как отправную точку. Целесообразно исключить из сборки (build) файлы из директории /Demo, заменив их своими, а файлы из директории /Source - нетронутыми. Следует упомянуть также о заголовочном файле FreeRTOSConfig.h , который находится в каждом демонстрационном проекте. FreeRTOSConfig.h содержит определения (#define), позволяющие произвести настройку ядра FreeRTOS:
1. Набор системных функций.
2. Использование сопрограмм.
3. Количество приоритетов задач и сопрограмм
4. Размеры памяти (стека и кучи).
5. Тактовая частота МК.
6. Период работы планировщика времени, выделяемый каждой задаче выполнения, который обычно равен 1 мс. Отключение некоторых системных функций и уменьшение количества приоритетов (уменьшает расход памяти).
В дистрибутив FreeRTOS включены также средства для конвертирования трассировочной информации, полученной от планировщика, в текстовую форму (директория /ТгасеСоn ) и текст лицензии (директория /License ).
Выводы
С помощью первой статьи цикла читатель познакомился с операционной системой ля микроконтроллеров FreeRTOS. Показаны особенности работы. Описапо содержимое дистрибутива FreeRTOS. Приведены основные шаги, с которых следует начинать разработку устройства, работающего под управлением FreeRTOS.
В следующих публикациях внимание будет уделено механизму многозадачности, а именно задачам и сопрограммам. Будет приведен образец работы планировщика на примере микроконтроллеров AVR фирмы Atmel и компилятора WinAVR (GCC).
Я постоянно задаюсь этим вопросом, во время занятий своим хобби, – разработкой домашней системы автоматического контроля (умного дома), основанной на 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 сообществе. В большинстве случаев, быстрее и легче разрабатывать на этих системах, так что зачастую это лучший выбор для большинства проектов.
Для микроконтроллеров остаются только области низковольтных устройств, операций реального времени и устройств низкой стоимости.
Это не зависит от того, что микроконтроллеры могут казаться «веселее» чем ПК. Это то, с чем придется смириться.
Перевод с английского языка оригинального поста