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

FreeRTOS – операционная система для микроконтроллеров

Published: Ср. 26 Апрель 2017By Oleg Mazko

In Embedded.

tags: msp430 RTOS

FreeRTOS — многозадачная, мультиплатформенная операционная система жесткого реального времени (RTOS) для встраиваемых систем. Написана на языке Си с ассемблерными вставками для конкретной аппаратной платформы.

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

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

Соответственно кооперативная многозадачность по своей природе является системой мягкого реального времени т.к.

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

MSP430.js | исходники

При создании приложения на FreeRTOS рекомендуется брать за основу демонстрационный проект из официальных примеров. В нашем случае микроконтроллер MSP430F1611, организация файлов проекта makefile и компилятор (msp430-gcc 6.2.1.16) самый свежий на текущий момент от производителя.

Все настройки конфигурации, касающиеся FreeRTOS, принято помещать в один отдельный заголовочный файл FreeRTOSConfig.h. Большинство настроек в этом файле являются опциональными т.к.

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

FreeRTOSConfig.h

#ifndef FREERTOS_CONFIG_H
#define FREERTOS_CONFIG_H #include /*———————————————————–
* Application specific definitions.
*
* These definitions should be adjusted for your particular hardware and
* application requirements.
*
* THESE PARAMETERS ARE DESCRIBED WITHIN THE 'CONFIGURATION' SECTION OF THE
* FreeRTOS API DOCUMENTATION AVAILABLE ON THE FreeRTOS.org WEB SITE.
*
* See http://www.freertos.org/a00110.html.
*———————————————————-*/ #define configUSE_PREEMPTION 1
#define configUSE_IDLE_HOOK 0
#define configUSE_TICK_HOOK 0
#define configCPU_CLOCK_HZ ( ( unsigned long ) 130000 )
#define configTICK_RATE_HZ ( ( TickType_t ) 10 )
#define configMAX_PRIORITIES 2
#define configMINIMAL_STACK_SIZE ( ( unsigned short ) 50 )
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 8 * 1024 ) )
#define configUSE_16_BIT_TICKS 1 #endif /* FREERTOS_CONFIG_H */

Итак пробежимся по порядку по всем указанным настройкам:

configUSE_PREEMPTION задаёт режим многозадачности — кооперативная (0) или вытесняющая (1)
configUSE_IDLE_HOOK, configUSE_TICK_HOOK — хуки сейчас не используем (0), но будем в следующем материале
configCPU_CLOCK_HZ — в подавляющем большинстве задач необходимо отмерять интервалы времени, данная величина — тактовая частоты микроконтроллера (похоже порт MSP430 её нигде не использует, сейчас там при расчёте временных квантов используется portACLK_FREQUENCY_HZ из расчёта LFXT1CLK = 32768 Hz)
configTICK_RATE_HZ — переключение между задачами осуществляется через равные кванты времени работы планировщика и время реакции FreeRTOS на внешние события в режиме вытесняющей многозадачности не превышает одного кванта. По идее чем меньше квант тем лучше, однако за увеличением частоты переключений следует то, что ядро системы использует больше процессорного времени и тогда соответственно меньше процессорного время остаётся под задачи. Чем выше тактовая частота, тем большую частоту переключения можно задавать
configMAX_PRIORITIES — каждой задаче назначается приоритет от 0 до (configMAX_PRIORITIES – 1). Наиболее низкий приоритет у задачи «бездействие», значение которого по умолчанию определено как 0. Уменьшение configMAX_PRIORITIES позволяет уменьшить объем ОЗУ, потребляемый ядром
configMINIMAL_STACK_SIZE, configTOTAL_HEAP_SIZE — пока что пусть это будут некие магические числа, определяющие достаточный объём памяти для нормального функционирования задач. Что будет если их поменять или задать неправильно посмотрим в следующем материале
configUSE_16_BIT_TICKS — разрядность счётчика квантов времени, прошедших с начала работы системы 16 бит (1) или 32 бит (0)

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

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

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

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

task_r_leds.c

Источник: http://proiot.ru/blog/posts/2017/04/26/freertos-operatsionnaia-sistema-dlia-mikrokontrollerov/

Операционная система для микроконтроллеров с поддержкой операций реального времени и прав пользователей

УДК 537.622:519.245

Устюгов В. А., Епихин В. С. Операционная система для микроконтроллеров с поддержкой операций реального времени и прав пользователей

Операционная система для микроконтроллеров с поддержкой операций реального времени и прав пользователей	The operating system for microcontrollers with support for real-time operations and user rights
В. А. Устюгов, В. С. Епихин	V. A. Ustyugov, V. S. Epikhin
Сыктывкарский государственный университет имени Питирима Сорокина, г. Сыктывкар	Syktyvkar State University named after Pitirim Sorokin, Syktyvkar
В статье представлен обзор структуры и используемых концепций новой операционной системы для бюджетных микроконтроллеров. Особенностью рассматриваемого программного продукта является учёт в планировщике задач и модулях контроля прав пользователей. Это позволяет удобно разрабатывать безопасные управляющие программы.	The article provides an overview of the structure and concepts used for the new operating system for low cost microcontrollers. A general feature of the reporting software is a user rights accounting in task scheduler and control modules. This allows you to conveniently develop secure firmware programs.
Ключевые слова: операционная система, микроконтроллеры, реальное время.	Keywords: operating system, microcontrollers, real time.

