Примеры встроенных систем
Робот, такой как марсоход , показанный на рисунке 1.1 , является встроенной системой. Сотовый телефон, PDA , или портативный мультимедиа плеер, показанные на рисунке 1.2 , являются встроенными устройствами. Даже электрическая зубная щетка, показанная на рисунке 1.2 , является встроенной системой. Небольшой микроконтроллер в зубной щетке обеспечивает программируемое управление скоростью и индикацию состояния заряда батареи. Высококачественные автомобили могут содержать около ста встроенных микроконтроллеров. Типичное домовладение среднего класса имеет около пятидесяти встроенных устройств. Для каждого ПК в мире имеется более сотни встроенных устройств. В общей сложности, встроенные устройства составляют большую часть мирового производства микропроцессоров.
Рис.
1.1.
Как видно в таблице 1.1 , встроенные устройства можно найти в разнообразных продуктах, включая самолеты и военные системы, биомедицинские системы, автомобили, коммуникацию, компьютерные устройства в/в, электронные инструменты, домашняя электроника, промышленное оборудование, офисные машины, персональные устройства, роботы, и интеллектуальные игрушки. Встроенные устройства можно найти повсюду.
Конструкторы встроенных систем часто сталкиваются со сложными проектными задачами. Встроенные системы должны быть надежными. Многие встроенные устройства не могут ломаться, и не могут быть перезагружены. Программное обеспечение невозможно обновить во многих встроенных устройствах. Многие устройства имеют жесткие конструкционные ограничения по производительности и потреблению энергии. Некоторым устройствам необходимо работать от батареи длительный период времени. Кроме того, потребительские устройства обычно очень быстро выходят на рынок с новыми продуктами и имеют жесткую ценовую конкуренцию. Во многих приложениях существуют ограничения реального времени и многие устройства имеют ограниченную память и вычислительную мощность .
|
|
|
Рис. 1.2.
| Авиационные & Военные системы | Автопилоты самолетов, авионика и навигационные системы, системы автоматической посадки, системы наведения, управление двигателем. |
|---|---|
| Биомедицинские системы | Cистемы компьютерной томографии и ультразвукового исследования, мониторинг пациентов, кардиостимуляторы. |
| Автомобили | Управление двигателем, антиблокировочные тормозные системы, противобуксовочная тормозная система, управление подушками безопасности, управление системой обогрева и кондиционирования воздуха, навигация GPS, спутниковое радио, системная диагностика. |
| Коммуникация | Коммуникационные спутники, сетевые маршрутизаторы, коммутаторы, концентраторы. |
| Потребительская электроника | телевизоры, духовки, посудомоечные машины, плееры DVD, стереосистемы, системы безопасности, управление поливом газонов, термостаты, фотокамеры, радиочасы, автоответчики, декодеры кабельного телевидения, другие устройства. |
| Устройства в/для компьютера | Клавиатуры, мыши, принтеры, сканеры, дисплеи, модемы, устройства жестких дисков, устройства DVD, графические платы, устройства USB. |
| Электронные инструменты | Системы сбора данных, осциллографы, вольтметры, генераторы сигналов, логические анализаторы . |
| Промышленное оборудование | Управление лифтами, системы наблюдения, роботы, станки с ЧПУ, программируемые логические контроллеры, промышленные системы автоматизации и управления. |
| Офисные машины | факс-аппараты, копиры, телефоны, калькуляторы, кассовые аппараты. |
| Персональные устройства | сотовые телефоны, переносные плееры MP3, видео-плееры, персональные цифровые помощники (PDA), электронные наручные часы, портативные видеоигры, цифровые камеры, системы GPS. |
| Роботы | Промышленные роботы , автономные транспортные средства, космические исследовательские роботы (например, роботы- марсоходы ) |
| Игрушки | системы видеоигр, игрушки роботы типа "Aibo", "Furby", и "Elmo". |
Операционные системы реального времени
Системы реального времени должны отвечать на внешние параметры ввода и создавать новые результаты вывода за ограниченное время, как показано на рисунке 1.3 . Время ответа должно быть ограничено. Очень длительное время ответа может привести к отказу систем реального времени.
Иллюстративным примером системы реального времени является контроллер автомобильной воздушной подушки безопасности. Когда датчики движения воздушной подушки ( акселерометры ) распознают столкновение, системе необходимо среагировать, раскрывая воздушную подушку в течение 10 мс, или система не сработает нужным образом. На высокой скорости с задержкой более 10 мс водитель уже столкнется с рулевым колесом до того, как раскроется подушка.
Рис. 1.3.
В мягкой системе реального времени приоритет имеют критически важные задачи. Мягкая система реального времени обычно удовлетворяет ограничениям отклика реального времени. Примером типичной мягкой системы реального времени является плеер мультимедиа . Плеер может иногда пропустить видео кадр или аудио сэмпл, и пользователь может это даже не заметить, пока плеер правильно работает большую часть времени.
В жесткой системе реального времени новый результат вывода всегда должен быть вычислен в указанных границах времени, или система не сработает. В качестве примера жесткой системы реального времени рассмотрим систему дистанционного управления рулями (т.е., управляемую компьютером). В системе управления полетом самолета, когда летчик перемещает штурвал управления, рули управления полетом должны в ответ переместиться очень быстро, или самолет потеряет устойчивость и упадет. Чтобы обеспечить безопасность , FAA постоянно проверяет и сертифицирует реакцию в реальном времени управляемых компьютером симуляторов полета и самолеты.
Процедуры обмена страниц виртуальной памяти и сборки мусора, необходимые объектно-ориентированным языкам, могут вызывать проблемы в жестких системах реального времени. Даже кэширование является иногда проблемой, так как может приводить к изменению времени выполнения программы.
Многие встроенные системы являются системами реального времени с несколькими входами и выходами. Несколько событий происходят независимо друг от друга. Программирование упрощается при разделении задач, но это требует от ЦП постоянного переключения между различными задачами. Операционная система , которая поддерживает мультизадачность, обеспечивает разделение времени ЦП между несколькими задачами. ОС обеспечивает также элементы синхронизации, необходимые для координации действий между различными задачами, выполняющимися параллельно.
Операционные системы часто классифицируют по их характеристикам реального времени. Операционная система реального времени должна быть тщательно спроектирована, чтобы поддерживать приложения реального времени. Недавнее исследование приходит к выводу, что 95% приложений реального времени требуют ограниченного времени ответа в диапазоне от 0.5 до 10 мсек. Только 10% отклонение (колебание от 50 микросекунд до 1 мсек) во времени ответа может быть допустимо. Согласно таким требованиям большинство операционных систем общего назначения не являются системами реального времени. Согласно этим критериям встроенная ОС, такая как Windows XP, может рассматриваться в лучшем случае только как мягкая ОС реального времени . Для Windows XP существуют некоторые инструменты сторонних поставщиков, которые улучшают время ответа.
Операционные системы для встроенных систем
Большинство новых устройств имеет сложное программное обеспечение , которое требуется для мультизадачности, синхронизации задач, поддержки широкого диапазона устройств ввода/вывода, планирования и буферизации операций ввода/вывода, управления памятью, поддержки графических дисплеев, файловых систем, сетей, безопасности и управления питанием. Операционная система может предоставить все эти возможности, чтобы помочь разработчикам приложений. Прикладные программисты будут более продуктивными, так как они работают на более высоком уровне абстракции, используя эти средства, предоставляемые операционной системой.
Выпущенная недавно модель сотового телефона содержит более пяти миллионов строк кода. Немногие, если вообще какие-то проекты, будут иметь время и средства, необходимые для разработки всего этого кода полностью самостоятельно. В таких случаях имеет экономический смысл использовать существующую операционную систему. Сокращение времени разработки и снижение расходов вполне оправдают стоимость лицензии операционной системы.
Лицензионные отчисления типичной коммерческой встроенной ОС составляют только несколько долларов на устройство. Некоторые очень простые устройства могут обходиться без ОС, но новые устройства постоянно становятся все более сложными.
В связи с этим большинство встроенных устройств используют встроенную операционную систему. Встроенные операционные системы обычно разрабатываются большей частью на C/C++ и поставляются вместе с компилятором C/C++, ассемблером, и инструментами отладки, чтобы помочь разработчикам в разработке прикладных программ и тестировании устройства. Инструменты разработки встроенных систем должны также поддерживать выполнение программ с помощью кода, хранящегося в энергонезависимой памяти, такой как ROM или память Flash .
Привет, Хабр!
Сегодня я расскажу о такой интересной штуке как операционная система реального времени(ОСРВ). Не уверен, что это будет интересно для бывалых программистов, но, думаю, новичкам понравится.
Что такое ОСРВ?
Если мы посмотрим в Википедию, то увидим аж 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
Эта статья посвящена операционной системе реального времени (ОСРВ), которая называется 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, программировании флеш-памяти, а также архитектурах и принципах встроенной эмуляции.
Что приходит на ум когда слышишь операционная система? Наверняка форточки, линукс, макось.. или что нибудь подобное. Верно, и на вопрос зачем она нужна, все уверенно ответят: послушать музыку, поиграть в игру (по интернету!), разговаривая при этом с другом по скайпу. Заодно созерцая, как мигает светодиодик, получив байт с юарта =).
А если копнуть глубже, то прослушивание музыки, пересылка данных по Интернету — это все одиночные процессы, а так как процессор у нас один, то одновременно он может выполнять только одну задачу. Поэтому задачи выполняются поочередно небольшими «порциями», суть ОС делать это незаметно для пользователя: чтобы звук не хрипел и байтики слались и все работало одновременно. При этом, если одна из задач «повиснет», то все остальное продолжало работать.
Если отбросить все лишние плюшки и оставить голую суть, то в первую очередь ОС это просто таймер, который отсчитывает равные промежутки времени, а также сам без участия пользователя переключается между задачами, выполняет какую то часть и снова переключается. Также нужно учесть, что большинство задач могут не успевать выполниться за один квант времени, поэтому нужно сохранять состояние задачи в момент переключения на другую, а в следующий раз восстанавливать состояние переменных. Управлением всего этого занимается планировщик заданий.
Есть два основных вида ОС: вытесняющая и кооперативная. В первом случае, переключение между задачами будет «жестким», т.е. если квант времени 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;
}
}
} Чтобы смешать два канала использовал простенькую схемку. Итого небольшой кусочек Для желающих прошивка Оба, 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, какие бы патчи на него не навешали, никогда не побьет микроконтроллеры в этой области, благодаря наличию у них системы прерываний. Для микроконтроллеров остаются только области низковольтных устройств, операций реального времени и устройств низкой стоимости. Это не зависит от того, что микроконтроллеры могут казаться «веселее» чем ПК. Это то, с чем придется смириться. Перевод с английского языка оригинального поста 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
;
}
}
}
Частично к этому меня побудило появление в продаже Stellaris Launchpad и Arduino Due . Они оба основаны на 32-битных микроконтроллерах, и во многом, очень похожи. Я изучил спецификации (datasheet) к обоим, и хотя они прилично отличаются по цене, они рассчитаны на одну целевую аудиторию. Я задумывался о том, что возможно мне стоит перейти с MSP430 на Stellaris, а может быть даже пересесть на принципиально иную систему, использовать что-то вроде Raspberry Pi, вместо микроконтроллеров.
В заключение, хочу сказать, что потратил много времени, пытаясь найти области, где применение микроконтроллеров в моих проектах имеет преимущество. И все выглядит так, что пришла эпоха мирового доминирования Raspberry Pi и Beaglebones. Это текущая ситуация в DIY сообществе. В большинстве случаев, быстрее и легче разрабатывать на этих системах, так что зачастую это лучший выбор для большинства проектов.