Trecerea de la 8 biţi la 32 biţi

18 OCTOMBRIE 2008

Ecosistem – nu doar arhitectură
Tradiţional procesoarele pe 8- şi 16-biţi au fost foarte ieftine, dar au memorie limitată – dimensiunea programului era foarte importantă. Aceasta înseamnă că programele erau adesea construite la nivele joase. Aplicaţiile utilizează normal un comutator de sarcini, mai curând decât un RTOS sau dacă utilizează un RTOS, este convenabil să fie o chestiune particulară decât un produs comercial sau open source. Depanarea este printr-un monitor de ROM, sau printr-un emulator. Aplicaţiile au tendinţa să fie monolitice – un procesor poartă o aplicaţie unică, uzual directă. Pe de altă parte, dispozitivele pe 32 de biţi sunt mai puţin constrânse de dimensiunea programului (cu toate că unele dintre produsele noi şi foarte ieftine bazate pe ARM Cortex-M3, sunt încă limitate ca memorie: Luminary Micro LM3S102 are numai 2k RAM şi 8k Flash). Ele sunt în mod normal programate utilizând C++. Dispozitivele pe 32 de biţi utilizează aproape inevitabil un RTOS, fie comercial, fie în unele cazuri, open source. Depanarea se realizează prin porturi JTAG şi de asemenea, în dispozitivele ARM, utilizează ETM (Embedded Trace Macrocells). Acestea sunt macro-celule care capturează informaţia pe starea procesorului înainte şi după un eveniment specific, fără overhead pe procesor. Datele comprimate sunt citite de pe cip printr-un port dedicat. Un procesor pe 32 de biţi poate fi utilizat pentru o întreagă gamă de aplicaţii, de la simple la foarte complexe.
În vreme ce opţiunile arhitecturale includ MIPS, Power PC şi X-Scale, el este ARM care domină scena de 32 de biţi. Produsele cu procesor ARM de la Philips, ST, Atmel, Oki, TI, şi altele, sunt suportate de un uriaş ecosistem de unelte software şi hardware. ARM7 acoperă o parte semnificativă a pieţei, cu peste 3 miliarde de bucăţi fabricate, cu preţ ce poate fi sub 4$. Dar noua familie ARM Cortex-M3 a spulberat bariera de preţ, cu produse ce costă sub 1$ şi deja s-au anunţat noi implementări pentru o serie întreagă de nume cunoscute.
Restul acestui articol se referă la trecerea către ARM, dar mare parte din informaţie este utilă şi pentru alte arhitecturi pe 32 de biţi. Trebuie apreciat că în noua arhitectură, tot ce ştiţi despre evaluarea arhitecturilor pe 8-biţi se aplică în continuare.

Opţiuni la trecerea pe 32 de biţi
Există două arhitecturi ARM principale pentru care se poate opta: binecunoscuta arhitectură ARM7TDMI şi Cortex-M3, lansată recent. În jur de 8 companii deja vând procesoare de uz general bazate pe ARM7TMI şi titularii de licenţe promit lansări de produse care să se alăture primelor componente cu Cortex-M3, gama Stellaris de la Luminary.
ARM7TDMI suportă atât seturile de instrucţiuni ARM cât şi Thumb. ARM este un set de instrucţiuni pe 32 de biţi; Thumb oferă cele mai des utilizate instrucţiuni pe 16-biţi. Thumb îmbunătăţeşte densitatea de cod cu până la 30% faţă de instrucţiunile ARM, dar performanţele se vor degrada deoarece sunt necesare mai multe instrucţiuni pentru a realiza o funcţie. Echilibrul dintre Thumb şi ARM este ales de programator, acesta având de ales între performanţe şi dimensiune de program. Uneltele de generare a programului gestionează comutarea între diferite stări prin generarea unor coduri de legătură. (Acest lucru produce extra-cod şi consumă cicluri de procesare). Reglarea fină a echilibrului ARM/Thumb pentru optimizarea memoriei şi performanţei poate fi consumatoare de timp (şi frustrantă în acelaşi timp). Cortex-M3 a fost proiectat să se adreseze pieţei embedded, cu o implementare fizică foarte compactă pentru înalte performanţe şi joasă putere, utilizând setul de instrucţiuni Thumb-2. Thumb-2 extinde Thumb cu noi instrucţiuni pe 16- şi 32 de biţi pentru a se apropia mai mult de performanţele unei implementări ARM pure, dar păstrând şi densitatea de cod a Thumb. Nu există nici o comutare de stare, astfel încât nu este nevoie de cod sau performanţe superioare.
În vreme ce ARM7TDMI ISR (Interrupt Service Routines) necesită segmente de limbaj de asamblare pentru lucrul cu registrele, Cortex-M3 ISR poate fi scris în C. Cortex-M3 nu necesită utilizarea limbajului de asamblare pentru boot/pornire.

