Sys/bios: операционная система реального времени для микроконтроллеров msp430

Содержание

SYS/BIOS: операционная система реального времени для микроконтроллеров MSP430

Эта статья посвящена операционной системе реального времени (ОСРВ), которая называется 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 во Фрайзинге, Германия. Имеет степень магистра в области электротехники Университета прикладных наук в Лейпциге, Германия. На протяжении восьми лет работы в Texas Instruments участвовал в разработке множества микросхем MSP430 и работал над инструментами для MSP430, такими как бюджетные средства разработки eZ430. Специализируется на программировании микроконтроллеров MSP430 через интерфейс JTAG, программировании флеш-памяти, а также архитектурах и принципах встроенной эмуляции.

MSP430, учимся программировать и отлаживать железо


Сегодня, уважаемый хабрапользователь, я постараюсь заполнить некоторый пробел, образовавшийся в статьях об MSP430, а именно азы и подход к программированию устройств на данном микроконтроллере.
Эта статья прежде всего направлена на новичков, поскольку я буду рассматривать ряд достаточно простых задач, таких как работа с SPI, мигание лампочкой и отладка в proteus.

Введение

В данной статье будет рассмотрено устройство, в основу которого легла отладочная плата eZ430-RF2500. На плате находится микроконтроллер MSP430F2274 и беспроводной модуль CC2500, который, надо заметить, не будет рассмотрен далее.
Моим коллегой, Соколовым С. А., была изготовлена небольшая надстройка для этого отладочного комплекта, она присоединена ко всем выводам. На надстройке расположен акселерометр LIS331DLH, с которым мы и будем взаимодействовать по SPI.

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

Что нам потребуется

Среда разработки

Для начала нужно скачать и установить среду разработки и компилятор. На сегодняшний день существует три варианта — Code Composer Studio, IAR Embedded Workbench for TI MSP430 и mspgcc.
Я буду использовать Workbench KickStart Edition. KickStart бесплатный, он имеет ограничение по количеству кода, но для изучения этого более чем достаточно.

Средство отладки

Если у вас нет под рукой осциллографа или логического анализатора, то часто возникают сложности, связанные с непониманием того, что же на самом деле происходит в вашем устройстве. Понять причины того, почему же устройство отказывается работать часто помогает Proteus.
В нём можно найти очень многие микроконтроллеры MSP430. К сожалению MSP430F2274 в Proteus не оказалось, но имеется аналог — MSP430F2272, его и будем использовать.

Приступим к написанию кода

Создание проекта

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

  • Заменяем стандартный #include «io430.h» на #include «msp430f2274.h» (заголовочный файл для нашего микроконтроллера);
  • В свойствах проекта на вкладке Debugger выбираем Driver: FET Debugger;
  • На вкладке General Options в окне Device выбираем MSP430F2274;
  • Для того чтобы убедиться, что всё сделано правильно нажимаем Ctrl+D (Download and Debug). Как только контроллер прошивка загрузится нажимаем F5 для её выполнения.

В случае если нужно скомпилировать файл для Proteus, на вкладке Debugger в окне Driver выбираем Simulator, а на вкладке Linker Output в окне Format ставим Other и Output format выбираем intel-standart, а в окне Output file меняем расширение на hex.

Работа с портами

void main ( void )
<
WDTCTL = WDTPW + WDTHOLD ;

BIT2 ;
P1REN | = BIT2 ;

P1DIR | = BIT1 + BIT0 ;

BIT0 ;
>
else
<
P1OUT | = BIT0 ;
P1OUT & =

PxDIR отвечает за направление порта 1. Когда конкретный бит данного регистра установлен в 0, соответствующий пин работает на вход. И наоборот, если соответствующий бит установлена в 1, то пин работает на выход. В примере фигурируют 3 пина: P1.2 — кнопка, P1.0 — красный светодиод, P1.1 — зеленый светодиод.

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

PxIN и PxOUT содержат в себе состояние пинов порта. Устанавливая ноль или единицу в регистр PxOUT мы меняем напряжение на лапке микроконтроллера, тем самым включая и выключая светодиод. Читая конкретный бит из регистра PxIN мы получаем логический сигнал, который сейчас подан на пин.

PxSEL выбирает функцию пина. В datasheet на изображении микроконтроллера функции обычно указывают через знак «/».

