Dezvoltarea software-ului Punerea în funcțiune a software-ului; Instrumente de dezvoltare încorporate; Electronicsnet
27 noiembrie 2012, 10:14 am | Joachim Kroll
Înainte ca un microcontroler să prindă viață, acesta trebuie alimentat cu software. Dar software-ul nu doar „rulează”, ci trebuie dezvoltat. Acest lucru necesită instrumente sofisticate. Din fericire, Infineon nu este lăsat pe propriile dispozitive. Există mulți furnizori care furnizează dezvoltatorilor de software „material” pentru arhitectura populară.
Pentru a programa software pentru microcontrolere, sunt necesare aceleași instrumente de dezvoltare ca și pentru software-ul PC: Un editor pentru codul sursă, precum și un compilator și linker pentru traducerea codului sursă în comenzi citibile de mașină. Dar acolo se opresc asemănările. Deoarece software-ul PC rulează pe același sistem sau cel puțin pe aceeași arhitectură pe care este dezvoltat (dezvoltare auto-găzduită).
Acest lucru nu ar fi posibil pe majoritatea microcontrolerelor, fie pentru simplul motiv că nu există conexiuni pentru tastatură și ecran, fie pentru că există prea puțină memorie și putere de procesare pentru a efectua un proces de compilare într-un timp acceptabil.
Prin urmare, software-ul microcontrolerului este dezvoltat pe PC și codul final este transferat la arhitectura terță parte a controlerului (dezvoltare încrucișată). Trebuie să ruleze acolo și - de regulă, nu funcționează ca niciun cod pe care încercați să îl puneți la lucru pentru prima dată.
Apoi apare întrebarea: Cum analizați aceste erori și cum revin mesajele de eroare la computerul de dezvoltare? Pe cât de simplă este această problemă, arată că sunt necesari mai mulți pași de dezvoltare și mai multe instrumente pentru dezvoltarea încrucișată decât pentru dezvoltarea auto-găzduită.
Ca să înrăutățească lucrurile, există un „multiculturalism” colorat în lumea microcontrolerelor și nu se poate vorbi de standardizare ca la procesoarele x86. Un anumit standard de facto a apărut odată cu arhitectura ARM, dar a vorbi cu adevărat despre standard aici ar fi o exagerare, deoarece în primul rând există ARM-uri în diferite generații și variante de bază (ARM 7/9/11, Cortex -A, -R, -M) și, în al doilea rând, esența microcontrolerului constă în faptul că perifericele sunt integrate pe cip.
Și astfel niciunul dintre zecile de mii de microcontrolere de pe piață nu este același. Este mai potrivit să vorbim despre arhitecturi mai răspândite și mai puțin răspândite - deoarece totul din microcontrolere este proprietar.
Sarcini generale
Un lanț de instrumente care acceptă toate arhitecturile Infineon este cel al Tasking/Altium. Fie că seria XC800 cu nucleul său 8051, familia XC2000/C166 pe 16 biți, ARM sau Tricore - Altium oferă o versiune potrivită pentru toate acestea. Tasking are propriul mediu de dezvoltare pentru 8 și 16 biți, adică XC800 și XC2000/166, care combină toate instrumentele secundare (compilator, asamblator, linker, cross-debugger) sub o singură suprafață.
Sub denumirea „VX-Tools” există o versiune pentru XC2000/166, ARM și TriCore care se potrivește în cadrul Eclipse cu CDT (C Development Tools). Instrumentele de sarcini pot funcționa împreună cu DAvE și suport, de ex. de asemenea, o examinare a codului conform standardului MISRA-C, care este important pentru proiectele auto.
Pană: un întreg ecosistem
Instrumentele de la Keil oferă, de asemenea, suport extins pentru arhitecturile Infineon - cu excepția TriCore. Keil are, de asemenea, diferite versiuni de instrumente de dezvoltare pentru 8, 16 și 32 biți. Ca filială ARM și filială germană ARM, Keil oferă un sprijin extins pentru această arhitectură.
Figura 1. Kitul de dezvoltare a microcontrolerului (MDK) este disponibil în diferite versiuni pentru diferite arhitecturi. Versiunea ARM conține nu numai instrumente de dezvoltare, ci și middleware.
Cu instrumentele Keil, interfața cu utilizatorul este mediul de dezvoltare µVision cu manager de proiect, editor și depanator. Întregul lanț de instrumente de la Keil se numește MDK (Microcontroller Development Kit) și include mult mai mult decât mediul de dezvoltare, inclusiv compilator, asamblator, linker și debugger (Imaginea 1).
MDK-ARM poate citi în proiecte generate cu DAvE3, dar conține și extensii care scutesc inginerul de a dezvolta caracteristici nediferențiale ale produsului: sistem de fișiere, gazdă USB și stivă de dispozitive, rețea TCP/IP, interfață CAN și Bibliotecile pentru desenarea interfețelor utilizator sunt incluse în versiunea completă. Cu RTX, există chiar și un sistem de operare slab în timp real, care oferă infrastructura pentru software-ul multitasking și este furnizat în codul sursă.
Cu arhitecturile de 8 și 16 biți, suita de instrumente se numește PK51 sau PK166, iar ecosistemul software din jur este puțin mai slab, dar există un kernel RTX chiar și pentru 8051. Schimbul de informații de depanare este, de asemenea, furnizat: Cu ULINK2, Keil oferă un adaptor de depanare care este conectat la portul USB al computerului de dezvoltare și la sistemul țintă prin JTAG sau prin modurile ARM Serial Wire Debug (SWD) ) sau Serial Wire Viewer (SWD). În același timp, memoria flash a sistemului țintă este programată prin intermediul acestui dispozitiv.
Adaptorul de depanare ULINKpro oferă funcții suplimentare, care pot, de asemenea, să înregistreze o urmă de comandă, să stabilească puncte de întrerupere și să citească conținutul memoriei. Aceasta permite analizarea întregii secvențe a programului.
IAR: universal, dar numai pentru două arhitecturi Infineon
Un alt mediu de dezvoltare foarte universal este IAR Workbench, despre care se spune că este potrivit pentru majoritatea microcontrolerelor. Cu toate acestea, în cazul Infineon, sunt acceptate doar arhitecturile ARM și XC800. Versiunea 8051 este disponibilă în diferite etape de extindere, de ex. diferențiați prin dimensiunea maximă admisă a codului, suport pentru sistemele de operare în timp real și prezența MISRA-C-Checker. Versiunea ARM are numeroase conexiuni cu instrumente partenere, cum ar fi depanatoare hardware sau sisteme de operare în timp real.
IAR oferă, de asemenea, instrumente de dezvoltare hardware, cum ar fi depanatorul JTAG J-Link, care abordează funcțiile de depanare interne ale cipurilor componentelor XMC4000, sau I-Jet, un instrument pentru corelarea codului și a consumului de energie. Aceasta înseamnă că software-ul poate fi optimizat în așa fel încât controlerul să consume cât mai puțină energie sau să poată fi identificate punctele care sunt responsabile pentru un consum de energie deosebit de ridicat. Integrarea Eclipse a IAR este încă relativ nouă. Până în prezent există un singur program de previzualizare a tehnologiei cu care compilatoarele C/C ++, asamblatoarele, linkerele și depanatoarele C-Spy pot fi integrate în Eclipse și apoi înlocuiesc instrumentele GNU corespunzătoare.
Wind River și HighTec: specialități pentru TriCore
Ca arhitectură Infineon singulară, TriCore este, fără îndoială, mai exotică decât XMC4000 cu nucleul ARM Cortex-M4. Selecția de instrumente este, de asemenea, mai mică pentru TriCore. Instrumentele VX de sarcini menționate mai sus (pentru Eclipse) sau compilatorul Diab de la Wind River intră aici în discuție. Diab era o companie independentă care a fost cumpărată de Wind River la scurt timp după trecerea mileniului.
Chiar dacă nu auziți nimic altceva de la Diab - instrumentele încă există, iar compilatorul Diab este caracterizat de codul optimizat de memorie pe care îl produce. Poate fi integrat în mediul de dezvoltare al bancului de lucru Wind River. Pe lângă TriCore, compilatorul Diab acceptă aproape toate celelalte arhitecturi moderne de 32 de biți.
O altă posibilitate de a genera cod pentru TriCore este platforma de dezvoltare TriCore de la Hightec EDV-Systeme. Hightec folosește cadrul Eclipse și un compilator C/C ++ bazat pe GNU. După selectarea unui microcontroler, platforma de dezvoltare generează independent o structură de cod de bază cu inițializările necesare și o buclă principală pentru a începe dezvoltarea internă sau importă un proiect DAvE.
Figura 2. Compilatorul de înaltă tehnologie poate instrumenta codul pentru a afișa acoperirea codului într-o imagine de ansamblu grafică.
Compilatorul poate utiliza diferitele moduri de adresare ale controlerului TriCore prin instrucțiuni pragma, cu care poate fi controlată distribuția optimă a codului și a datelor în memorie și optimizarea timpului de rulare. Compilatorul se poate adapta și la coexistența unui sistem de operare AUTOSAR de la ETAS, Elektrobit sau Vector.