Проблемы совместимости программного кода для Cortex


PDF версия

В ноябре 2008 г. концерн ARM принял стандарт CMSIS (Cortex Microcontroller Software Interface Standard) для программных интерфейсов микроконтроллеров (МК) семейства Сortex. Этот стандарт позволяет снизить затраты на разработку новых устройств или перенос существующего программного кода с МК одного производителя на аналогичные МК другого. Попробуем разобраться, насколько достижима эта цель.

Как известно, характеристики МК, даже если используется одно и то же ядро, зависят от производителя. Стандарт СMSIS позволяет разрабатывать приложения для МК семейства Cortex-M на абстрактном уровне, независимо от производителя. Единый стандарт позволяет уменьшить затраты на обучение специалистов и ускорить проектирование и выход продукции на рынок за счет повторного использования частей кода.
Микроконтроллеры — устройства с очень высокой степенью интеграции, фактически, это системы на кристалле (СнК). Как и в других СнК, функция кристалла определяется периферийными аппаратными модулями, расположенными рядом с ядром. Процессор контролирует выполнение кода, а взаимодействие кристалла с другими частями системы происходит через периферийные устройства. Именно большое количество интерфейсов ввода-вывода отличает МК от классических СнК. С другой стороны, из-за этой особенности усложняется процесс наладки и управления МК, поскольку часть регистров должна быть установлена до того, как начнется обмен. Для упрощения написания программного кода на МК имеются установленные библиотеки, которые содержат все необходимые функции для установки регистров и управления различными блоками МК. У каждого производителя свои библиотеки, поэтому одна и та же модель МК будет иметь различные периферийные ресурсы.
Рассмотрим блоки, которые чаще всего различаются.

Архитектура системы

В зависимости от производителя в аналогичных МК интеграция системы (в частности, системная шина, дерево тактирования, ячейки памяти) организуется по-разному. Это позволяет создавать преимущества перед конкурентами, но посмотрим, к чему могут привести эти различия.
Дерево тактирования обеспечивает ритм работы всей системы, координируя выполнение всех других функций. Оно организовано так, чтобы система была оптимальной по быстродействию и экономичности работы. Набор функций и периферийных устройств, реализованных на кристалле, равно как и задачи, которые должен решать МК, напрямую влияют на структуру дерева. Поскольку каждый производитель использует собственную структуру, последовательность загрузки регистров может различаться, что необходимо учитывать при переносе программного кода.
Архитектура системных шин определяет, как все функции встроены в МК и что записывается в регистры при инициализации. В зависимости от набора периферийных возможностей может использоваться одна или несколько шин.
Как правило, МК имеют как энергозависимую (SRAM), так и энергонезависимую память (флэш). Однако конкретная структура зависит от производителя. Например, блок флэш-памяти может подключаться к ядру и шине данных или к системной шине. Модуль ОЗУ иногда разбивается на два независимых банка, чтобы обеспечить одновременный доступ для процессора и периферийных устройств. Структура памяти важна при составлении программного кода, а также оказывает прямое влияние на быстродействие системы при переносе кода на МК другого производителя.

Периферийные устройства

Каждый производитель использует стандартные и специальные периферийные устройства. Стандартные выполняют типичные функции, такие как последовательный обмен по UART или SPI. Это, например, таймеры или широтно-импульсные модуляторы. Стандартные периферийные устройства одинаковы у всех производителей, хотя в них могут быть улучшения, которые обеспечивают большую гибкость или дополнительные возможности. За счет таких улучшений производители получают конкурентное преимущество. Как и для других блоков, для стандартных периферийных устройств требуется набор регистров. Каждый производитель выбирает их по своему усмотрению.
Специальные периферийные устройства предназначены для выполнения уникальных для данного приложения задач, например ШИМ — для управления бесщеточным двигателем или протокол I2S — для аудиосистем и устройств цифровой подписи. В зависимости от сложности для специальных периферийных устройств может потребоваться от нескольких штук до нескольких десятков регистров.

Встроенные библиотеки

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

Назначение CMSIS