Например на рисунке P2.7 работает как обычный пин в случае, если P2SEL имеет 0 в соответствующем разряде. По умолчанию, в данном случае, там установлена единица, что означает, что эта лапка предназначена для подключения внешнего часового кварцевого резонатора.

Константы BIT0..BITF содержатся в файле msp430f2274.h и представляют собой 16-ти разрядные слова в заданном разряде которых содержится 1, все остальные разряды содержат 0.

Надо заметить, что файл msp430f2274.h содержит много полезной информации. Там находятся все константы контроллера с комментариями на английском.

В примере используются побитовые операции Си, «|=» установит соответствующий значению справа бит в регистре слева в единицу, а «&=

» напротив установит его в 0.

Работа с SPI

unsigned char spi ( unsigned char data, unsigned char dataEx = 0x00 ) ;

void main ( void )
<
WDTCTL = WDTPW + WDTHOLD ;

P1DIR | = BIT0 + BIT1 ;
P1OUT & =

P3SEL = BIT1 + BIT2 + BIT3 ;
P3DIR | = BIT0 ;
P3OUT | = BIT0 ; // Отключаем CC2500 (устанавливаем 1 на CS)

BIT7 ;
P2DIR | = BIT6 + BIT7 ;
P2OUT | = BIT6 ; // Отключаем датчик температуры (тоже подключен к SPI)
P2OUT | = BIT7 ; // Отключаем акселерометр

// Конфигурируем SPI
UCB0CTL0 | = UCMSB + UCMST + UCSYNC ;
UCB0CTL1 | = UCSSEL_2 ;
UCB0BR0 = 0x02 ;
UCB0BR1 = 0 ;
UCB0CTL1 & =

if ( spi ( 0x8F ) == 0x32 )
<
P1OUT | = BIT1 ; // Красный светодиод
>
P1OUT | = BIT0 ; // Зеленый светодиод
>

unsigned char spi ( unsigned char data, unsigned char dataEx )
<
unsigned char RX ;

BIT7 ; // Включаем акселерометр

while ( ! ( IFG2 & UCB0TXIFG ) ) ; // Ожидаем готовность буфера отправки
UCB0TXBUF = data ;
while ( ! ( IFG2 & UCB0RXIFG ) ) ; // Ожидаем готовность буфера приёма
RX = UCB0RXBUF ;

while ( ! ( IFG2 & UCB0TXIFG ) ) ;
UCB0TXBUF = dataEx ;
while ( ! ( IFG2 & UCB0RXIFG ) ) ;
RX = UCB0RXBUF ;

В примере запрашивается значение регистра по адресу 0x8F, там содержится код, который идентифицирует устройство. Этот код указан в datasheet. Это позволяет убедиться в том, что обмен данными произошел. В случае успеха включаем красный светодиод.
Соответственно все остальные устройства подключенные к SPI необходимо отключить от интерфейса. Для этого CS на них устанавливается в единицу.

Заключение

В следующий раз постараюсь рассказать подробнее про работу с LIS331DLH, добраться до прерываний, поработать со встроенным в программатор мостом USB-UART и рассказать немного про watchdog.

Я надеюсь, что эта статья оказалась полезна тебе, читатель.

Операционная система для микроконтроллера

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

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

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

Есть два основных вида ОС: вытесняющая и кооперативная. В первом случае, переключение между задачами будет «жестким», т.е. если квант времени 1мс, то сначала первая задача будет выполняться ровно 1мс, затем вторая ровно 1мс и т.д. Такие оси называются реального времени (ОСРВ). У кооперативных немного попроще, процесс сам должен сказать что «я выполнился», поэтому к ОСРВ их отнести нельзя.

Впердолить вытесняющую на мелкие AVR не получится по причине небольшого количества ОЗУ. Из имеющихся вариантов кооперативок, мне приглянулась mRTOS, почитать подробности сей системы можно на сайте автора (легко гуглится). Главная причина ее использования — простота, наличие готовой версии под CAVR, для понимания общих принципов самое то.

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

Поэтому стоит задать себе несколько вопросов:
1.Сможете ли вы распорядиться грамотно ресурсами?
2. Не предполагается ли в процессе написания прошивки изобретать такой же велосипед, подобный планировщику?
3. Насколько читаем Ваш код? Способны ли Вы через полгода-год открыть его и сходу разобраться?
4. Один ли Вы пишите или группой?

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

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