Введение

ОС для микроконтроллеров принципиально отличается от традиционных операционных систем в силу существенного различия архитектуры процессорного модуля, системы ввода-вывода, жёсткой ограниченности в ресурсах [1].

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

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

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

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

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

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

ОС имеет три слоя (уровня):

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

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

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

С целью повышения переносимости системы реализован программный таймер с указанными возможностями.

Платформо-зависимый код вынесен в отдельный компактный модуль нижнего уровня системы, который может быть легко изменён при переносе ОС на иное семейство микроконтроллеров.

Процессы

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

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

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

Учёт существующих в управляющей программе процессов ОС осуществляет путём ведения таблицы процессов.

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

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

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

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

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

В силу ограниченности объёма оперативной памяти количество общих слов в оперативной памяти не может превышать 16.

Для работы с очередью реализованы функции помещения в очередь и извлечения из очереди (по аналогии с функциями работы со стеком push и pop). Количество элементов в очереди не может превышать 16.

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

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

Когда процесс переходит в активное состояние, счётчик очков процесса обнуляется.

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

Для обеспечения контроля прав пользователя реализованы следующие модули:

модуль авторизации пользователя. Для авторизации пользователю требуется тем или иным способом передать идентификатор и ключ по протоколу UART, после чего производится проверка соответствия введённых данных, и начинает выполняться основная часть программы с учётом пользовательских привилегий;
модуль хранения и проверки идентификаторов и ключей пользователей. Идентификаторы и ключи могут храниться как на энергонезависимой памяти EEPROM, так и на flash-памяти контроллера;
для учёта пользователей ОС использует таблицу пользователей, размещённую в памяти программ (flash). В таблице указаны идентификатор пользователя, ключ доступа, приоритет, а также метод, с помощью которого производится авторизация (передача ключа с помощью клавиатуры, интерфейса UART или иного средства). После проведения процедуры авторизации использованные выводы микроконтроллера могут быть переведены в режим общего пользования. Процедура авторизации может быть проведена многократно как в начале работы управляющей программы, так в ходе её работы.

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

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

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

Выводы

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

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

Статья поступила в редакцию: 28.04.2016

Список литературы

1. Иртегов Д. В. Введение в операционные системы. 2-е изд. М. : БХВ-Петербург, 2012.

List of references

1. Irtegov, D. V. Introduction to operating systems, 2-e izd., Moscow: BKHV-Peterburg, 2012.

VN:F [1.9.17_1161]

Rating: 0.0/10 (0 votes cast)

VN:F [1.9.17_1161]

Стиль изложения

Информативность

Сложность вопроса

Научная новизна

Коммерциализуемость

Rating: 0.0/5 (0 votes cast)

Источник: http://itue.ru/?p=891

TI ARM-Event 2013, Москва, 22 октября (Отчет)

Всем привет!

Во вторник, в Москве прошла ежегодная ARM конференция, организованная компанией №1 Texas Instruments их официальными дистрибьюторами в России, фирмой MT-system. Под катом небольшой отчет с места событий с кучей полезных ссылок.

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

Цифровая секция
Аналоговая секция
Практическая Секция.

Можно сказать, что я бы на каждой из них по немногу:

Цифровая часть:

На первой части цифровой секции представители из TI рассказали какие они молодцы (впрочем, кто с этим спорит) и представили сообществу семейство микроконтроллеров TIVA. Что такое микроконтроллеры семейства TIVA? Это ARM ядро Cortex-M4F с низким потреблением(сказывается MSP430) и весьма богатой периферией.

Основной принцип линейки TIVA — сбалансированный продукт, без всяких 81632 выходов, «В этом процессоре мы оставим вам полтора UART-а, а вот тут отберем один канал ADC», и проч. Только полный функционал, только хардкор. Естественно, есть определенные отличия по количеству памяти и т.д. и т.п., но общий принцип остается.

Среди линейки TIVA выделяются следующие контроллеры:

TIVA-C — Connectivity-series — линейка микроконтроллеров с максимальным числом коммуникационных интерфейсов. Получите 8 UART, 6 I2C, 4 SPI, 2 CAN и USB интерфейс вместе с 256 Кбайт Flash и 32 кбайт ОЗУ в уже выпускаемом микроконтроллере TM4C123. Я уже заказал себе launchpad-ы на его основе.

Другим из контролеров, доступным пока в качестве образцов уже доступным для заказа является TM4C129 — контроллер с Ethernet PHY!

TIVA-R Real Time (sample date Q2,14) — Уникальные микроконтроллеры, имеющие внутри себя СОПРОЦЕССОР (О_О), на который можно возложить абсолютно любые задачи, в частности, специалисты TI предлагают использовать его в качестве контроллера обработки контура регулирования объекта — пока основной контроллер занимается какими-то своими делами или даже спит — на сопроцессоры вовсю трудятся регуляторы. Ядро сопроцессора послабее, у меня к сожалению не записано, какие именно находится в них. Программирование такого процессора в принципе ничем не отличается, разве что необходимо написать две программы — сначала для большого процессора, потом для сопроцессора. Среда программирования позволяет все это объединить и залить так как нужно.

