Alegerea microcontrolerului optim pentru o aplicaţie embedded

by donpedro

Alegerea microcontrolerului se face la începutul unui proiect de control embedded. Opţiunile sunt de a alege un MCU pe 8 biţi, 16 biţi sau 32 de biţi şi, fie să se înceapă de la un dispozitiv economic şi să se migreze către variante superioare, fie să se coboare de la un microcontroler de ultimă generaţie.

de Keith Curtis, Inginer principal de aplicaţii, Departamentul de securitate, microcontrolere şi dezvoltare tehnologică, Microchip Technology Inc.

Nu există reguli grele şi rapide: un număr de factori vor influenţa decizia, incluzând aici nivelul de control şi puterea de procesare ce va fi necesară proiectului, limitările energetice, dar lista este aproape fără sfârşit. Cerinţe precum necesitatea de operare în medii dure, sau de interfaţare cu un om aflat la comanda altui sistem poate fi la fel de vitală ca şi luarea în considerare a rapidităţii cu care produsul trebuie să răspundă la schimbări. Rezultatul final poate fi un blocaj în selecţie prin cântărirea conflictelor dintre cerinţe şi necesităţi.
Soluţia poate fi găsită într-un document de cerinţe ce dă oportunitatea unui inginer să analizeze alternativele.

Prima selecţie trebuie să se refere la funcţionalitatea de bază:
1. Ce sarcini are de îndeplinit sistemul?
2. Care sunt intrările şi ieşirile sistemului?
3. Ce cantitate de date trebuie stocată?
4. Cât de repede trebuie sistemul să realizeze sarcinile şi să răspundă la evenimente?
Tabelul 1 prezintă o listă de exemplu pentru un control de termostat simplu.

Constrângerile de proiectare trebuie analizate în partea a doua:
1. Care este ţinta de cost pentru materiale şi asamblare?
2. Care este cerinţa de putere a sistemului?
3. Care sunt limitările dimensionale ale sistemului?
4. Care va fi mediul de operare pentru sistem?
Tabelul 2 prezintă un exemplu pentru acelaşi sistem simplu de control cu termostat.

Odată ce aceste cerinţe sunt clar definite, poate fi schiţată o listă preliminară de cerinţe de resurse pentru sistem, după cum se poate observa în următorul exemplu:
1. Memorie de date – câtă memorie RAM de date este necesară?
• 165 byte
2. Memorie flash – cât spaţiu de program este necesar?
• 2300 de cuvinte
3. Periferice – listă cu ce periferice pe cip “trebuie avute” şi ce periferice pe cip sunt “bine de avut”?
Trebuie avute: • Periferic LCD • USART • ADC
Bine de avut: • Periferice pentru senzor tactil capacitiv • Periferic ceas de timp real
4. Circuit extern – ce alte condiţionări de semnal sau circuite de control sunt necesare? • Senzor de temperatură
• Temporizator de siguranţă (Watchdog timer)
• Drivere colector deschis pentru cald/rece
• Stabilizator de tensiune
5. Viteză de procesare – ce valoare MIPS este necesară pentru a face sarcina?
• de la 500 KIPS la 1 MIPS

În acest punct al procesului, precizia nu este esenţială; scopul este de a obţine un ordin de mărime pentru a stabili bazele numerice pentru analiza ce va urma. Figura 1 prezintă câteva dintre alternativele ce trebuie cântărite ca parte a proiectării.

Figura 1: Alternative de sistem.

Graficul arată o gamă de la 8 biţi la 32 de biţi; fiecare produs listat se află continuu într-o gamă de la o extremă la alta. Aceasta nu însemnă că funcţionarea completă a tuturor elementelor la extreme este imposibilă, ci doar însemnă că ele sunt mai uşor de implementat. De exemplu, răspunsul de timp real este listat la sfârşitul graficului pentru 8 biţi, în vreme ce RTOS este listat la sfârşitul listei pentru 32-biţi. Aceasta nu însemnă că o soluţie RTOS pentru microcontrolere pe 8 biţi este imposibilă, doar că RTOS este mai prevalentă pentru 16- şi 32 biţi, şi că amprenta memoriei necesare este proporţional mai mică în microcontrolerele pe 16 şi 32 de biţi.

Hardware sau Software?