Теперь заглянем под капот. Для запуска mRTOS к проекту нужно подключить mrtos.c и заинклюдить mrtos.h. Структура кода немного отличается от привычного

Теперь подробнее. количество задач указывается в mrtos.h дефайном APPTASKS N. Задача объявляется внутри task1()<>, task2()<> и тому подобное, внутри while(1) не нужно ничего писать, вызывать функции тоже никак не нужно, все это сделает за вас планировщик. Как видно задача состоит из бесконечного цикла, это нормально так и должно быть, но внутри задачи нужно обязательно отдавать управление планировщику. Либо функцией WAIT, либо DISPATCH. Если этого не сделать, то задача будет выполняться бесконечно.

Как это работает? Создадим таск мигания светодиодом.

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

Читайте также:  Ночник на микроконтроллере

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

20 мкс при тактовой 16МГц.

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

Далее задачу нужно создать. Для этого достаточно достаточно указать ее имя, приоритет и состояние.

С приоритетами все довольно таки не просто. Если имеются две задачи с разными приоритетом и задача с большим приоритетом постоянно выполняется, то в задачу с низким приоритетом мы никогда не зайдем. Поэтому нужно организовывать работу так, чтобы все задачи получали доступ. Заострять внимание на этом не будем, припасем на следующий раз. Состояние задачи, Active — запущена, остановлена StopTask.

Итак, для желающих просто мигнуть светодиодом:

#include #include “mRTOS.h” vo ) > vo >

В качестве бонуса я попробовал сделать полифоническую (двухголосую) мелодию «Dr.Mario chill». Идея в том, что каждая ножка контроллера постоянно инвертируется в отдельном таске, тем самым генерируя частоту. Меняя задежку можно менять высоту ноты.

Я не заморачивался с идеей, в 1 таске генерится меандр с частотой ноты для соло партии, во втором для баса. Высота каждой ноты берется из массивов. Длительность, переключение и обрывание в таске3.

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

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

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

12 комментариев: Операционная система для микроконтроллера

Супер ! Не то что-бы я никогда не слышал про всякие «ос» для микроконтроллера, но Ваша статья понравилась очень. Ярко, доступно и с интересными примерами. Спасибо, читал с удовольствием.

Очень интересно! А сколько голосов максимально можно воспроизвести с помощью микроконтроллера? И как это отразится на работоспособности? Не будет ли «зависать»?

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

ЧТОТО ПОДОБНОЕ МНЕ ПРИХОДИЛО В ГОЛОВУ НО ВОТ НАПИСАТЬ КОНКРЕТНУЮ БИБЛИОТЕКУ ТАК И НЕ СМОГ. спасибо за материал будем пробовать

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

mRTOS категорически отказывается работать. Пробовал на atmega8 вашу прошивку. Писал свою под Atmega32. В обоих случаях результат нулевой. В чем может быть проблема? Есть какие -то подводные камни при использовании данной ОС?

RTOS ChibiOS/RT – операционная система для микроконтроллеров часть 1.

RTOS ChibiOS/RT – операционная система для микроконтроллеров.

RTOS ChibiOS/RT:

ChibiOs/RT – операционная система реального времени (ОСРВ, RTOS — real-time operating system). Реальное время в операционных системах — способность операционной системы обеспечить требуемый уровень сервиса в определенный промежуток времени. Операционная система, реагирующая на событие за определенный, заданный промежуток времени. ChibiOs/RT предназначена для встраивания приложений, работающих в реальном времени. Эта ОСРВ отличается высокой мобильностью, компактными размерами и, главным образом имеет свою собственную уникальную архитектуру, подходит для быстрого и эффективного переключения контекста.

Основные функции ChibiOs/RT