TIVA-L — Low Power (sample date Q2,14) — микроконтроллеры Cortex-M4F, с энергопотреблением Cortex-M0, что открывает огромные возможности по их применению в микропотребляющих устройствах.

TIVA-S — Special (sample date Q2,14) — специализированные микроконтроллеры для различных медицинских, аэрокосмических и автомобильных задач. НЕ для массового рынка. Насколько я понял, TI создало некоторый собственный конструктор, на котором будет быстренько собирать нужные промышленности микроконтроллеры.

А еще, в процессорах TIVA есть вшитый ROM! Что это? Это область памяти, в которой расположены ВСЕ функции доступа к периферии! Фактически, каждый микроконтроллер поставляется со своим собственным API, что предоставляет возможность не таскать в проекте кучу системных библиотек и что позволит сэкономить пространство во Flash памяти. Естественно, никто не заставляет использовать Только вшитые функции — можно использовать и обычные. Ну мало ли. Вернее если вы хотите использовать вшитые функции, то используйте обычные с префиксом ROM_ и все будет как надо.

Аналоговая часть.

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

Тут вам и ZegBee и Wi-Fi и прочие радости жизни! Упомяну лишь микроконтроллер CC3000 со стеком внутри, который позволяет подключать шибко медленный микроконтроллер и полноценно работать в Wi-Fi сети — CC3000 самостоятельно подключится к сети с указанными настройками.

Практическая часть.

Первую половину дня, на практической части народ осваивал Cortex-A8 процессор на материнской плате MTAX-SOM-AM335x от такого вида:Они ставили туда Linux. Я до туда в итоге не попал, ну да ладно. В конце участникам «Подарили» процессорные модули (участие в первой части стоило 3000 рублей 🙂 ) с весьма жирными характеристиками — 1ГГц, 4 Гбайт Flash, 4Гбайт ОЗУ.

Вторая часть была посвящена ОСРВ TI-RTOS. На второй части был я. У нас был от такой вот отладочный набор:С двух-ядерным микроконтроллером Cortex-M3 + C2000 F28M36 семейства Concerto.

Кроме того, у нас был дистрибутив Code Composer Studio v5 и порядка 3 часов времени, за которые нам рассказали насколько хороша TI-RTOS, что она поддерживает все микроконтроллеры от TI (наглая ложь — например под MSP430 обещают доделать в этом квартале 🙂 ), что существует давным давно, что включает в себя отлаженные и проверенные временем средства, например SYS/BIOS, который уж точно поддерживает все микроконтроллеры от TI (опять наглая ложь — MSP430 launchpad не поддерживается :)) и прочие радости жизни. У Code Composer studio есть просто замечательная утилита графического конфигурирования TI-RTOS:Этот конфигуратор позволил практически в пару строк кода например создать web-сервер. В общем, ребята мне показали, что они действительно №1 в области микроконтроллеров и самое главное — все их программные продукты тоже. В итоге, после двух месяцев попыток настроить Eclipse я купил лицензию на Code Composer и начинаю переезжать на контролеры TIVA. В целом, мероприятие мне очень понравилось, узнал много интересного, а главное — понял для себя, что контроллеры от TI вместе с ПО от TI дадут мне максимальные возможности. Тем более, что текущий проект я начал с выбора CC430F6137 — RF микроконтроллеров MSP430.

Мне запомнилась одна из фраз от сотрудника TI: «Коллеги, если у вас возникли вопросы, вы нам на почту не пишите. Нет, конечно вы можете нам написать, но мы вам скорее всего не ответим. Наиболее вероятно, что ваш ответ уже есть на e2e. Если нет, то лучше напишите там. Там мы вам ответим. Если уж совсем сроки жмут — попробуйте написать нам на почту, попробуем разобраться». ИМХО, Такой подход идеологически верен. Сначала гугл, потом живой спец 🙂

В заключение, определенное количество ссылок:
e2e Forum — TI-RTOS currently uses the SYS/BIOS e2e Forum:

– External: e2e.ti.com/support/embedded/bios/default.aspx
– Internal: e2e.ti.com/support/embedded/int-embedded_software/intbios/default.aspx
• Wiki: processors.wiki.ti.com/index.php/Main_Page – Select ‘TI-RTOS’ category • Download page:

– softwaredl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/index.html

Web Page:

– www.ti.com/tool/ti-rtos

– Includes link for product downloads for customers – Includes link for product bulletin • Sales Presentations – Available on ESP and from:

• wiki.sanb.design.ti.com/twiki/bin/view/MCUSDK/WebHome

• Youtube Overview Videos:

– Overview: www.youtube.com/watch?v=Vrs-o8HsMs8

– Components: www.youtube.com/watch?v=nkA8ss5FAqE
– Tools: www.youtube.com/watch?v=_F2bVVqaeFkТолько зарегистрированные и авторизованные пользователи могут оставлять комментарии.

Источник: http://tqfp.org/events/ti-arm-event-2013-moskva-22-oktyabrya-otchet.html