Motive de trecere la 32 de biţi
Pot fi motive bune de a rămâne pe arhitecturi de 8-biţi. De exemplu, dacă este nevoie doar de îmbunătăţirea performanţelor unei aplicaţii existente, creşterea se poate face în cadrul aceleiaşi familii şi trebuie să fie simplă, determinând un timp rapid de lansare pe piaţă. Similar, o aplicaţie mică şi bine definită, care necesită doar adăugarea unei caracteristici sau două, poate rămâne confortabil într-o implementare pe 8 biţi. De asemenea aplicaţiile în care costul produsului final se măsoară în cenţi, nu în dolari, se recomandă să rămână la soluţii pe 8 biţi. Dar atunci când se porneşte un nou proiect, când aplicaţia necesită o îmbunătăţire semnificativă în performanţă sau funcţionalitate, când aplicaţia existentă are deja constrângeri în a fi pe 8 biţi – este momentul de a lua în considerare procesoarele pe 32 de biţi. Iar avantajele sunt chiar mai mari decât o memorie mai mare şi performanţe de procesor mai crescute. Gama de opţiuni în ceea ce priveşte performanţa de procesor şi dimensiunea memoriei oferă o cale ideală pentru îmbunătăţiri viitoare sau pentru crearea de familii de variante pornind de la un design de bază. Trecerea la dispozitive pe 32 de biţi cu memorie şi periferice integrate pot reduce dimensiunea de placă, iar o alegere atentă a dispozitivului poate adăuga caracteristici fără costuri suplimentare.

Port sau start nou
Pentru o aplicaţie existentă, va fi un port nou sau va merita să se înceapă din nou de la schemă? Este aplicaţia periferic intensivă, sau este cu calcul intensiv cu interacţiune minimă periferică? (Sau undeva între acestea două?) Este codul sursă încă disponibil? Dacă nu, este cazul pentru un start complet nou. Dacă este cod C, este strict ANSI C, sau este numai C care rulează? Unele compilatoare au propriile extensii embedded, care sunt specifice implementării şi care cauzează probleme de transfer. Dacă există nesiguranţă, majoritatea compilatoarelor au o opţiune “numai ANSI C”: recompilarea cu aceasta va rezolva orice dubii. Vechimea celei mai vechi linii de program, şi numărul de revizuiri ale programului, vor avea impact asupra a cât de greu este transferul. Dacă codul sursă este disponibil, tot ceea ce este necesar este o simplă recompilare pentru a o rula pe produsul ARM pe 32 de biţi. Dacă sursa C/C++ a fost ţintită pe setul de instrucţiuni ARM, atunci trecerea la Cortex-M3 este o simplă recompilare, în vreme ce sursa ţintită pentru Thumb poate fi utilizată ca atare (Thumb-2 este o extensie a Thumb) sau recompilată. Sursele assembler pentru ARM ISA vor necesita să fie reasamblate pentru Cortex-M3, dar aceasta se face cu uşurinţă cu ARM RVDS (RealView Developer Suite) sau un mediu de dezvoltare similar utilizând Unified Assembler, sau surse de assembler pentru Thumb pot fi, fie utilizate ca atare, fie reasamblate similar. Alte cerinţe de transfer pot fi editarea ISR pentru îndepărtarea fragmentelor assembler, şi ştergerea codului de boot şi configuraţia sistemului.