Функционал применения ChibiOs/RT:

  1. Эффективное и портативное ядро.
  2. Лучшая в классе переключения контекста.
  3. Множество поддерживаемых архитектур и платформ.
  4. Статическая архитектура.
  5. Динамическое расширение, динамические объекты поддерживаются с помощью дополнительного слоя.
  6. Богатый набор примитивов для ОСРВ: потоки (threads), виртуальные таймера (virtual timers), семафоры (semaphores), мьютексы (mutexes), переменные условия/синхронизации (condition variables), сообщения (messages), очереди (queues), флаги событий (event flags) и почтовый ящик (mailboxes).
  7. Поддержка алгоритма наследования для мьютексов.
  8. HAL (Hardware Abstraction Layer — слой аппаратных абстракций),поддержкаабстрактныхплатформ: GPIO, UART/USART, ADC, CAN, EXT, GPT, I2C, ICU, MAC, MMC, PWM, RTC, SDC, SPI, UART, USB, USB-CDC.
  9. Инструментарий для отладки ОСРВ.

Области применения ChibiOs/RT:

  1. Автомобильная электроника.
  2. Робототехника и промышленная автоматика.
  3. Бытовая электроника.
  4. Системы управления электроэнергией.
  5. DIY.

Производительность ChibiOs/RT [Таблица 1].

Таблица 1. Синтетические тесты. Версия ядра 2.4 ChibiOs/RT

Платформа-Частота -КомпиляторПереключение контекстаРазмера ядра, байт
ARM7(ARM)/LPC2148-48-GCC4.6.22.03µS9224
ARM7(THUMB)/LPC2148-48-GCC4.6.22.43µS6052
ARMCM0/LPC1114-48-GCC4.6.22.60µS5500
ARMCM0/LPC1343-72-GCC4.6.21.02µS6172
ARMCM3/STM32F1xx-72-GCC4.6.21.03µS6172
ARMCM3/STM32F4xx-168-GCC4.6.20.40µS6172
MSP430F1611-8-GCC3.2.316.93µS6108
AVR/ATMega128-16-GCC4.3.011.24µSN/A

7500

STM8L152-16-CosmicN/AN/A

6500

STM8L152-16-Raisonance9.03µSN/A

7000

STM8S105-16-CosmicN/AN/A

6500

STM8S105-16-Raisonance9.03µSN/A

7000

PA/SPC563M64-80-GCC4.4.11.11µS11944

Ядро ChibiOs/RT было перенесено на множество различных архитектур и для различных компиляторов, однако текущая стратегия заключается в поддержке меньшего числа конкретных микроконтроллеров, и для текущего набора официально поддерживаемых микроконтроллеров обеспечить полноценный HAL. HAL — слой абстрагирования, реализованный на уроне удобных пользовательский функций, находящийся между физическим уровнем аппаратного обеспечения и программным обеспечением, работающим с периферией микроконтроллера. HAL предназначен для скрытия различий в аппаратном обеспечении от основной части, алгоритма работы программы, таким образом, чтобы большая часть кода, работающая в режиме ядра, не нуждалась в изменении при запуске ОСРВ на различных платформах микроконтроллеров.

ChibiOs/RT предлагает отличную поддержку для нескольких популярных семейств микроконтроллеров. Для семейств, которые не входят в официальный дистрибутив существует сообщество и поддержка от авторов сторонних семейств микроконтроллеров.

Официально поддерживаемые платформы

Следующий список включает в себя архитектуры и платформы поддерживаемые ChibiOs/RT [таблица 2]. Следующие платформы тщательно протестированы и стабильно работаю со своим набором инструментария. Для каждой архитектуры представлен список поддерживаемых семейств микроконтроллеров.

Таблица 2. Официально поддерживаемые платформы ChibiOs/RT

Ядро архитектурыКомпиляторПоддерживаемые платформы
ARM Cortex-M0 (ARMv6-M)GCCLPC11xx, LPC11Uxx, STM32F0xx
ARM Cortex-M0 (ARMv6-M)RVCTLPC11xx, LPC11Uxx, STM32F0xx
ARM Cortex-M3 (ARMv7-M)GCCLPC13xx, STM32F1xx, STM32F2xx, STM32L1xx
ARM Cortex-M3 (ARMv7-M)IARLPC13xx, STM32F1xx, STM32F2xx, STM32L1xx
ARM Cortex-M3 (ARMv7-M)RVCTLPC13xx, STM32F1xx, STM32F2xx, STM32L1xx
ARM Cortex-M4 (ARMv7-ME)GCCSTM32F3xx, STM32F4xx
ARM Cortex-M4 (ARMv7-ME)IARSTM32F3xx, STM32F4xx
ARM Cortex-M4 (ARMv7-ME)RVCTSTM32F3xx, STM32F4xx
ARM7GCCAT91SAM7x, LPC214x
MegaAVRGCCATmega128, AT90CAN128, ATmega328p, ATmega1280
MSP430GCCMSP430F1611
Power Architecture e200zGCC/HighTecSPC56x (all)
STM8CosmicSTM8L, STM8S
STM8RaisonanceSTM8L, STM8S

