Периферийные устройства играют фундаментальную роль в процессе миграции.
Многие проекты начинаются с определения функций, которые будет предоставлять система, и способов доступа к ним для пользователей.
Это определяет необходимую схемотехнику и периферийные устройства, которые необходимо интегрировать в микроконтроллер для управления ими. Например, если разработчик хочет включить промышленный человеко-машинный интерфейс (HMI), микроконтроллер должен поддерживать ЖК-дисплей и несколько кнопок или сенсорный экран; интерфейс связи с машиной; светодиоды; и звуковой сигнал или другой аудиокомпонент. Следовательно, микроконтроллер должен интегрировать контроллер CAN для связи; аналого-цифровой преобразователь для сенсорного экрана; и ШИМ-таймер для звукового сигнала. Чем больше функциональность периферийного устройства, тем меньше потребуется внешней схемотехники, что может уменьшить объем кода, который должен написать разработчик. Таким образом, при звуковом сигнале проще настроить ШИМ для достижения того же результата.
Как правило, разработчиков интересует два основных момента, касающихся ядра: достаточно ли оно быстрое для выполнения всех программных задач, необходимых для поддержки всех функций, предлагаемых конечным продуктом? И эффективно ли оно выполняет все эти задачи? Если ответ на оба вопроса положительный, то большинство разработчиков не будут слишком беспокоиться о типе используемого ядра.
Более важным является объем существующего программного обеспечения и микропрограмм, которые можно перенести с одного ядра на другое для обеспечения поддержки периферийных устройств. Поскольку большая часть кода 32-битных микроконтроллеров написана на языке C, значительная его часть может быть перекомпилирована для любого ядра. Однако каждый производитель микроконтроллеров будет иметь функции периферийных устройств и модели программирования, эксклюзивные для его собственной продукции, независимо от используемого ядра. Именно это делает переносимость кода сложной задачей.
Переносимость прошивки:
Каждый производитель микроконтроллеров предоставляет библиотеку прошивки, содержащую код для настройки и запуска периферийных устройств, интегрированных в их микроконтроллер. Однако каждый производитель также реализует эти периферийные устройства по-разному, и каждое периферийное устройство может иметь разные функции. Это означает, что перенос приложения с одного микроконтроллера на другой — непростая задача.
Компания ARM решила эту проблему, определив стандартный уровень абстракции встроенного ПО, называемый стандартом интерфейса программного обеспечения микроконтроллеров Cortex™ (CMSIS), который был принят всеми производителями микроконтроллеров, использующими ядра Cortex-M, и используется в их библиотеках встроенного ПО. Однако этот стандарт не решает проблемы переносимости периферийных устройств и не устанавливает стандартную систему именования переменных или функций. В результате он мало что делает для уменьшения усилий и работы, необходимых для переноса приложения между различными производителями микроконтроллеров ARM.
Проекты по обеспечению переносимости:
Хотя производители микроконтроллеров могут использовать одно и то же ядро ARM, у них нет стимула упрощать переносимость на микроконтроллеры других производителей. Таким образом, задача обеспечения переносимости проекта ложится на плечи инженера-разработчика. Для упрощения переносимости разработчик может реализовать уровень абстракции для создания стандартного программного интерфейса между микроконтроллером, периферийным оборудованием и кодом приложения. Существует как минимум два способа достижения этой цели:
- Для преобразования кода приложения в библиотеку периферийных устройств производителя микроконтроллера можно разработать слой компенсации или покрытия. Хотя это, вероятно, наиболее эффективное по времени решение, оно добавит больше кода в пути команд и данных.
- Определить стандартный метод именования функций и переменных и применить его к каждой библиотеке периферийных устройств. Хотя это позволяет избежать добавления кода, это может быть трудоемким процессом, особенно для сложных периферийных устройств.
Портативность должна быть частью процесса разработки с самых ранних этапов. Помимо прошивки/программного обеспечения, существует проблема совместимости выводов, которая обычно включает в себя перекладку печатной платы при переходе от одного поставщика микроконтроллеров к другому. Также может потребоваться замена внешних компонентов, таких как конденсаторы и стабилизаторы.
Реальная переносимость:
Легкая переносимость между 32-битными микроконтроллерами от разных производителей остается лишь пожеланием для отрасли до тех пор, пока не будут решены проблемы переносимости периферийных устройств и библиотек встроенного ПО. До тех пор разработчики должны брать на себя ответственность за переносимость своих разработок. Один из способов решения этой проблемы — выбор микроконтроллера, который облегчает миграцию на другие микроконтроллеры в рамках одной линейки продукции производителя.
Например, компания Microchip недавно упростила свой портфель компиляторов C, выпустив пакет MPLAB® XC, который предлагает компилятор для каждой из своих 8-, 16- и 32-битных архитектур и поддерживает все микроконтроллеры PIC® и цифровые сигнальные контроллеры (DSC) dsPIC®. Это, в сочетании с кросс-архитектурной совместимостью для экономии средств на разработку кода и совместимостью выводов в различных корпусах для упрощения компоновки печатных плат для прямой замены, делает его идеальным для этой цели.
Таким образом, пока разработчики ждут завершения разработки стандартного ядра со стандартными периферийными устройствами и встроенным ПО, они, по крайней мере, могут создавать перспективные проекты, оценивая соотношение затрат и выгод от перехода на каталог одного производителя в начале каждого проекта.