Dar un RTOS?
Utilizarea unui RTOS poate aduce numeroase avantaje pentru dezvoltator şi pentru aplicaţie, dar care sunt elementele care să indice că este necesar un RTOS? Dacă dimensiunea programului este peste 64k, există probabil un motiv pentru a căuta un RTOS. (Dacă este sub 32k atunci un RTOS nu este probabil necesar.) Un RTOS oferă avantaje dacă aplicaţia gestionează mai mult decât o funcţie, sau dacă dezvoltări viitoare se estimează să implementeze mai mult decât o funcţie. Avantajele unui RTOS cu privire la sarcina de comutaţie sunt împărţite în 4: performanţe, complexitate, productivitate şi documentaţie. Performanţa nu este o măsură a productivităţii absolute, dar, în loc, este o garanţie a timpului de răspuns la un eveniment extern în cazul cel mai defavorabil, adică timpul necesar procesării întreruperii şi programării reluării funcţiei.
Complexitatea, sau mai bine spus reducerea complexităţii, este un rezultat direct la a nu trebui să se introducă logică de alocare a procesorului peste tot în aplicaţie. Numai şi inserarea logicii este dificilă, dar RTOS devine chiar şi mai utilă atunci când aplicaţia necesită mentenanţă şi upgrade. Un efect asociat reducerii complexităţii este adesea creşterea productivităţii procesorului, cauzată de eliminarea timpului alocat pentru operaţii neproductive, şi o creştere a sensibilităţii sistemului. Divizarea unei aplicaţii în sarcini, necesară pentru funcţionarea eficientă a RTOS, face ca aplicaţia să fie mai uşor de documentat şi de înţeles (ceea ce o face de asemenea şi uşor de întreţinut).

Alegerea RTOS
Dar pe piaţă fiind o mulţime de RTOS disponibile pentru arhitecturi ARM, care sunt factorii de decizie? Un factor semnificativ este preţul. Există numeroase modele cu preţuri diferite, prin care furnizorii de RTOS încearcă să răspundă diferitelor necesităţi de piaţă, dar să obţină şi profit. Modelele pot fi specifice procesoarelor care acoperă toate codurile de repere 2868 (cu performanţă mai mică Cortex-M3 Thumb2-Ospace 2x) ARM7TDMI Thumb Ospace-2908 Cortex-M3 Thumb2 -Otime-3008 (cu performanţă mai mică sau egală cu 20%) aplicaţia ARM7TDMI ARM -Otime 3684 Dhrystone: RO-Code size (bytes) O3 Aplicaţia lungimii codului (dhry_1.c + dhry_2.c), cu excepţia contribuţiei de biblioteci compilate cu RVCT 3.0, “-O3 – no_inline – no_multifile”; Chiar şi pentru acest mic exemplu, dimensiunea codului Thumb-2 este mai mică cu 20% decât ARM, iar pentru aplicaţii mai realiste, dimensiunea codului este mai mică cu 30%+ pentru utilizarea unui anumit procesor), produse sau familie de produse specifice (care acoperă fie un singur produs sau derivate ale acestui produs) sau specifice site-ului (care acoperă tot ceea ce produce la un anumit site).
Modelul de preţ trebuie să fie luat în considerare ca o parte importantă în comparaţia diferitelor RTOS. O caracteristică importantă pentru orice RTOS trebuie să fie depanarea calificată a kernelului, permiţând uneltei de depanare să afişeze starea structurilor de date specifice pentru kernel. Desigur, pentru ca această depanare să fie folositoare, lanţul de unelte trebuie să suporte această caracteristică. Pot fi puse la dispoziţie, însoţite de un sistem de operare sau disponibile ca opţiune plug in, o serie de componente software, precum sisteme de fişiere flash, pachete pentru USB, SAN sau TCP/IP, software de reţea, baze de date embedded şi management de date embedded. Există două întrebări importante: ce opţiuni sunt necesare? Cum se potrivesc cel mai bine?

Alegerea compilatorului
Datorită faptului că trecerea la 32 de biţi se datorează dorinţei de trecere la un limbaj de nivel mai înalt, alegerea compilatorului este importantă.
Chiar şi prin arhitecturi pe 32 de biţi ce oferă un spaţiu de memorie mai mare, dimensiunea programului este încă foarte importantă: eficienţa compilatorului, atât ca dimensiune a programului pe care-l produce, cât şi ca eficienţă a execuţiei, trebuie să fie un factor primar atunci când se doreşte o evaluare. De asemenea, eficienţa compilatorului se reflectă şi într-un consum energetic mai mic al sistemului; cu cât procesorul are mai puţine instrucţiuni de executat, cu atât este consumată o cantitate mai mică de energie.
Astăzi prima alegere în ceea ce priveşte limbajul este C++, dar există semne de întrebare. Este compilatorul EABI (Embedded Applications Binary Interface) conform, permiţând obiectelor partajate şi executabilelor să lucreze împreună în diferite medii de execuţie? Suportă el întreaga linie de produse ARM, ambele familii de produse (ARM7, ARM9, ARM11, Cortex) şi seturile de instrucţiuni (ARM, Thumb2)? Este furnizorul obligat să menţină acest suport? Ce pachete de plăci suport sunt disponibile? (BSP – un pachet cu o placă conţinând procesorul ţintă pentru dezvoltare de cod şi depanare în afara sistemului ţintă şi software relevant).
Iar întrebările trec de la pur tehnic la comercial. Ce parteneriate are furnizorul compilatorului cu distribuitorul RTOS? Dacă există o relaţie cu distribuitorul RTOS-ului ales, sistemul rezultat poate fi mai eficient. Similar, o relaţie cu distribuitorul de unelte JTAG, atunci depanarea poate fi mult mai uşoară. Este importantă analiza legăturilor din lanţurile de unelte deja aflate în uz. Suportul tehnic al unei companii, particular pe piaţa locală, poate fi un factor decisiv pentru unii utilizatori.

