Realitatea migrării în cruce între producătorii de MCU pe 32 de biţi este luată în considerare de Erlendur Kristjansson, Product Marketing Manager, Divizia de microcontrolere de înaltă performanţă la Microchip Technology.
Standardizarea pe o singură platformă de bază MCU este foarte dorită în mediul industrial, dar, chiar şi în cazul unui miez uzual, proiectanţii vor trebui să facă faţă unor probleme de portabilitate între periferice şi firmware.
Perifericele sunt esenţiale pentru migrare
Majoritatea proiectelor încep prin specificarea funcţiilor pe care sistemul le furnizează şi modul în care utilizatorii le vor accesa.
Acest lucru va determina circuitele care vor fi necesare şi perifericele necesare pe cip pentru a le controla. Dacă proiectantul doreşte să includă o interfaţă industrială HMI (Human Machine Interface), de exemplu, MCU va trebui să suporte un LCD şi fie butoane, fie ecran tactil; o interfaţă de comunicare cu maşina; LED-uri şi un buzer şi alte componente sonore. De aceea, MCU va trebui să integreze un controler CAN pentru comunicaţie; un convertor ADC pentru suportul ecranului tactil şi un temporizator PWM pentru buzer. Cu cât un periferic are mai multă funcţionalitate, cu atât este mai puţin necesar un circuit extern, ceea ce reduce mărimea programului pe care proiectantul trebuie să îl scrie. De exemplu, utilizarea modului buzer este mai simplă decât pregătirea unui semnal PWM pentru obţinerea aceluiaşi rezultat.
Tipic, un proiectant va dori să ştie doi factori cheie despre miez. Este suficient de rapid pentru a rula toate sarcinile software cerute de toate funcţiile oferite de produsul final? Realizează el toate sarcinile eficient?
Dacă răspunsul la ambele întrebări este “Da”, atunci majoritatea proiectanţilor nu acordă prea mare importanţă tipului de miez utilizat.
O mai mare atenţie este acordată posibilităţii de migrare a software-ului vechi şi firmware-ului de la un miez la următorul pentru a asigura suport acestor periferice. Deoarece majoritatea acestor programe pentru MCU pe 32 de biţi sunt scrise în C, o mare parte din ele pot fi recompilate pe orice miez, fiecare producător de MCU având caracteristici de periferice şi modele de programare unice pentru produsul lor, indiferent de miezul utilizat. Acesta este motivul pentru care portarea programelor este mai mult decât o provocare.
Portarea firmware-ului
Fiecare producător de MCU furnizează o bibliotecă de firmware ce conţine programe de pregătire şi rulare a perifericelor integrate în MCU. Totuşi, fiecare producător implementează aceste periferice într-un mod diferit, iar fiecare periferic poate avea diferite caracteristici. Acest lucru înseamnă că portarea unei aplicaţii de pe un MCU pe altul nu este o sarcină simplă.
ARM s-a preocupat de această problemă prin definirea unui standard privind nivelul de abstractizare al firmware-ului, denumit CMSIS (Cortex™ Microcontroller Software Interface Standard). Acesta a fost adoptat de toţi producătorii de MCU-uri ce utilizează miezuri Cortex-M şi este utilizat în bibliotecile lor de firmware.
Cu toate acestea, acest standard nu se adresează dificultăţii portarii perifericelor, şi nu implică o convenţie de nume sau funcţii standard. Ca rezultat, el reduce doar cu puţin efortul şi munca necesară pentru portarea unei aplicaţii între diferiţi distribuitori de microcontrolere ARM.
Proiectare în portabilitate
Chiar dacă distribuitorii de MCU-uri utilizează acelaşi miez ARM, nu este în interesul lor să simplifice portabilitatea către un alt distribuitor de MCU. Provocarea de a face un proiect portabil este pentru inginerii proiectanţi. Pentru simplificarea portabilităţii, proiectantul poate implementa un nivel abstract ce creează o interfaţă de programare standard între MCU, periferic şi programul de aplicaţie. Există cel puţin două căi de a aborda acest lucru:
• Poate fi dezvoltat un “înveliş” de trecere între biblioteca periferică a producătorului de MCU şi programele de aplicaţie. Deşi este probabil soluţia cea mai eficientă din punct de vedere al timpului, ea va adăuga mult program pe căile de comandă şi date.
• Se poate defini o schemă standard de funcţii şi variabile, şi se poate aplica fiecărei biblioteci de periferice.
Deşi aceasta evită cantitatea de program suplimentar, ea poate fi foarte costisitoare ca timp, în special pentru periferice complexe.
Portabilitatea trebuie să fie o parte a procesului de dezvoltare încă din etapele de început. Pe lângă firmware/ software, se mai pune problema compatibilităţii pin la pin, ceea ce de obicei înseamnă reproiectarea layout-ului PCB la trecerea de la un producător de MCU la altul. Poate de asemenea fi nevoie de o schimbare de componente externe, precum condensatoare şi stabilizatoare.
Portabilitatea în lumea reală
Portabilitatea uşoară între microcontrolerele pe 32 de biţi de la diferiţi producători poate rămâne pe lista de dorinţe a mediului industrial până la rezolvarea problemei portării perifericelor şi bibliotecilor firmware. Până atunci, proiectanţii trebuie să îşi asume responsabilitatea portabilităţii propriilor proiecte. Una dintre căile de obţinere a acestui lucru este alegerea unui MCU care să ofere o migrare uşoară către alte MCU în cadrul gamei de produse ale aceluiaşi producător.
De exemplu, Microchip a simplificat de curând gama sa de compilatoare C cu suita MPLAB® XC, ce oferă un compilator pentru fiecare arhitectură a sa pe 8-, 16- şi 32-biţi, asigurând suport pentru fiecare MCU PIC® şi DSC dsPIC®.
Pe lângă compatibilitatea – în sens crescător – dintre arhitecturi, acest lucru asigură păstrarea investiţiei în dezvoltare de software şi compatibilitate la pini, simplificând layout-ul PCB pentru dispozitive de înlocuire.
Astfel, în vreme ce proiectanţii aşteaptă un miez standard industrial, completat cu firmware şi periferice standard industrial, ei pot crea proiecte de viitor prin evaluarea cost / beneficii a migrării în cadrul portofoliului unui singur.
www.microchip.com