Микро операционные системы на контроллерах avr. Российская операционная система реального времени для IT-оборудования и Интернета вещей
ОСРВ МАКС - бесплатная российская операционная система реального времени для мультиагентных когерентных систем.
МАКС воплощает классический функционал операционных систем данного типа и обладает рядом преимуществ, позволяющих значительно ускорить разработку встраиваемого ПО при создании новых устройств на основе микроконтроллеров. Особенно ярко преимущества новой ОС проявляются в вопросах организации взаимодействия множества устройств.
ОСРВ МАКС включает:
- Полнофункциональное ядро ОСРВ.
- Полный комплект исходных кодов.
- Документацию.
- Демо-приложения.
Или скачайте стабильную версию в составе среды разработки «MACS Master» на базе Eclipse
Поддержка средств разработки
|
Eclipse + GCC. |
ОСРВ МАКС - это:
Планировщик:
- динамическое создание и удаление задач,
- поддержка режимов вытесняющей и кооперативной многозадачности,
- выбор режима выполнения задач - привилегированного или непривилегированного.
- бинарные и считающие семафоры,
- рекурсивные и нерекурсивные мьютексы с поддержкой наследования приоритетов,
- события,
- очереди сообщений.
- для защиты стека процессов от переполнения,
- для защиты памяти по нулевому адресу,
- для защиты портов периферии от непривилегированного доступа.
- активизация пользовательских задач-обработчиков из предопределённого универсального обработчика прерываний, не требующего дополнительной настройки,
- возможность назначить несколько задач-обработчиков для одного прерывания,
- управление последовательностью обработки через приоритеты задач-обработчиков.
- измерение времени выполнения секций кода от точки до точки или в области видимости автоматической переменной,
- возможность автоматической настройки (повышение точности измерения за счет вычисления задержек собственной работы),
- формирование статистики замеров с группировкой секций по разделам (полное время выполнения всех секций с учётом и без учёта вложенности, минимальное/среднее/максимальное время выполнение секции, среднеквадратичное отклонение).
- синхронизация контекста задач между устройствами,
- обмен сообщениями внутри группы устройств.
Устройства под управлением микроконтроллеров используются для решения широкого спектра задач. ОСРВ МАКС - универсальная платформа для разработки встраиваемых приложений, и сфера её применения связана с целесообразностью использования микроконтроллеров в той или иной задаче.
Робототехника, БПЛА
- Система управления
Электроника управления устанавливается непосредственно на самом роботе и реализует алгоритмы, позволяющие ему решать поставленную задачу.
- Система телеметрии
Обеспечивает связь между роботом и удалённым терминалом, даёт возможность оператору получать сведения о состоянии робота и отправлять команды.
- Система позиционирования
Дополнительные внешние устройства позволяют роботам ориентироваться в помещениях и на открытой местности, находить путь до места назначения и к базовым станциям.
- Управление электропитанием и освещением
Обеспечение бесперебойного электроснабжения здания, контроль расхода электроэнергии, автоматическое включение/отключение освещения в зависимости от присутствия людей в помещении и контроль уровня освещённости (регулирование яркости света в разное время суток).
- Управление климатом
Поддержание комфортного микроклимата в помещении (регулирование температуры и влажности, вентиляция и очистка воздуха) осуществляется в зависимости от предпочтений пользователя, присутствия людей в помещении, а также внешних факторов (погода, время суток).
- Системы мониторинга и безопасности
Видеонаблюдение и контроль доступа в помещения, отслеживание событий, угрожающих безопасности жилища (взлом, возгорание, протечка воды) и автоматическое оповещение о них владельцев и соответствующие службы (охрана, противопожарная служба).
С развитием технологий бытовые приборы становятся более функциональными и удобными в использовании. Например, в настоящее время потребителю уже доступна техника, управляемая централизованно со смартфона или планшета вместо отдельных пультов ДУ. «Умная» техника требует всё меньше внимания со стороны человека, что даёт возможность пользователю значительно экономить время и деньги (роботы-пылесосы самостоятельно занимаются уборкой, функции отложенного старта и автоотключения контролируют время работы устройства и тем самым оптимизируют расход электроэнергии). Бурно развивающиеся технологии Интернета вещей (Internet of things, IoT) предполагают и вовсе полную автономность устройств, что порождает высокие требования к их программной начинке, а со стороны разработчиков этих устройств растет интерес к ОС, уже «из коробки» предоставляющих сервисы и протоколы взаимодействия, позволяющие обеспечить эту автономность.
Технологии Интернета вещей предполагают полную автономность устройств. Это порождает высокие требования к их программной начинке. Со стороны разработчиков этих устройств растет интерес к ОС, предоставляющих уже «из коробки» сервисы и протоколы взаимодействия, позволяющие обеспечить эту автономность.
Поддержка Mesh-сетей
- Надёжность и отказоустойчивость сети
Узлы сети соединяются друг с другом, образуя большое количество связей. Между узлами может формироваться несколько маршрутов следования трафика. При наличиии избыточных маршрутов выход из строя одного из промежуточных узлов не нарушит функционирование всей сети. Информация будет динамически перенаправлена по другому маршруту.
- Самоорганизация
Структура сети формируется автоматически по мере подключения/отключения узлов. При необходимости каждый узел может самостоятельно получить информацию о доступности узла назначения и построить оптимальный маршрут для обмена данными.
- Увеличение дальности связи
Каждое из устройств может обладать небольшой дальностью связи. Однако территориальное распределение множества соединённых друг с другом устройств позволяет обеспечить гораздо большее покрытие.
- Оптимальная конфигурация распределённой системы
Аппаратные ресурсы каждого устройства системы выбираются исходя из его функционального предназначения. Нет необходимости в мощных компьютерах для решения простых задач, например, идентификации объектов или измерения параметров внешней среды. Эти функции могут быть выполнены небольшими автономными модулями, что снижает стоимость распределенной системы.
- Автономное функционирование системы
Взаимодействуя друг с другом, устройства способны принимать решения и выполнять задачи без участия человека, что позволяет снизить затраты на обслуживание системы.
- Масштабируемость
Ввод и вывод устройств из сети происходит безболезненно и автоматически. Сеть «сама разберется», какое устройство в ней появилось и как его задействовать.
- Датчики, сенсоры, преобразователи
- Системы «умного дома», «умного города»
- Интернет вещей (Internet of things, IoT)
- Промышленная автоматика, управление
- Робототехника
- Медицинское оборудование
- Ж/д транспорт
- Потребительская электроника
- Системы связи
Эта статья посвящена операционной системе реального времени (ОСРВ), которая называется 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, программировании флеш-памяти, а также архитектурах и принципах встроенной эмуляции.
Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.
Что такое ОСРВ?
Если мы посмотрим в Википедию, то увидим аж 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
Что приходит на ум когда слышишь операционная система? Наверняка форточки, линукс, макось.. или что нибудь подобное. Верно, и на вопрос зачем она нужна, все уверенно ответят: послушать музыку, поиграть в игру (по интернету!), разговаривая при этом с другом по скайпу. Заодно созерцая, как мигает светодиодик, получив байт с юарта =).
А если копнуть глубже, то прослушивание музыки, пересылка данных по Интернету — это все одиночные процессы, а так как процессор у нас один, то одновременно он может выполнять только одну задачу. Поэтому задачи выполняются поочередно небольшими «порциями», суть ОС делать это незаметно для пользователя: чтобы звук не хрипел и байтики слались и все работало одновременно. При этом, если одна из задач «повиснет», то все остальное продолжало работать.
Если отбросить все лишние плюшки и оставить голую суть, то в первую очередь ОС это просто таймер, который отсчитывает равные промежутки времени, а также сам без участия пользователя переключается между задачами, выполняет какую то часть и снова переключается. Также нужно учесть, что большинство задач могут не успевать выполниться за один квант времени, поэтому нужно сохранять состояние задачи в момент переключения на другую, а в следующий раз восстанавливать состояние переменных. Управлением всего этого занимается планировщик заданий.
Есть два основных вида ОС: вытесняющая и кооперативная. В первом случае, переключение между задачами будет «жестким», т.е. если квант времени 1мс, то сначала первая задача будет выполняться ровно 1мс, затем вторая ровно 1мс и т.д. Такие оси называются реального времени (ОСРВ). У кооперативных немного попроще, процесс сам должен сказать что «я выполнился», поэтому к ОСРВ их отнести нельзя.
Впердолить вытесняющую на мелкие AVR не получится по причине небольшого количества ОЗУ. Из имеющихся вариантов кооперативок, мне приглянулась mRTOS, почитать подробности сей системы можно на сайте автора (легко гуглится). Главная причина ее использования — простота, наличие готовой версии под CAVR, для понимания общих принципов самое то.
Итак, остались главные вопросы, зачем и когда применять ось. Теоретически, все тоже самое, что вы сделаете с осью, вы можете сговнякать без нее, ибо ресурсы одни и те же. От того, что вы приладите ее к проекту, мегагерцы в космос не взлетят, железо останется тем же, следовательно ресурсы те же.
Поэтому стоит задать себе несколько вопросов:
1.Сможете ли вы распорядиться грамотно ресурсами?
2. Не предполагается ли в процессе написания прошивки изобретать такой же велосипед, подобный планировщику?
3. Насколько читаем Ваш код? Способны ли Вы через полгода-год открыть его и сходу разобраться?
4. Один ли Вы пишите или группой?
На первый вопрос дать ответ сложно, ибо все зависит от криворукости разработчика. Со вторым все более понятно, если есть много независимых задач и планируется выполнять их через определенные промежутки времени, то лучше посмотреть в сторону ОС. С третьим тоже понятно, гораздо проще разбираться в отдельной задаче, чем ковырять зависимости в основном цикле. Если Вы пишите не один, то тут тоже есть плюсы, ибо каждый может писать свою задачу отдельно, не мешая остальным.
Объединяя выше сказанное, сфера применения довольно специфична, под определенный круг задач. Не стоит пихать ее в каждый проект. Для большинства радиолюбительских поделок ось излишня, но имея представление о ней раньше, наверняка бы засунул ее пару проектов.
Теперь заглянем под капот. Для запуска mRTOS к проекту нужно подключить mrtos.c и заинклюдить mrtos.h. Структура кода немного отличается от привычного
#include |
#include Теперь подробнее. количество задач указывается в 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 В качестве бонуса я попробовал сделать полифоническую (двухголосую) мелодию «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;
}
}
} Чтобы смешать два канала использовал простенькую схемку. Итого небольшой кусочек Для желающих прошивка Я разработал немногим более 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). void
task1()
{
while
(1
)
{
PORTB.0 =
!
PORTB.0;
WAIT(100
)
;
}
;
}
create_task(task1,
1
,
Active)
;
#include
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
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
;
}
}
}