Концепция ядра ChibiOS/RT

Соглашение по именованию:

Все имена в ChibiOs/RT имеют следующую концепцию записи ch .

Возможны следующие группы: Sys, Sch, Time, VT, Thd, Sem, Mtx, Cond, Evt, Msg, Reg, SequentialStream, IO, IQ, OQ, Dbg, Core, Heap, Pool.

API имена суффиксов.

Суффикс может быть:

None, API (application programming interface, интерфейс прикладного программирования) без суффиксов не может быть вызван из кода пользователя в нормальном режиме, если по-другому не указано.

«I», API, I-класса являются нерегулярными только в состояниях I-Locked или S-Locked.

«S», API S-класса являются нерегулярными только с S-Locked состоянии.

Примеры: chThdCreateStatic(), chSemSignalI(), chIQGetTimeout().

Классы прерываний

В ChibiOS / RT существуют 3 класса логических прерываний:

  1. Регулярные прерывания. Источник маскируемых прерываний, прерывания не могут воздействовать на код ядра и таким образом появляется возможность вызывать API операционной системы изнутри обработчиков прерываний. Обработчики прерываний, принадлежащие к этому классу должны быть описаны с помощью определенных правил.
  2. Быстрые прерывания. Источник маскируемых прерываний с возможностью воздействовать на код ядра, таким образом имеют меньше скрытых состояний работы и менее подвержен дребезгу.
  3. Не маскируемые прерывания. Не маскируемые источники прерываний контролируются операционной системой не полностью и имеют наименьшее число скрытых состояний работы.

Состояние системы

При использовании СhibiOs/RT система может находиться в одном из следующих рабочих логических состояниях:

Init. B этом состоянии все маскируемые источники прерываний запрещены, не представляется возможным использовать различные системные API, за исключением chSysInit(), состояние системы возможно определить после физического сброса.

Normal. Все источники прерываний разрешены, доступны системные API, потоки выполняются.

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

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

Sleep. Архитектурно-зависимый режим пониженного энергопотребления. В этом состоянии находятся потоки в режиме ожидания. После возникновения прерывания восстанавливается нормальное состояние работы планировщика, при котором есть возможность перепланировать работу потоков или продолжить выполнение задач до входа в режим пониженного энергопотребления.

S-Locked. Ядро заблокировано и регулярные источники прерываний запрещены. Быстрые источники прерываний разрешены. API S-класса, и I-класса нерегулярные в этом состоянии.

I-Locked. Ядро заблокировано и регулярные источники прерываний запрещены. API I-класса нерегулярные в этом состоянии.

Обработка регулярных прерываний. Нет доступа к системным API, но можно переключиться на состояние I-Locked и использовать chSysLockFromIsr(), и вызывать различные I-Class API. Обработка прерываний может быть вытеснена на некоторых архитектурах, чтобы перейти к I-Locked состоянию до вызова системных API.

Обслуживание быстрых прерываний. Системные API недоступны.

Обслуживание не маскируемых прерываний. Системные API недоступны.

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

Следующая диаграмма [рисунок 1] показывает возможные переходы между состояниями работы:

Рисунок 1. Состояние работы ChibiOs/RT

Обратите внимание, что SFI, Halted и SNMI состояния не были показаны, потому что они доступны для большинства состояний [рисунок 2].

Рисунок 2. SFI, Halted и SNMI

Планировщик

Планировщик — часть операционной системы, которая отвечает за параллельное выполнения задач, потоков, процессов. Планировщик выделяет потокам процессорное время, память, стек и прочие ресурсы. Планировщик может принудительно забирать управление у потока, либо ожидать пока поток отдаст управление планировщику [рисунок 3].

Рисунок 3. Многопоточность ChibiOs/RT