Întrebarea, în relaţia cu perifericele digitale, este de a considera când se va crea funcţionalitate software sau hardware. Acest lucru are implicaţii importante pentru proiect. Puterea de procesare trebuie să fie în raport cu complexitatea hardware. Este de exemplu diferenţa dintre implementarea software a unui controler pentru motor pas cu pas şi un cip de controler. Selecţia va afecta viteza de procesor şi cerin­ţele de memorie program, costul sistemului, dimensiunea plăcii şi consumul posibil de curent.
Unele limitări pot fi ascunse. De exemplu, o funcţie USART poate fi integrată în software, după cum atât funcţiile de transmisie, cât şi cele de recepţie pot fi emu­late pe această cale. Problema este cu funcţia de recepţie care trebuie să aleagă continuu frontul des­cres­cător al bitului de start pentru a sincroniza exact timpul de recepţie. Aceasta însemnă o cerinţă conside­rabilă în puterea de procesare. Chiar dacă este dispo­nibilă o funcţie de întrerupere la schimbare, întârzierea subrutinei de întrerupere poate face problematică temporizarea precisă. La acest nivel cea mai bună abordare este a evita limitările ascunse şi de a nota opţiunile potenţiale şi de a cunoaşte costurile acestor opţiuni.

Răspuns de timp real sau RTOS?

Trebuie luate decizii în legătură cu modul de realizare a multi-task-urilor în proiect şi când să se utilizeze un sistem de operare de timp real (RTOS); sau este posibil să se construiască sistemul fără adresare întreţesută?
RTOS manipulează toate comutările între stări şi simplifică proiectarea software, în vreme ce un sistem cu răspuns de timp real necesită o amprentă a memo­riei mai mică şi face controlul răspunsului de timp real mai uşor de implementat. Ambele opţiuni vor avea impact asupra cerinţelor de memorie de date şi program, precum şi a puterii de procesare cerute de sistem. RTOS se împarte în două categorii de bază: preemptive şi cooperative. Ambele permit comu­tarea între sarcini multiple, dar diferă în declanşarea comutării, având impact asupra cerinţelor de diferite cantităţi de stocare şi periferice, trebuind să fie considerate ca cerinţe de sistem.

Alimentare cu mod sleep sau control dinamic al puterii?

Opţiunile sunt: un control ce prevede un consum de curent “totul sau nimic” sau un sistem mai gradual care permite oprirea anumitor secţiuni din proiect. Ambele au meritele lor; decizia va fi puternic afectată de deciziile făcute mai devreme în secţiunea Hardware/Software. Întrebarea se centrează pe analiza când o parte a sistemului trebuie lăsată în funcţiune şi curentul manipulează sarcinile sistemului; sau când să se implice un sistem hardware automat ce poate gestiona sarcini simple în vreme ce procesorul este “adormit” şi consumă mult mai puţin curent.

Design electric robust

Cu toate că într-o lume ideală toate proiectele trebuie să fie robuste electric, se poate face un compromis despre cum este atinsă această robusteţe. Această întrebare are legătură atât cu Alimentarea cât şi cu alegerea Hardware/Software.
De exemplu, o funcţie de conversie de putere poate fi realizată prin utilizarea unui design axat mai mult pe software, ce utilizează o funcţie software pentru a genera controlul de reacţie. Alternativa este de a adăuga un filtru cu buclă bazat pe un amplificator operaţional cu un simplu PWM de reacţie analogică. Ambele sisteme funcţionează şi ambele se află curent în utilizare în industrie. Diferenţele sunt acelea că sistemul bazat pe software trebuie să rămână activ, în vreme ce convertorul de putere lucrează, ceea ce poate necesita un curent de operare mai ridicat, iar în eventualitatea în care numărătorul programului în microcontroler este corupt, sistemul bazat pe hardware este neafectat de funcţia de recuperare a microcontrolerului, făcându-l mai robust din punct de vedere electric într-un mediu zgomotos.

Lanţ de semnal analogic sau calcul (DSP)?

Se examinează din nou întrebarea legată de hardware versus software, compromisul fiind aici legat de controlul sistemului şi când să fie utilizat un lanţ de semnale analogice pentru condiţionarea semnalelor de intrare şi generarea ieşirilor. Răspunsul la această ieşire are un impact semnificativ asupra alegerii microcontrolerului. În acest caz, MCU-ul trebuie să aibă cu adevărat câteva caracteristici pe cip pentru a implementa o funcţie PID sau un proiect de filtru digital. Prima cerinţă este o funcţie de multiplicare hardware care este capabilă de a păstra cerinţele sistemului pentru feedback şi control, iar a doua este un convertor analog/digital de mare viteză şi mare rezoluţie.

Tabelul 3: Exemplu de matrice de selecţie a unui microcontroler.