Реализация операционной системы для микроконтроллеров AVR ATmega32

УДК 681.3.068

РЕАЛИЗАЦИЯ ОПЕРАЦИОННОЙ СИСТЕМЫ ДЛЯ МИКРОКОНТРОЛЛЕРОВ AVR ATmega32

М.Г. Логутенко, А.Н. Осокин, С.А. Щербаков*

Томский политехнический университет *ООО НИИ «ЭлеСи», г. Томск E-mail: logutenko_maria@mail.ru

Реализована операционная система для микроконтроллеров AVR ATmega на языке Си.

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

Произведено тестирование разработанного программного обеспечения. Проведен сравнительный анализ разработанной операционной системы и свободно распространяемой операционной системой реального времени FreeRTOS.

Ключевые слова:

Микроконтроллер, процесс, диспетчер, критическая секция, операционная система реального времени (ОСРВ).

Key words:

Microcontroller, process, scheduler, critical section, real time operating system (RTOS).

Микроконтроллеры AVR фирмы «Atmel» представляют собой мощный инструмент, прекрасную основу для создания современных

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

Популярность микроконтроллеров AVR постоянно увеличивается. Не последнюю роль в этом играет соотношение показателей «цена/быстродействие/энергопотребление», являющееся одним из лучших на рынке 8-ми разрядных микроконтроллеров.

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

Все это позволяет говорить о микроконтроллерах AVR как о новом индустриальном стандарте среди 8-ми разрядных микроконтроллеров общего применения.

В рамках единой базовой архитектуры микроконтроллеры AVR подразделяются на три семейства: Classic AVR, Mega AVR, Tiny AVR.

Микроконтроллеры семейства Mega имеют наиболее развитую периферию и наибольшие среди всех микроконтроллеров AVR объемы памяти программ и данных. Они предназначены для использования в мобильных телефонах, контроллерах различного периферийного оборудования (принтеры, сканеры, современные дисковые накопители, приводы CD-ROM/DVD-ROM и т. п.), сложной офисной технике и т. д. [1-3].

В компании «ЭлеСи» в 2010 г. были разработаны модули ввода-вывода серии TM с использованием микроконтроллеров AVR ATmega. Модули серии ТМ представляют собой универсальные модули ввода-

Логутенко Мария Геннадьевна,

магистрант кафедры

вычислительной техники

Института кибернетики ТПУ. E-mail: logutenko_maria@mail. ru Область научных интересов: применение микропроцессоров, цифровых сигнальных

процессоров.

Осокин Александр Николаевич, канд. техн. наук, доцент кафедры вычислительной

техники Института киберне-тики ТПУ.

E-mail: osokin@vt.tpu.ru Область научных интересов: помехоустойчивое кодирова-ние, сжатие информации, применение микропроцессоров, цифровых сигнальных процессоров. Щербаков Сергей Андреевич, руководитель сектора ООО НИИ «ЭлеСи», г. Томск.

E-mail: sergey.sherbakov@elesy.ru

Область научных интересов: применение встроенного

программирования в области автоматизированного управления.

вывода. Основная область их применения – системы автоматического и автоматизированного управления технологическими процессами [4].

При решении любой задачи с использованием микроконтроллера (8-ми , 16-ти или 32-х разрядных) пользователь часто сталкивается с набором следующих трудностей:

• невысокая производительность процессора и ограниченная емкость ОЗУ ;

• большое количество обработчиков прерывания (ISR – Interrupt Service Routine) как источников событий, которые необходимо успеть обслужить;

• отсутствие компактной операционной системы (ОС), которая помогает в решении поставленных задачи и содержит малые накладные расходы на выполнения функций ОС;

• отсутствие соглашений по эффективной обработке критических секций и критических участков, обеспечивающих обработку их без закрытия прерываний;

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

Решить данные проблемы позволяет системное программное обеспечение – операционная система.

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

Исходя из того, что основная функция ОС – поддержка параллельного асинхронного исполнения разных процессов и взаимодействия между ними, встает вопрос о планировании процессов, т. е.

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

По способу организации работы планировщики бывают:

• с приоритетным вытеснением (preemptive);

• с вытеснением без приоритетов (round-robin или «карусельного» типа);

• без вытеснения (cooperative).

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

Очевидно, что способность ОС реагировать на события определяется, в первую очередь, типом планировщика. Из упомянутых выше наиболее «быстрыми» в смысле реакции на события являются ОС с приоритетными вытесняющими планировщиками – у них время реакции (при прочих равных условиях) минимально. Остальные типы планировщиков уступают им по скорости реакции.

Однако вытесняющие ОС имеют и недостаток – они значительно более требовательны к ОЗУ, чем невытесняющие.

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

Данная реализация ядра ОС сочетает возможности и кооперативных ОС, и ОС с вытесняющим планированием. В 2007-2008 гг. в компании «ЭлеСи» данная концепция была реализована на ассемблере для микроконтроллеров Renesas SH2, SH2A.

Следующим этапом развития ядра ОС стала его реализация на Си для микроконтроллера AVR ATmega32.