Стандарт CMSIS призван обеспечить совместимость платформ на аппаратном уровне. В версии 1.3 определены два типа функций и блоков МК. Одни осуществляют доступ периферийных устройств к процессору. К ним относятся определение имен, адресов и вспомогательных функций доступа к регистрам ядра и периферийным устройствам, а также интерфейсы ОСРВ, не зависящие от аппаратной реализации и содержащие определения каналов отладки.
Ко второму типу относятся процедуры, устанавливаемые производителем МК. Это функции доступа к периферийным устройствам — определения для всех периферийных устройств и функции доступа для периферийных устройств (опционально) — дополнительные вспомогательные функции.
Таким образом, CMSIS закрепляет язык описания блоков МК. В таблице 1 приведены характеристики одного и того же МК двух производителей. Видно, что ключевые параметры значительно различаются. Соответственно, программный код для этих двух моделей будет разным даже для простой стандартной задачи, такой как переключение портов ввода-вывода или использование UART. При переносе кода придется вносить изменения.
Единый язык CMSIS для доступа к элементам ядра дополняется интерфейсными функциями, разработанными производителем МК, поэтому совместимость программного кода не сохраняется. Встроенные библиотеки содержат базовые функции, например, обмен данными между процессором и периферийными модулями. Переход на абстрактный уровень позволяет сделать библиотеки переносимыми, однако при этом не учитываются аппаратные различия между МК. Если на новой платформе нет какой-либо функции, то в результате переноса кода возникнут ошибки несовместимости.

Уровни абстракции

Абстрактный уровень используется при разработке операционной системы устройства для обращения к процессору или при переходе на другое ядро. Процессоры имеют минимальный набор встроенных модулей, поэтому у различных производителей они не так сильно различаются, как МК. Процессор управляется программным обеспечением, а в МК функции записаны в ПЗУ, поэтому связь между ядром и периферией намного более тесная. По отношению к МК модель уровней абстракции имеет смысл только при работе с операционными системами реального времени (ОСРВ). С другой стороны, в ОСРВ код приложения оторван от аппаратной части, поэтому тщательного контроля, характерного для МК, не будет.
Если приложение работает под ОСРВ, оно может быть без проблем перенесено на любой МК с поддержкой данной ОС. Например, код для Cortex-M3, написанный под μCOS II (Micrium), может быть выполнен на платформе MIPS M4K. Приложение изолировано от аппаратного обеспечения до тех пор, пока все новые элементы имеют подходящие характеристики.
Исходя из того, что каждый производитель интегрирует ядро, память и периферийные модули собственным методом, сложно придумать один стандартный уровень абстракции для всех. К тому же, производители сами этого не хотят.
В большинстве приложений МК тесная связь между кодом и периферией очень важна. Именно она препятствует переходу на абстрактный уровень. Без привязки к аппаратной схеме могут выполняться только стандартные функции, например UART или SPI. Однако даже в этом случае программу придется изменить, если в ней используется функция, которой нет в библиотеке МК.

Встроенные библиотеки

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

Возможности переноса

В рассмотренном примере (см. табл. 1) оба МК имеют ядро Cortex-M3, поэтому записанные в ПЗУ библиотеки функций совместимы по стандарту CMSIS. Однако это не означает, что библиотеки специализированных функций переносимы. Если производители используют различные подходы к организации периферийных модулей, то программный код несовместим. Например, один производитель ориентируется на максимально эффективное использование специализированных периферийных ресурсов, а второй, наоборот, разрабатывает универсальный код с использованием стандартных модулей и функций. Тогда все специфические для приложения процедуры выполняются на основе демонстрационных примеров и рекомендаций по применению. При таких разных подходах сложно обеспечить бесшовную переносимость приложения. Названия функций в библиотеках могут не совпадать, тогда придется заменять их вручную.

 

Таблица 1. Различие периферийных ресурсов одной модели МК разных производителей

Произво­дитель 1

Произво­дитель 2

Протоколы связи

5хUSART

4хUSART

3хSPI

3хSPI/SSP

USB 2.0 OTG FS

USB OTG

АЦП

12 разр., 1 млн выборок/с

12 разр., 200 тыс. выборок/с

Счетчики

16 разрядов

32 разряда

Макс. частота внутреннего резонатора

72 МГц

100 МГц

Макс. емкость ОЗУ

48 кБ

64 кБ

 

Заключение

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

Литература
1. Kristjánsson Е. Application Portability for 32-Bit Microcontrollers — Reality or Myth?

Оставьте отзыв

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