Controlul simplu de reacţie implementat utilizând microcontrolere fără aceste caracteristici are tendinţa să fie lent şi utilizează, tipic, aproape întreaga putere de procesare disponibilă pentru a îndeplini sarcina.
O opţiune mai simplă este de a alege un sistem analogic pentru îndeplinirea funcţiilor necesare în timp ce microcontrolerul va îndeplini rolul de supervizare. Unele funcţii vor necesita viteze mai mari, sau sunt mult mai dificil, chiar imposibil de implementat analogic, precum controlul de reacţie neliniar şi filtre IIR (Infinite Impulse Response).
În aceste cazuri, opţiunea cea mai bună este de a utiliza o soluţie software împreună cu orice circuit analogic necesar de detecţie erori.

Lumea reală sau sistem avansat?

Întrebarea finală este legată de utilizare şi când sistemul are un control automat mic cu o interfaţă limitată cu utilizatorul sau un sistem mult mai avansat cu reţea şi o interfaţă cu utilizatorul mult mai complexă. În vreme ce nu va fi necesară utilizarea unui QVGA cu un ecran tactil pentru a implementa un control de termostat casnic de 9,99 USD, o asemenea interfaţă cu utilizatorul poate fi necesară pentru un sistem mare de control al mediului într-o clădire de birouri. Răspunsul stă în ce lăţime de bandă este necesară pentru interfaţa cu utilizatorul şi când este necesară orice conectivitate.
Tendinţa estetică “Priveşte şi simte” de pe piaţă poate avea impact asupra alegerii, dar şi cerinţe mai practice pentru ope­rare de către un utilizator cu mănuşi. Toate aceste cerinţe trebuie cântărite pentru a determina complexitatea potrivită a sistemului.
Odată ce lista cerinţelor de resurse a sistemului a fost stabilită pentru a permite compromisuri acceptabile, proiectantul poate începe căutarea microcontrolerului potrivit pentru a respecta aceste cerinţe. Tabelul 3 prezintă de exemplu selectarea unui microcontroler dintr-o matrice de selecţie ce reflectă examinarea puterii de procesare, memoriei (flash şi RAM) şi mixul de periferice necesare. O potrivire exactă este improbabilă; proiectantul va trebui să reanalizeze unele compromisuri şi să facă unele alegeri dificile. Având deja evidenţiate perifericele care sunt esenţiale şi acelea care intră în categoria “bine de avut”, acest lucru se dovedeşte valoros pentru decizia finală. Este recomandată utilizarea unui microcontroler care face parte dintr-o familie cu compatibilitate superioară sau inferioară şi care furnizează opţiuni în eventualitatea că se adaugă sau se renunţă la memorie şi/sau peri­ferice pentru a aduce un plus de caracteristici sau pentru a reduce din cheltuieli.
Există un circuit şi un cost de testare pentru fiecare funcţie, iar costul fiecăreia se adaugă. Unele funcţii au un cost incremental mai mare decât altele, astfel încât la îngustarea selecţiei produsului final este bine de a se analiza încă odată lista cu “trebuie avut” vs. “bine de avut”. De asemenea costul şi complexitatea uneltelor de proiectare trebuie luate în considerare după cum aceasta va avea impact suportului, testării şi producţiei în realizarea produsului final.

Consideraţii suplimentare

Disponibilitatea unor pachete de programe pre-construite şi biblioteci de funcţii este un alt element de proiectare important de luat în considerare. Unii producători fac disponibile pachete de programe pre-construite disponibile pentru funcţii specifice, precum drivere pentru display-uri, funcţii de comu­nicaţie serială şi funcţii tactile capacitive. Aceste blocuri standard pot economisi o mulţime de timp de dezvoltare şi testare, dar aceste blocuri pot să nu fie compatibile cu proiectul. De exemplu, unele blocuri pot monopoliza unul sau mai multe peri­ferice, prevenind ca alte funcţii să le acceseze.
Pot exista cerinţe de temporizare care intră în conflict cu alte funcţii din sistem, astfel că este important să se pună întrebări specifice înainte de trecerea la utilizarea codului pre-construit.
În final, consideraţi reutilizarea codului în decizia finală, deoarece nu este niciun motiv să se reinventeze roata la fiecare nou proiect. Găsirea unui produ­cător care realizează o gamă largă de microcontro­lere, va permite reutilizarea unei părţi importante din ceea ce este dezvoltat în proiectele viitoare, ceea ce poate reduce timpul de dezvoltare şi testare.

www.microchip.com

S-ar putea să vă placă și