Портиране между различни платформи 32 битови микроконтролери

07.02.2013   |   Начало»Статии

Редактор
Пепа Петрунова

Редактор
Пепа Петрунова

Ерлендур Кристиансон, продуктов мениджър високопроизводителни микроконтролери в Microchip Technology

Едно от най-силните желания на специалистите в областта на цифровата електроника е постигането на стандартизиране на една-единствена микроконтролерна платформа. На практика, обаче, дори и при работа с едно и също процесорно ядро, когато трябва да се премине към различна периферия и да се адаптира на фърмуера, дизайнерите се изправят пред редица проблеми.

За преносимостта от решаващо значение е периферията
Често конструкторите започват проектирането с подбор и класификация на функциите, които трябва да осигурява устройството и начина, по който потребителят ще ги използва. Това определя външните схеми, които ще са необходими и вградената в микроконтролера периферия, която ще ги управлява. Ако, например, е предвиден операторски интерфейс (HMI), микроконтролерът трябва да поддържа LCD и бутони или чувствителен на допир екран, комуникационен интерфейс към управляваното устройство, светодиодна и звукова сигнализация. Това означава, че микроконтролерът трябва да има вграден CAN контролер за комуникация, ADC за чувствителния на допир екран и PWM таймер за звука. Колкото повече функции има периферията, толкова по-малко външни ИС ще са необходими, което намалява и обема на програмния код, който трябва да се напише.

Проектантът иска да знае две неща за процесорното ядро: дали е достатъчно бързо, за да изпълнява всички софтуерни задачи, изисквани от функционалността на крайния продукт и дали ще може да ги изпълнява достатъчно ефективно. Друго съображение е каква част от вече използвания софтуер и фърмуер може да бъде прехвърлена от едно ядро към друго, за да се осигури поддръжка на периферията. Тъй като повечето програми за 32-битови микроконтролери са написани на C, те биха могли да бъдат рекомпилирани към всяко ядро. От друга страна, всеки производител на микроконтролери има функции и програмни модели на периферията, които са характерни за неговите продукти, независимо от използваното ядро. Точно това прави преноса на програмния код толкова проблематичен.

Преносимост на фърмуера
Производителите на микроконтролери осигуряват фърмуерни библиотеки с програми за конфигуриране и използване на интегрираната в микроконтролерите периферия. Всеки производител обаче реализира по различен начин периферните блокове, освен това всеки блок може да има различна функционалност. Това означава, че прехвърлянето на дадено приложение от един микроконтролер към друг не е лесна задача.

ARM решава този проблем чрез дефиниране на стандарт за ниво на абстрактно представяне на фърмуера (CMSIS). Той се използва от производители на микроконтролери, базирани на Cortex-M ядра и в техните фърмуерни библиотеки. Стандартът обаче не елиминира проблемите при пренос към друга периферия, нито осигурява правила за наименоване на функции и променливи. В резултат той не улеснява значително задачите по пренасяне на определено приложение между ARM микроконтролери на различни производители.

Осигуряване на преносимост в процеса на разработка
Дори когато производителите използват едно и също ARM ядро, те нямат интерес да осигурят лесна преносимост към микроконтролерите на другите производители. Задачата за реализиране на преносимост се прехвърля към инженера проектант. За да опрости преносимостта, конструкторът може да използва ниво на абстрактно представяне, създаващо стандартен програмен интерфейс между микроконтролера, хардуера на периферията и приложните програми. Има поне два начина за реализация на това:
- Може да бъде дефинирана стандартна схема за наименоване на функции и променливи, прилагана към всяка библиотека за периферия. Така програмният код остава компактен, но нараства времето за разработка, особено при сложна периферия.
- Може да бъде разработено обвиващо ниво, което да “превежда” между програмния код на приложението и библиотеката за периферията на производителя на микроконтролера. Това е ефективен от гледна точка  на времето метод, при който обаче се създава по-сложен и обемен код за команди и данни.
Портируемостта трябва да е част от процеса на разработка още от най-ранните му етапи. При преминаване от микроконтролер на един производител към друг, освен адаптирането на софтуера/фърмуера, проблем е и съвместимостта по изводи, която често води до ново проектиране на печатната платка. Може да се наложи и смяна на външни компоненти като кондензатори и регулатори.
 
Преносимост в реалния свят
По всичко личи, че лесната преносимост между 32-битови микроконтролери на различни производители ще си остане в сферата на пожеланията, поне докато се разрешат проблемите с преноса на библиотеките за периферията и фърмуера. Дотогава конструкторите ще трябва да осигуряват преносимостта на своите проекти. Един от пътищата за това е използването на микроконтролери, които дават възможност за лесна миграция към други на същия производител.

Като един пример, компанията Microchip опрости гамата си от C компилатори чрез пакета MPLAB XC, използващ един и същ компилатор за 8-, 16- и 32-битовите архитектури и поддържащ всички PIC MCU и dsPIC DSC. Това осигурява възходяща съвместимост между архитектурите, съхранявайки инвестициите в разработка на програмен код и съвместимост по изводи при различните корпуси, опростяваща разработката на печатните платки.

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

Ключови думи: Микроконтролери   PIC   ARM   MPLAB   dsPIC   фърмуер   Microchip  

Област: Статии