Что дает операционная система микроконтроллеру. Микроконтроллеры устарели? Дополнительные библиотеки осрв

Я разработал немногим более 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. Обмен данными между задачами. Для этого в ОСРВ используется очередь.
4. Синхронизация. Если разные задачи используют один и тот же ресурс, например последовательный порт, то можно использовать мьютексы и критические секции. Если необходимо выполнять задачи в строгой последовательности или при наступлении определенного события, то можно использовать семафоры или сигналы для синхронизации задач.

Недостатки ОСРВ :

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).

ОСРВ МАКС - бесплатная российская операционная система реального времени для мультиагентных когерентных систем.

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

• Полнофункциональное ядро ОСРВ.
• Полный комплект исходных кодов.
• Документацию.
• Демо-приложения.

Или скачайте стабильную версию в составе среды разработки «MACS Master» на базе Eclipse

Поддержка средств разработки

Eclipse + GCC.

ОСРВ МАКС - это:

Планировщик:

• динамическое создание и удаление задач,
• поддержка режимов вытесняющей и кооперативной многозадачности,
• выбор режима выполнения задач - привилегированного или непривилегированного.

• бинарные и считающие семафоры,
• рекурсивные и нерекурсивные мьютексы с поддержкой наследования приоритетов,
• события,
• очереди сообщений.

• для защиты стека процессов от переполнения,
• для защиты памяти по нулевому адресу,
• для защиты портов периферии от непривилегированного доступа.

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

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

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

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

• Система управления

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

• Система телеметрии

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



• Система позиционирования

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

• Управление электропитанием и освещением

  Обеспечение бесперебойного электроснабжения здания, контроль расхода электроэнергии, автоматическое включение/отключение освещения в зависимости от присутствия людей в помещении и контроль уровня освещённости (регулирование яркости света в разное время суток).



• Управление климатом

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



• Системы мониторинга и безопасности

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

С развитием технологий бытовые приборы становятся более функциональными и удобными в использовании. Например, в настоящее время потребителю уже доступна техника, управляемая централизованно со смартфона или планшета вместо отдельных пультов ДУ. «Умная» техника требует всё меньше внимания со стороны человека, что даёт возможность пользователю значительно экономить время и деньги (роботы-пылесосы самостоятельно занимаются уборкой, функции отложенного старта и автоотключения контролируют время работы устройства и тем самым оптимизируют расход электроэнергии). Бурно развивающиеся технологии Интернета вещей (Internet of things, IoT) предполагают и вовсе полную автономность устройств, что порождает высокие требования к их программной начинке, а со стороны разработчиков этих устройств растет интерес к ОС, уже «из коробки» предоставляющих сервисы и протоколы взаимодействия, позволяющие обеспечить эту автономность.

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

• Надёжность и отказоустойчивость сети

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



• Самоорганизация

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



• Увеличение дальности связи

  Каждое из устройств может обладать небольшой дальностью связи. Однако территориальное распределение множества соединённых друг с другом устройств позволяет обеспечить гораздо большее покрытие.

• Оптимальная конфигурация распределённой системы

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



• Автономное функционирование системы

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



• Масштабируемость

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

• Датчики, сенсоры, преобразователи
• Системы «умного дома», «умного города»
• Интернет вещей (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, программировании флеш-памяти, а также архитектурах и принципах встроенной эмуляции.

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

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

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

ВЫБОР ОСРВ

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

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

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

рисунок 1

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

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

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

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

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

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

рисунок 2

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

рисунок 3

РЕСУРСЫ

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