Alegerea uneltelor de depanare
Familiile ARM existente au o serie de unelte de dezvoltare, dintre care multe deja suportă Cortex-M3. Sistemul de monitorizare familiar ROM, ce stă în memorie şi îndeplineşte funcţii de bază, precum descărcarea memoriei prin port serial, este intruziv, utilizează resursele sistemului, astfel încât are o influenţă asupra mediului pe care-l monitorizează, şi nu este suficient de sofisticat pentru depanare în mediul ARM. O interfaţă JTAG (Joint Testing Action Group) permite ca programele să fie transferate pe flash on-chip sau pe RAM. Pentru depanare, interfaţa poate fi utilizată pentru stabilirea unor puncte de întrerupere, pentru a permite execuţie pas cu pas, pentru a monitoriza starea memoriei şi alte tehnici pentru observarea executării aplicaţiei. Aproape orice produs ARM are un port JTAG, iar uneltele nu sunt scumpe ($49 – $1495), beneficiind de o gamă largă de caracteristici uzuale. Depanarea prin urmărire caută condiţiile ce au cauzat declanşarea unei întreruperi. Un ETM (Embedded Trace Macrocell) pe cip trimite datele despre instrucţiuni şi transferuri de date către un mare buffer de memorie circular (de la 128k la câţiva gigabyte). Odată declanşat punctul de întrerupere, bufferul transferă datele pe un PC, unde pot fi analizate şi se poate vedea ce instrucţiuni au fost executate. Nu fiecare dispozitiv ARM are un ETM, cu toate că este prezent pe un număr crescut de dispozitive ARM7 şi ARM9 şi este o caracteristică opţională pentru Cortex-M3. Preţurile hardware-ului variază în gama de la $1295 la “mai mult decât o persoană sănătoasă îşi poate permite”. ETB (Embedded Trace Buffer), o abordare relativ nouă şi încă nu foarte răspândită din punct de vedere al suportului, oferă memorie pe cip, mai exact decât în proba de test.

Concluzii
În lumea embedded, ca şi în cea reală, fiecare decizie are un preţ, iar rezultatul unei serii de decizii este uzual o serie de compromisuri. La fiecare sfârşit al spectrului de complexitate al aplicaţiei, deciziile asupra cărei arhitecturi să fie utilizate sunt relativ simple. În zona medie lucrurile nu sunt foarte formate. Deşi odată cu apariţia economicelor procesoare bazate pe ARM Cortex-M3, suportate de întregul sistem de dezvoltare şi depanare ARM, numărul de compromisuri a început să scadă, iar deplasarea către procesoare pe 32 de biţi este o realitate, chiar şi pentru produse cu preţuri de vânzare mici.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile necesare sunt marcate *

  • Folosim datele dumneavoastră cu caracter personal NUMAI pentru a răspunde comentariilor/solicitărilor dumneavoastră.
  • Pentru a primi raspunsuri adecvate solicitărilor dumneavoastră, este posibil să transferăm adresa de email și numele dumneavoastră către autorul articolului.
  • Pentru mai multe informații privind politica noastră de confidențialitate și de prelucrare a datelor cu caracter personal, accesați link-ul Politica de prelucrare a datelor (GDPR) si Cookie-uri.
  • Dacă aveți întrebări sau nelămuriri cu privire la modul în care noi prelucrăm datele dumneavoastră cu caracter personal, puteți contacta responsabilul nostru cu protecția datelor la adresa de email: gdpr@esp2000.ro
  • Abonați-vă la newsletter-ul revistei noastre