Ядро ОС построено на ряде соглашений. Ядро не контролирует процессорное время исполнения конкретного прерывания, требует только соблюдения соглашения их написания. Та часть прерывания, которая не уместилась во временные рамки, должна быть исполнена на fork-процессе – приоритетном системном процессе (ПСП).

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

Fork-процесс будет поставлен в очередь ядра, если на данный момент исполняется

системная часть ядра (другой fork-процесс, директива). Выполнения фонового процессов приостанавливается и будет продолжено по завершению выполнения всей очереди fork-процессов. Для постановки в очередь пользователь должен предоставить блок PDB (Process Description Block).

Приоритет

исполнения

Прерывания

FORK-

процессы,

директивы

ПП

процессы

Фоновые

задачи

Время

Рис. 1. Временная диаграмма выполнения процессов

Рассмотрим работу обработчика прерывания.

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

Регистр статуса SREG записывается в стек (при этом используется рабочий регистр R16, который перед этим сохраняется в стеке). Ответственность за сохранение контекста при выполнении обработчика прерывания возлагается на разработчика.

Если в обработчике прерывания выполняется вызов функции постановки fork-процесса в очередь, то на выходе из обработчика должна осуществляться проверка, не была ли прервана директива. Если директива была прервана, то прерывание должно завершиться макросом EXIT.

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

Директивный уровень используется для разграничения доступа к критическим участкам процессов. Для упрощения работы с директивами могут быть использованы макросы BEGIN_DIR и END_DIR.

Кроме того, пользователю предоставляется возможность создания приоритетных пользовательских процессов (ППП). Блок PDB для ППП не отличается от PDB для fork-процесса. Постановка в очередь ППП осуществляется с помощью функции call_pp, входными параметрами которой является указатель на блок PDB ППП и приоритет процесса. Уровень приоритета ППП ниже, чем fork-процессов.

Для создания пользовательской фоновой задачи пользователь должен предоставить блок TDB (Task Description Block). Для постановки пользовательской задачи в очередь на исполнение пользователь должен вызвать функцию task_create.

После того, как все необходимые фоновые задачи созданы, для их запуска вызывается функция start_tasks().

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

На рис. 2 приведено разбиение процессов по уровню приоритета.

Уровень

приоритета

Приоритетные пользовательские процессы (ППП)

Рис. 2. Уровни приоритета

Функция управления процессами возложена на диспетчер. Диспетчер имеет 3 основных блока: обработка fork-очереди, обработка очереди ППП и изменение фоновой задачи. В блоках обработки fork-очереди и очереди ППП осуществляется проверка на наличие процессов в соответствующей очереди.

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

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

Обобщая структуру ядра, можно выделить следующие выполняемые функции:

• инициализация ядра void init_kernel() (должна быть вызвана на этапе инициализации пользовательской задачи, до первого выполнения ISR). Функция выполняет инициализацию очереди fork-процессов, очереди ППП, очереди фоновых задач, обнуляет переменные ядра;

• диспетчеризация процессов ______task void dispatcher() выполняет проверку очереди fork-

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

В противном случае, производится проверка, не истекло ли время выполнения текущей фоновой задачи. Если истекло, то контекст текущей задачи сохраняется в ее TDB, а из очереди фоновых задач выбирается новая задача.

Переход в программу диспетчера процессов осуществляется либо по завершению fork-процесса, либо по завершению выполнения директивы или ISR;

• формирование очереди fork-процессов call_fork (PDB *). Вызов данной функции производится в тех случаях, когда исполнение ISR не укладывается в определенные временные рамки или когда необходимо произвести разграничение к критическим ресурсам на уровнях секций процессов;

• формирование очереди ППП call_pp (PDB *p_newPDB, unsigned char prior). Постановка ППП в очередь осуществляется с помощью директивы;

• формирования очереди фоновых задач task_create (TDB *p_newTDB) и запуска их выполнения start_tasks ();

• вспомогательные функции – функции обработки очереди, функция перехода в диспетчер из прерывания EndISR(), макросы BEGIN_DIR, END_DIR.

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

Разработанная ОС успешно прошла все тесты (табл. 1).

Таблица 1. Результаты тестирования

Содержание теста Ожидаемый результат

Проверка регистра статуса SREG Выполнение процессов из ПИ! 1-очереди и работа диспетчера не должны изменять регистра статуса 8КБО текущей фоновой задачи.

Проверка указателя стека SP Выполнение процессов из ППП-очереди и работа диспетчера не должны изменять указатель стека 8Р

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

Выполнение трех фоновых задач Фоновые задачи должны осуществляться последовательно друг за другом.

Проверка сохранности регистров при выполнении трех фоновых задач Фоновые задачи не должны изменять контекст друг другу

Таблица 2. Сравнение функциональных возможностей разработанной ОС и РгееЯТ08

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

РгееЯТОЗ Разработанная ОС

Вытесняющая и кооперативная многозадачность + +

Отсутствие ограничений на количество задач, которые может создать пользователь + +

Возможность периодического запуска задач + +

Директивный уровень разграничения критических секций – +

Двоичные, счетные, рекурсивные семафоры, мьютексы + –

Очередь сообщений – для обеспечения межзадачной коммуникации + –

Функции управления памятью + –

Функции статистики времени выполнения задач + –