Выбор работы потока зависит от приоритета задачи. Приоритет задачи – важность задачи для планировщика, чем выше приоритет, тем быстрее планировщик ее начнет выполнять и тем меньше система потратит процессорного времени на выполнении задачи. ChibiOs/RT имеет следующие стандартные приоритеты: IDLEPRIO, LOWPRIO, NORMALPRIO, HIGHPRIO и ABSPRO.

В следующей статье мы разберем, как создавать проект для Keil, напишем программу для мигания светодиодов для STM32F429i – DISCO и разберем реализацию многозадачности в ChibiOs/RT.

Sys/bios: операционная система реального времени для микроконтроллеров msp430

Источники питания электронной аппаратуры, импульсные и линейные регуляторы. Топологии AC-DC, DC-DC преобразователей (Forward, Flyback, Buck, Boost, Push-Pull, SEPIC, Cuk, Full-Bridge, Half-Bridge). Драйвера ключевых элементов, динамика, алгоритмы управления, защита. Синхронное выпрямление, коррекция коэффициента мощности (PFC)

  • 3 часа назад
  • Тема:240V на UC3843′ >Повышающий преобразователь 24V->240V на UC3843
  • От:manowar
  • Обратная Связь, Стабилизация, Регулирование, Компенсация

    Организация обратных связей в цепях регулирования, выбор топологии, обеспечение стабильности, схемотехника, расчёт

    • 16 мая
    • Тема:Источник тока Управляемый напряжением
    • От:Шнекоход
  • Первичные и Вторичные Химические Источники Питания

    Li-ion, Li-pol, литиевые, Ni-MH, Ni-Cd, свинцово-кислотные аккумуляторы. Солевые, щелочные (алкалиновые), литиевые первичные элементы. Применение, зарядные устройства, методы и алгоритмы заряда, условия эксплуатации. Системы бесперебойного и резервного питания

    • 12 мая
    • Тема:Контроллер Li-Ion батареи BQ30Z55 не работает
    • От:rfengin
  • Высоковольтные Устройства – High-Voltage

    Высоковольтные выпрямители, умножители напряжения, делители напряжения, высоковольтная развязка, изоляция, электрическая прочность. Высоковольтная наносекундная импульсная техника

    • В воскресенье в 11:22
    • Тема:Какую топологию ВВ источника выбрать для двунапр…
    • От:iiv
  • Электрические машины, Электропривод и Управление

    Электропривод постоянного тока, асинхронный электропривод, шаговый электропривод, сервопривод. Синхронные, асинхронные, вентильные электродвигатели, генераторы

    • 28 мая
    • Тема:Помогите подобрать качественный драйвер ШД
    • От:dinam
  • Индукционный Нагрев – Induction Heating

    Технологии, теория и практика индукционного нагрева

    • 16 мая
    • Тема:Индукционный нагреватель на 100 кВт своими рукам…
    • От:dericc
  • Системы Охлаждения, Тепловой Расчет – Cooling Systems

    Охлаждение компонентов, систем, корпусов, расчёт параметров охладителей

    • 20 мая
    • Тема:Изолирующая прокладка между силовым компонентом …
    • От:vladec
  • Моделирование и Анализ Силовых Устройств – Power Supply Simulation

    Моделирование силовых устройств в популярных САПР, самостоятельных симуляторах и специализированных программах. Анализ устойчивости источников питания, непрерывные модели устройств, модели компонентов

    • 9 апреля
    • Тема:Micro-CAP 12. Цепи с одинаковым именем почему-то…
    • От:SAVC
  • Компоненты Силовой Электроники – Parts for Power Supply Design

    Силовые полупроводниковые приборы (MOSFET, BJT, IGBT, SCR, GTO, диоды). Силовые трансформаторы, дроссели, фильтры (проектирование, экранирование, изготовление), конденсаторы, разъемы, электромеханические изделия, датчики, микросхемы для ИП. Электротехнические и изоляционные материалы.

    • 24 мая
    • Тема:Программы расчета трансформаторов и дросселей
    • От:kochkuroff
  • Интерфейсы

      Последнее сообщение

    Форумы по интерфейсам

    все интерфейсы здесь

    • 5 часов назад
    • Тема:Можно ли 1G Ethernet по бекплейну
    • От:sorok-odin
  • Поставщики компонентов для электроники

      Последнее сообщение

    Поставщики всего остального

    от транзисторов до проводов

    • В понедельник в 04:18
    • Тема:Изготовление лицевой панели
    • От:destroit
  • Компоненты

    Закачка тех. документации, обмен опытом, прочие вопросы.

    • 2 июня
    • Тема:Что за диод, есть фото.
    • От:Georgy
  • Майнеры криптовалют и их разработка, BitCoin, LightCoin, Dash, Zcash, Эфир

      Последнее сообщение

    Обсуждение Майнеров, их поставки и производства

    наблюдается очень большой спрос на данные устройства.

    • 21 февраля
    • Тема:Зачем нужны дорогие майнеры
    • От:Doka
  • Дополнительные разделы – Additional sections

      Последнее сообщение

    Встречи и поздравления

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

    • 1 июня
    • Тема:С Днём Великой Победы в Великой Войне.
    • От:evgdmi
  • Ищу работу

    ищу работу, выполню заказ, нужны клиенты – все это сюда

    • 17 часов назад
    • Тема:МОНТАЖ ПЕЧАТНЫХ ПЛАТ
    • От:radiomont
  • Предлагаю работу

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

    • 12 часов назад
    • Тема:ТЗ на разработку электронного устройства.
    • От:ergovit
  • Kуплю

    микросхему; устройство; то, что предложишь ты 🙂

    • 12 часов назад
    • Тема:SAW фильтр на 737 МГц
    • От:3apw
  • Продам

    есть что продать за деньги, пиво, даром ?
    Реклама товаров и сайтов также здесь.

    • 20 часов назад
    • Тема:Плата многоканального АЦП E14-440 (USB) и промыш…
    • От:Linker
  • Объявления пользователей

    Тренинги, семинары, анонсы и прочие события

    • 13 часов назад
    • Тема:CSP-3000 — мощные высоковольтные источники питан…
    • От:КОМПЭЛ
  • Общение заказчиков и потребителей электронных разработок

    Обсуждение проектов, исполнителей и конкурсов

    Встроенные операционные системы

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

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

    Ключевые особенности ОСРВ

    Типичные аппаратные требования ОСРВ: объём ОЗУ от одного килобайта и RISC-процессор, работающий на частоте от единиц мегагерц. В отличие от полноценных ОС, ОСРВ представляет собой исходный код или библиотеку, которая статически линкуется вместе с разрабатываемым ПО и образует монолитный образ прошивки. Такой подход существенно упрощает механизм изоляции пользовательского и системного кода (в ряде ОСРВ изоляция и вовсе отсутствует), а также оптимизирует размер прошивки, исключая из неё неиспользуемый код на этапе компиляции.

    Второе важное свойство ОСРВ — это детерминизм, обусловленный вычислительной сложностью О(1) любых системных вызовов, то есть отсутствие зависимости времени, потраченного на обработку системного вызова от внутреннего состояния системы. Это свойство частично вытекает из способности ОСРВ работать на системах с минимумом ОЗУ и невысокой скоростью CPU.

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

    Более сложные ОС (например, такие как Linux или Windows) не обладают этим качеством, поэтому даже при наличии ОС задачи реального времени зачастую выполняются в ОСРВ на выделенном контроллере или процессорном ядре.

    Помимо низкого уровня системных вызовов, обеспечивающих многозадачность и работу с основными аппаратными ресурсами (таймер, ОЗУ), большинство ОСРВ предоставляют также и более высокоуровневые сервисы, которые позволяют реализовывать графический интерфейс пользователя, работать с массой периферийных устройств, организовывать файловые системы, реализовывать различные сетевые протоколы (TCP/IP, PPPoE, FTP и т.п.) и многое другое.

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

    FreeRTOS

    Портируемая свободная (GPL) ОС реального времени для встраиваемых систем. Является одной из самых популярных встраиваемых ОС (занимает 13% рынка, по версии издания EE Times).

    FreeRTOS поддерживает 33 аппаратных архитектуры и 18 тулчейнов. Инженеры Promwad также добавили в эту ОС поддержку архитектуры Power e200z0h, которая используется в микроконтроллерах семейства SPC56 фирмы STMicroelectronics, разработанных для применения в ответственных узлах автомобилей.

    FreeRTOS предоставляет разработчику базовый набор сервисов, типичный для любой ОСРВ:

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

    Сообщество разработчиков FreeRTOS также предлагает богатый набор расширений, поставляемых как под свободными, так и под коммерческими лицензиями:

    • TCP/IP-стек
    • графический трейсер
    • CLI
    • SSL/TLS-функции
    • HTTP-сервер

    Для приложений, требующих сертификат о повышенной надёжности (IEC 61508, EN62304, FDA 510(k)), компания WITTENSTEIN поставляет ОСРВ SafeRTOS, которая представляет собой переработанную версию FreeRTOS с наследованием её API.

    ThreadX

    Одна из самых популярных коммерческих ОСРВ, поставляется компанией Express Logic под лицензией Royalty Free. Надёжность и предсказуемость ThreadX подтверждена 1,5 миллиардом устройств, которые работают под её управлением, а также наличием множества сертификатов безопасности.

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

    • Размер прошивки начинается от 2 КБ, требуя до 500 байт ОЗУ
    • Время загрузки — 300 циклов CPU, время переключения контекста — менее 100 циклов

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

    Express Logic поставляет богатый набор средств разработки, которые существенно облегчают процесс отладки. Имеется встроенный трейсер и графический анализатор, работающий на стороне хоста. Для среды Eclipse существует плагин, позволяющий наблюдать в наглядном виде за текущим положением системы: номер активной задачи, заполненность стека, обратный стек вызова функций, процент использования системных ресурсов и т.п.

    RTEMS

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

    Так, RTEMS содержит полноценный стек BSD TCP/IP, графический интерфейс на основе библиотек picoTk, NanoX, OpenGUI, MicroWindows, FLTK. Портированы многие библиотеки, популярные в других POSIX-совместимых ОС: zlib, tcl, ncurses, libavl.

    Инженеры Promwad выбрали ОСРВ RTEMS для одного проекта, включающего разработку индустриального компьютера на базе SoC NXP QorIQ p1020, предназначенного для контроля оборудования электроподстанций. Для этого проекта была реализована следующая схема работы операционных систем компьютера:

    • Одно ядро p1020 исполняет RTEMS, на которой работают задачи реального времени
    • Другое ядро исполняет ОС Linux, которая реализует проприетарные коммуникационные протоколы и высокоуровневую бизнес-логику
    • Взаимодействие между двумя ОС осуществляется посредством стандартного интерфейса OpenMCAPI, для которого на стороне RTEMS был реализован соответствующий адаптер

    Linux

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

    Типичные системные требования ОС Linux:

    • RISC CPU >100 МГц
    • >16 Мбайт FLASH-памяти
    • >8 Мбайт ОЗУ

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

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

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

    SYS/BIOS

    SYS/BIOS является проприетарной ОС, которая, тем не менее, распространяется в исходных кодах без продажи лицензии.

    SYS/BIOS — это разработка Texas Instruments, которая изначально предназначалась для работы на DSP-процессорах (она называлась DSP/BIOS, а потом была переименована в SYS/BIOS, чтобы подчеркнуть более общую направленность этой ОСРВ).

    Последние версии SYS/BIOS способны работать не только на DSP, но также на широком спектре других процессоров и контроллеров компании TI: ARM Cortex-M3, MSP430, ARM9 и др.

    SYS/BIOS является частью Linux SDK, который поставляется для видеопроцессоров Davinci. Связь между Linux, работающем на ARM-ядре и SYS/BIOS, работающем на DSP-ядре, осуществляется посредством стандартного программного интерфейса DSP/BIOS Link.

    PikeOS

    PikeOS была разработана компанией SYSGO AG специально для критически важных проектов, где тредуется максимальная надёжность и предсказуемость встроенного ПО.

    Для достижения максимального уровня изоляции структурно независимых частей ПО в PikeOS применена концепция логического разбиения ресурсов (resourse partitioning), основанная на применении гипервизора. Гипервизор PikeOS представляет собой небольшую программную прослойку, которая виртуализирует доступную периферию и ресурсы процессора. Каждой партиции статически назначаются доступные аппаратные ресурсы. Таким образом, для программы, работающей в одной партиции, нет никакой возможности повлиять на работу программы в другой партиции.

    PikeOS находит применение в авионике, машиностроении и автомобильной электронике.

  • Рейтинг
    ( Пока оценок нет )
    Загрузка ...
    Adblock
    detector