Проведем сравнение разработанной ОС и свободно распространяемой ОСРВ РгееЯТ08 по функциональным возможностям и времени выполнения некоторых функций (таблицы 2 и 3, соответственно).

РгееЯТ08 – легко портируемая свободная ОС реального времени.

Весь системнонезависимый код из состава РгееЯТ08 написан на языке Си, что позволило разработчикам создать большое количество портов на различные архитектуры и средства разработки [6].

В качестве количественного критерия сравнения РгееЯТ08 и разработанной ОС выступило среднее время выполнения следующих операций:

• постановка задачи на выполнение, инициированная из обработчика прерывания;

• выполнение критической секции.

Таблица 3. Сравнение разработанной ОС с РгееЯТ08 по времени выполнения

Время выполнения операций, мкс Операционная система

РгееРТ08 Разработанная ОС

Постановка задачи на выполнение из обработчика прерывания 11 4

Вход в критическую секцию 0,6 0,3

Выход из критической секции 0,6 0,7

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

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

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

Выводы

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Евстифеев А.В. Микроконтроллеры AVR семейств Tiny и Mega фирмы «Atmel». – М.: Додэка-XXI, 2004. – 560 с.

2. Баранов В. Н. Применение микроконтроллеров AVR: схемы, алгоритмы, программы. – М.: Додэка-XXI, 2004. – 288 с.

3. Голубцов М.С. Микроконтроллеры AVR: от простого к сложному. – М.: Солон-Пресс, 2003. -288 с.

4. Официальный сайт компании ЭлеСи. // Сайт компании ЭлеСи. 2005. URL: http://www.elesy.ru (дата обращения: 18.01.2011).

5. scmRTOS: Операционная система реального времени для однокристальных

микроконтроллеров/ Руководство пользователя. – Новосибирск, 2006. – 109 с.

6. Щербаков К.С., Щербаков С.А. Особенности работы операционной системы реального времени FreeRTOS // Itech. Журнал интеллектуальных технологий. – 2011. – № 18. – С. 71-77.

Источник: https://cyberleninka.ru/article/n/realizatsiya-operatsionnoy-sistemy-dlya-mikrokontrollerov-avr-atmega32

Библиотека CMSIS

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

Стандартизуя интерфейсы всех продуктов производителей микроконтроллеров с ядром Cortex-M, можно сократить процесс создания нового проекта или переноса старого на микроконтроллер другого производителя.

ARM CMSIS – это независимый от производителя уровень аппаратной абстракции для серии ядер Cortex-M, а также интерфейс отладчика (англ. debugger). CMSIS предоставляет последовательные и простые интерфейсы для ядра, его периферии и операционных систем реального времени.

Библиотека CMSIS включает в себя следующие компоненты:

CMSIS-CORE: API для ядра Cortex-M и периферии. Эта часть предоставляет стандартизированный интерфейс для Cortex-M0, Cortex-M3, Cortex-M4, SC000, и SC300. Включает в себя также дополнительные SIMD-инструкции для Cortex-M4.
CMSIS-Driver: определяет основные драйверы интерфейсов периферии. Содержит API для операционных систем реального времени (ОСРВ, или англ. Real-Time operating systems – RTOS) и соединяет микроконтроллер с промежуточным ПО, таким как стек коммуникации, файловая система или графический интерфейс.
CMSIS-DSP: коллекция из более чем 60 функций для различных типов данных (относятся к обработке сигналов, DSP – digital signal processor): с фиксированной точкой (q7, q15, q31) и с плавающей точкой (32 бита). Библиотека доступна для Cortex-M0, Cortex-M3, и Cortex-M4. Реализация библиотеки для Cortex-M4 оптимизирована c использованием SIMD-инструкций.
CMSIS-RTOS API: общий API для систем реального времени. Эта часть предоставляет стандартизированный программный интерфейс для того, чтобы большинство программных шаблонов, промежуточного ПО, библиотек и других компонентов RTOS-систем могли работать на Cortex-ядре.
CMSIS-DAP (Debug Access Port): стандартизованное программное обеспечение для отладчика (Debug Unit), которое подключает CoreSight Debug Access Port. CMSIS-DAP поставляется отдельно и используется для интеграции (на отладочных платах). Мы будем использовать только CMSIS-CORE.

В нашей работе понадобится документ, предоставляемый компанией ARM – Cortex-M3 Devices Generic User Guide, который можно найти на сайте infocenter.arm.

com (или скачать pdf-версию, нажав на ссылку внизу страницы). В данном документе описываются регистры самого ядра – нам потребуются регистры встроенного (во все Cortex-M ядра) простого таймера SysTick.

Сохраните этот документ, мы будем использовать его уже совсем скоро!

Наше основное внимание будет сосредоточено на CMSIS-CORE. В дальнейшем мы познакомимся со Standard Periferal Library от компании ST, но сейчас рассмотрим CMSIS чуточку ближе.

Назначение файлов

Файл startup_.s (где вместо подставляется идентификатор фирмы-производителя, это stm32, и серия микроконтроллера, для нас это 100) включает в себя:

обработчик (англ. handler) сброса, который выполняется после сброса микроконтроллера и вызывает функцию SystemInit();
установку значений для Main Stack Pointer (MSP);
векторы исключений для Cortex-M-ядер с функциями;
векторы прерываний (о них мы поговорим позже).

Все обработчики прерываний имеют названия _IRQHandler. Пример:

g_pfnVectors: .word _eram .word Reset_Handler .word NMI_Handler .word HardFault_Handler .word MemManage_Handler .word BusFault_Handler .word UsageFault_Handler .word 0 .word 0 .word 0 .word 0 .word SVC_Handler .word DebugMon_Handler .word 0 .word PendSV_Handler .word SysTick_Handler .word WWDG_IRQHandler .word PVD_IRQHandler .word TAMPER_IRQHandler .word RTC_IRQHandler .word FLASH_IRQHandler .word RCC_IRQHandler .word EXTI0_IRQHandler

Файл startup_stm32f10x.s может отличаться в зависимости от среды разработки; для IAR он принимает следующий вид:

__vector_table
DCD sfe(CSTACK)
DCD Reset_Handler # Reset Handler DCD NMI_Handler # NMI Handler
DCD HardFault_Handler # Hard Fault Handler
DCD 0 # Reserved
DCD 0 # Reserved
DCD 0 # Reserved
DCD 0 # Reserved
DCD 0 # Reserved
DCD 0 # Reserved
DCD 0 # Reserved
DCD SVC_Handler # SVCall Handler
DCD 0 # Reserved
DCD 0 # Reserved
DCD PendSV_Handler # PendSV Handler
DCD SysTick_Handler # SysTick Handler # External Interrupts
DCD WWDG_IRQHandler # Window Watchdog
DCD PVD_IRQHandler # PVD through EXTI Line detect
DCD RTC_IRQHandler # RTC through EXTI Line
DCD FLASH_IRQHandler # FLASH

Файлы system_stm32f10x.c и system_stm32f10x.h предоставляют минимальные наборы функций для конфигурации системы тактирования.

void SystemCoreClockUpdate(void) – обновляет переменную SystemCoreClock и должна быть вызвана каждый раз, когда тактовая частота меняется во время работы.

void SystemInit(void) – инициализирует микроконтроллер, а именно систему тактирования (в частности PLL), содержит переменную, хранящую тактовую частоту, и вызывается в startup_.s

uint32_t SystemCoreClock – переменная отвечает за частоту тактирования и обеспечивает работу таймера SysTick.

Для работы ядра требуются файлы:

core_.h (для Cortex-M3 это core_cm3.h) – предоставляет доступ к регистрам ядра и его периферии;

core_cmInstr.h (нам не требуется) – специальные инструкции Cortex-M;

core_cmFunc.h (нам не требуется) – функции доступа к периферии ядра Cortex-M;
core_cm4_simd.h (нам не требуется) – SIMD-инструкции для Cortex-M4.

И последний файл, который нас будет интересовать больше всего – это заголовочный файл микроконтроллера .h (в нашем случае это stm32f10x.h). Он содержит перечисление IRQn_Type, где описываются все возможные исключения и прерывания.

typedef enum IRQn {
/* Cortex-M3 Processor Exceptions Numbers */
NonMaskableInt_IRQn = -14,
MemoryManagement_IRQn = -12,
BusFault_IRQn = -11,
UsageFault_IRQn = -10,
SVCall_IRQn = -5,
DebugMonitor_IRQn = -4,
PendSV_IRQn = -2,
SysTick_IRQn = -1, /* STM32 specific Interrupt Numbers */
WWDG_IRQn = 0,
PVD_IRQn = 1,
TAMPER_IRQn = 2,
RTC_IRQn = 3,
FLASH_IRQn = 4,
RCC_IRQn = 5,
EXTI0_IRQn = 6,
…

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

#define GPIO_CRL_MODE0_0 ((uint32_t)0x00000001)

На этом наше знакомство завершено, пора настроить среду разработки и приступить к программированию.

Источник: http://stm32.chrns.com/post/148790052979/cmsis

Микроконтроллеры семейств AVR, MSP430, STM32 и мои субъективные впечатления

Здравствуйте, обитатели Хабра. В этой статье хочу поделится своими впечатлениями об опыте программирования микроконтроллеров семейств AVR, MSP430, STM32.

Введение

В бытность мою студентом занимался я прикладным программированием на Delphi и горя не знал, но и счастья не ведал. Пока как то раз не посетил меня на четвертом курсе предмет «Микропроцессорные контроллеры». Ну и пошло, поехало.

Семейство микроконтроллеров AVR

Предмет «Микропроцессорные контроллеры» как раз и был посвящен программированию микроконтроллеров на примере семейства AVR Atmega фирмы Atmel. Лабораторные работы по данному предмету заключались в программировании отладочных плат с Atmega16 на ассемблере данного семейства в программной среде avr studio 4.18.

Программа отлаживалась при помощи симулятора и зашивалась в микроконтроллер посредством встроенного в отладочную плату LPT-программатора на логике через программу ponyprog2000.

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

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

Посмотрите сами тут. Тут вам для E-LAB и JTAG-отладчики есть. Но во времена написания лабораторных работ JTAG-отладка доступна не была. Поэтому мы пользовались встроенным в E-LAB симулятором.

Как и тогда библиотеки E-LAB позволяет создавать проекты с ОСРВ, работающей по принципу Round-robin. Последние версии E-LAB поддерживают и кооперативную многозадачность.

В принципе с этих двух циклов лабораторных работ я и начал свое знакомство с микроконтроллерами и в частности семейством AVR. Что можно сказать теперь? AVR — самое популярное семейство микроконтроллеров в мире, я думаю.

Arduino-мания только укрепила это. Эти простые в освоении микроконтроллеры и сейчас остаются лучшим решением для первого знакомства.

Позволяют получить опыт создания создания простых приложений с использование интерфейсов SPI, I2C, UART. Понять работу портов ввода/вывода, подсистемы прерываний.

По сути, на данном семействе можно научится основам и делать малые и средние проекты. В последних версиях AVR Studio можно делать проекты на С.

А если взять в руки паяльник то можно себя обеспечить и программатором и JTAG-отладчиком.
Есть желание начать? Тут тоже много всего. Фирменные отладочные платы и программаторы от Atmel крайне дороги.

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

на сложные математические вычисления может уйти много времени. Микроконтроллер может не успевать обрабатывать собранную или принятую информацию.

Последний проект для Atmega16 Я делал на С в среде разработки IAR Embedded Workbench for Atmel AVR.

Семейство микроконтроллеров MSP430

После семейства AVR микроконтроллерый мир уже открыл мне часть своих тайн.

А тут подоспел и новый предмет, посвященный также программированию микроконтроллеров, но это было уже семейство MSP430 фирмы Texas Instruments, а именно микроконтроллер msp430f169 на отладочной плате с ziff-панелью и минимальной обвязкой. Разработка программы для него и отладка проходили в среде IAR Embedded Workbench for MSP430 при помощи JTAG-отладчика MSP-FET430UIF.

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

Ведь под JTAG-отладкой можно по шагам видеть, что происходит в регистрах в памяти и где сейчас идет выполнение кода, ставить точки останова. С этого времени я и на IAR подсел. Ведь это кроссплатформенный компилятор выпущенный под множество микроконтроллерных семейств.

Стоит один раз запомнить интерфейс и не надо каждый раз, при переходе на новое микроконтроллерное семейство, переучиваться. Это ли не чудо? Но затягивает.

Минус только в стоимости полной версии. Вообщем на этом семействе я и начал свою работу, как программист микроконтроллеров. И связка язык C (по сути кроссплатформенный ассемблер), кроссплатформенная среда разработки IAR и JTAG-отладка всегда были вместе со мной.

Семейство MSP430 в отличие от AVR шестнадцатиразрядное и более производительное за счет применения встроенного аппаратного умножителя.

Возможность использования режимов пониженного энергопотребления обеспечивает увеличение срока службы элементов питания, при применении в мобильных портативных устройствах. А микроконтроллеры MSP430F5419 и MSP430F5438, с которыми я работал, на частоте 25 МГц в плотную подтягиваются к ARM.

Так что они такие мощные середнячки. Если иметь фирменный JTAG-отладчик, IAR for MSP-430, нормальную отладочную плату, то работать с ними одно удовольствие.

Семейство микроконтроллеров STM32

Последним я познакомился с семейством STM32 фирмы STMicroelectronics. Архитектура ARM сама по себе является дверью ко многим семействам. Т.к. для множества этих микроконтроллеров разных фирм потребуется только один JTAG-отлдачик J-Link или его клон. А также если есть

в наличии среда разработки IAR Embedded Workbench for ARM, то двери открыты.

Плюсом в сторону семейства STM32 является наличие библиотеки встроенной периферии, которая позволяет быстро писать свои пользовательские библиотеки с минимальными трудозатратами, а также 32-разрядность ядра в отличии от AVR и MSP430. Линейка микроконтроллеров STM32 включает много вариантов их внутреннего наполнения встроенной периферией от чего варьируется и стоимость. Например, микроконтроллер STM32L152VBT6 на ядре Cortex-M3, как микроконтроллеры семейства MSP430, нацелен на низкое энергопотребление и работает на 32 МГц.

Другой микроконтроллер STM32F107VCT6 также на ядре Cortex-M3 подходит для большинства задач возлагаемый на данный класс устройств и имеет частоту 72 МГц. Тут сразу видно, что для «тяжелой» математики и обработки микроконтроллеры на ядре Cortex-M3 куда больше подходят, чем MSP430 и AVR.

Я работал и с «тяжеловесом» данного семейства STM32F407VGT6 на ядре Cortex-M4, частота которого доходит до 168 МГц. «Большой брат» идеально подошел для решения сложных математических задач. Кроме того он имеет аппаратный FPU для математики с плавающей точкой.

Для семейства STM32 разработана линейка плат DISCOVERY, которая позволяет получить плату со встроенным JTAG-отладчиком ST-Link, причем его можно использовать, чтобы программировать платы собственной разработки.

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

Заключение

В заключении хочу сказать. Что у всех рассмотренных семейств есть свои плюсы. Со всеми связаны теплые воспоминания.

Источник: http://www.pvsm.ru/msp430/59108