Programarea unui Microcontroler

1Obiectul și structura cursului7 min

A programa un microcontroler înseamnă, la nivelul cel mai concret, a modifica starea unor celule de memorie nevolatilă aflate în interiorul cipului, astfel încât, la următoarea alimentare, unitatea centrală să găsească acolo o secvență de instrucțiuni pe care le poate executa. Nimic mai mult. Microcontrolerul nu „înțelege" C, nu știe ce e o funcție și nu are noțiunea de fișier - are un numărător de program care indică o adresă în Flash, citește de acolo un cuvânt de 16 biți, îl interpretează ca instrucțiune, o execută și trece mai departe.

A doua diferență ține de locul unde se lucrează. Programul e scris, compilat și transformat pe un calculator gazdă, cu altă arhitectură decât ținta. Un compilator care rulează pe x86 și produce cod pentru un AVR pe 8 biți se numește compilator încrucișat (cross-compiler), iar ansamblul uneltelor care îl însoțesc formează un lanț de unelte (toolchain) - pentru AVR, acesta se numește avr-gcc.

• Să enumerați, în ordine, cele cinci transformări prin care trece codul sursă până la biți în Flash, cu unealta și fișierul rezultat pentru fiecare
• Să explicați de ce fișierul .elf nu poate fi trimis direct programatorului
• Să citiți o linie de fișier Intel HEX și să verificați suma ei de control
• Să comparați programarea prin bootloader cu cea prin ISP, ca hardware necesar și spațiu consumat
• Să estimați ocuparea memoriei Flash și SRAM a unui program și să recunoașteți simptomele epuizării fiecăreia
• Să identificați cauza reală a unui program care „merge de două ori mai încet" sau se resetează singur

2Etapele programării: de la sursă la ELF12 min

Un mediu integrat afișează o singură comandă, „Compilează" sau „Încarcă". În spate se execută, în ordine, cinci transformări succesive, fiecare producând un fișier intermediar cu un rol precis. Mediile integrate șterg fișierele intermediare la sfârșit - ceea ce nu înseamnă că nu au existat, ci doar că studentul nu are ocazia să le vadă.

1. Preprocesarea

Prima unealtă care atinge codul sursă nu e compilatorul, ci preprocesorul - el nu cunoaște C, pentru el fișierul e doar text. Execută directivele care încep cu diez (#include, #define, #ifdef) și livrează compilatorului un text din care acestea au dispărut. Explică de ce un program de cincisprezece linii ajunge, după preprocesare, la zeci de mii de linii: antetul <avr/io.h> trage după el fișierul specific dispozitivului, cu definițiile tuturor registrelor și biților lor. Când scriem PORTB, preprocesorul îl înlocuiește cu adresa fizică a registrului; compilatorul nu vede niciodată numele, ci doar accesul la o adresă.

2. Compilarea propriu-zisă

Compilatorul primește textul preprocesat și produce asamblare pentru arhitectura țintă. Aici se pierde definitiv structura de nivel înalt: buclele, funcțiile, tipurile de date devin instrucțiuni AVR, iar variabilele sunt repartizate în cele 32 de registre generale sau, dacă nu încap, în SRAM.

3. Asamblarea

Asamblorul traduce unu-la-unu mnemonicele în cod mașină binar - nicio decizie de optimizare, doar corespondență fixă. Rezultatul, fișierul .o, nu e cod executabil: e organizat pe secțiuni (.text pentru instrucțiuni, .data pentru variabile globale inițializate nenul, .bss pentru cele inițializate cu zero, .rodata pentru constante) și e incomplet - dacă apelează o funcție din alt fișier, asamblorul nu-i cunoaște adresa și lasă un gol, notat în tabela de relocări.

4. Editarea de legături

Linker-ul primește toate fișierele obiect și bibliotecile, cu trei sarcini: rezolvarea simbolurilor (caută definiția fiecărui nume nedefinit local - de aici erorile „undefined reference" și „multiple definition"), alocarea adreselor (concatenează secțiunile de același fel și le așază în spațiul de adrese, conform unui script de legare - pentru ATmega328P, .text începe la adresa 0 din Flash, .data/.bss în SRAM) și relocarea (completează golurile lăsate de asamblor, acum că adresele sunt cunoscute).

Rezultatul e un fișier executabil ELF - conține codul relocat complet, plus informația de depanare (nume de simboluri, corespondența adrese-linii, tipuri de variabile), esențială pentru orice depanator și motiv pentru care fișierul .elf nu trebuie aruncat.

3De la ELF la memoria Flash9 min

Un programator de circuite nu are nevoie de simboluri sau informație de depanare - are nevoie de un răspuns la o singură întrebare: ce octet se scrie la ce adresă. Din ELF se extrag doar secțiunile care ajung efectiv în Flash (.text și imaginea inițială a lui .data) și se transcriu în formatul Intel HEX, cu utilitarul avr-objcopy.

Transferul în memorie

Ultima etapă e singura care implică hardware. Un program de pe calculatorul gazdă (avrdude - AVR Downloader Uploader) citește fișierul .hex, îl împarte în pagini și le trimite, printr-un protocol serial, către logica de scriere din Flash-ul microcontrolerului.

După scriere se recomandă verificarea: programatorul recitește conținutul și îl compară cu sursa. O nepotrivire indică alimentare insuficientă, frecvență de programare prea mare, sau memorie uzată.

4Formatul fișierului Intel HEX10 min

Fișierul .hex e ultimul obiect pe care îl poate inspecta un om înainte ca programul să dispară în cip - și singurul din lanț suficient de simplu pentru a fi citit cu ochiul liber. Formatul, definit în anii 1970 pentru transferul prin legături seriale lente și nesigure, e text ASCII pur, fiecare linie e autonomă și poartă propria adresă, iar fiecare linie are o sumă de control.

5Structura memoriei Flash și bootloader-ul10 min

Cine scrie în Flash? Memoria e internă cipului, iar terminalele lui nu expun magistrala de memorie direct. Există două răspunsuri: ori un dispozitiv extern preia controlul cipului printr-o interfață serială dedicată, ori microcontrolerul se programează singur, executând un program deja prezent în el, folosind instrucțiunea spm (store program memory), care scrie o pagină în Flash. Programul care face asta se numește bootloader.

Cele două secțiuni ale memoriei Flash

Pentru siguranță, Flash-ul lui ATmega328P e împărțit în secțiunea de aplicație (partea de jos, de la adresa zero, programul utilizatorului) și secțiunea de pornire (partea de sus, bootloader-ul). Distincția e impusă hardware: instrucțiunea spm are efect numai când PC-ul se află în secțiunea de pornire - un program de aplicație obișnuit nu poate rescrie Flash-ul nici din greșeală, nici intenționat.

La resetare, bootloader-ul inițializează interfața de comunicație și așteaptă câteva sute de milisecunde un mesaj de sincronizare. Dacă sosește, primește pagini de cod, le scrie cu spm și sare la adresa zero. Dacă nu sosește, sare direct la aplicație - explicația secundei de întârziere observată la alimentarea unei plăci Arduino.

6Programarea modulelor Arduino8 min

Pe o placă Arduino Uno, pe lângă ATmega328P, un al doilea circuit se ocupă de conversia USB-serial - calculatorul gazdă îl vede ca pe un port serial virtual, ale cărui linii de transmisie/recepție sunt legate la terminalele RXD/TXD ale microcontrolerului principal. Acest circuit doar transportă octeți, nu programează nimic.

Resetarea automată

Bootloader-ul ascultă doar imediat după resetare. Pe plăcile vechi, utilizatorul trebuia să apese resetarea exact la momentul potrivit. Soluția actuală: linia DTR a portului serial virtual e legată la terminalul de resetare printr-un condensator mic. Când programul de pe calculator deschide portul, comută DTR, iar condensatorul transmite doar frontul, generând un impuls scurt de resetare - placa se resetează singură exact la momentul potrivit.

avrdude -C avrdude.conf -p atmega328p -c arduino \
        -P /dev/ttyUSB0 -b 115200 -D \
        -U flash:w:prog.hex:i

Protocolul de dialog se numește STK500: gazda cere sincronizarea, întreabă semnătura cipului, trimite adresa și conținutul fiecărei pagini, cere scrierea, trece la pagina următoare. Bootloader-ul Optiboot implementează doar un subset, suficient pentru scrierea în Flash - nu poate scrie siguranțele sau citi EEPROM, tocmai pentru a rămâne în cei 512 octeți alocați.

7Programarea prin ISP9 min

Programarea în sistem (ISP - In-System Programming, sau ICSP) e modalitatea de bază, care nu depinde de niciun cod deja prezent în microcontroler. Folosește interfața serială sincronă SPI a cipului, într-un regim special activat prin menținerea terminalului de resetare în stare activă - cât timp cipul e ținut în resetare, unitatea centrală nu execută nimic, iar logica de programare preia controlul prin MOSI/MISO/SCK.

Dialogul: activare programare, citirea semnăturii cipului (trei octeți: fabricant și model), ștergere, încărcarea paginilor, verificare.

8Limbaje de programare și costul bibliotecilor11 min

Un microcontroler poate fi programat, în principiu, în orice limbaj cu compilator pentru arhitectura respectivă. În practică, alegerea e restrânsă de resursă: cu 32 KB de Flash și 2 KB de SRAM, nu există loc pentru o mașină virtuală, un colector de gunoaie sau o bibliotecă standard bogată.

Asamblare, C, C++

Asamblarea dă codul cel mai compact și cel mai rapid posibil, cu consum de resurse perfect cunoscut - esențial în bucle cu termen strict sau întreruperi cu timp garantat. Devine însă greu de citit și neportabilă dincolo de câteva zeci de linii; astăzi se folosește punctual, în rutine scurte și critice.

C ocupă poziția dominantă, din motive de fond: tipurile corespund unităților naturale ale procesorului, operatorii pe biți permit manipularea directă a registrelor, pointerii permit accesul la adrese fizice. Un compilator bun generează, pentru cod scris cu grijă, un rezultat comparabil cu asamblarea scrisă de om. Prețul: o curbă de învățare abruptă și nicio plasă de siguranță - C permite fără să protesteze scrierea în afara unui tablou sau un pointer neinițializat.

C++ adaugă clase și încapsulare - bibliotecile Arduino (Serial, Servo) beneficiază vizibil. Costul: alocarea dinamică, tratarea excepțiilor și identificarea tipurilor la execuție consumă memorie pe care 2 KB de SRAM n-o pot susține, de aceea practica embedded folosește un subset disciplinat, fără aceste mecanisme.

Ce ascund bibliotecile Arduino

Mediul Arduino ascunde registrele în spatele unor funcții cu nume citibile - alegere pedagogică bună la început, costisitoare mai târziu.

/* varianta cu functii Arduino */
void setup() { pinMode(13, OUTPUT); }
void loop() { digitalWrite(13, HIGH); digitalWrite(13, LOW); }

/* aceeasi operatie, direct in registre */
#include <avr/io.h>
int main(void) {
    DDRB |= (1 << PB5);
    while (1) {
        PORTB |= (1 << PB5);
        PORTB &= ~(1 << PB5);
    }
}

Diferența de comportament e nulă - pe placa Uno, pinul 13 e chiar PB5. Diferența de cost e mare: PORTB |= (1<<PB5) generează instrucțiunea sbi, doi cicluri. digitalWrite(13, HIGH) traduce numărul de pin în port și bit citind două tabele din Flash, verifică dacă pinul e atașat unui canal PWM și, dacă da, îl detașează, dezactivează întreruperile, modifică registrul și le reactivează - zeci de cicluri, în loc de două.

9Depanarea unui microcontroler9 min

Depanarea unui microcontroler e structural mai grea decât pe un calculator: nu are ecran, consolă sau sistem de fișiere pentru un jurnal; interacționează cu lumea fizică în timp real (un motor nu se oprește pentru un punct de întrerupere); multe defecte sunt la granița cod-hardware (un fir prost lipit, o alimentare care cade), invizibile unui depanator software; iar resursele necesare depanării - memorie de program, pini - sunt exact resursele care lipsesc.

Depanare la nivel hardware

Pentru AVR-urile mici, mecanismul se numește debugWIRE - folosește un singur fir, chiar terminalul de resetare, transformat într-o legătură bidirecțională de comandă: oprește procesorul, citește/scrie registre și memorie, execută pas cu pas, fixează puncte de întrerupere.

JTAG (patru-cinci terminale, pe AVR mari și pe majoritatea ARM) și SWD (varianta redusă la două terminale, specifică ARM) oferă aceleași funcții de bază - puncte de întrerupere, execuție pas cu pas, inspecția variabilelor și a stivei - funcționând pentru că dispozitivul de depanare citește fișierul .elf și știe ce adresă corespunde cărei linii de cod.

De ce mesajele pe serială rămân unealta principală

Nu cere hardware suplimentar (legătura există deja, aceeași cu cea de încărcare), nu oprește execuția (sistemul continuă să funcționeze în timp ce raportează), permite observarea evoluției în timp - o valoare care derivează lent se vede într-un jurnal, nu într-o oprire.

10Flash plin, SRAM epuizată: bugetul de memorie11 min

Memoria Flash plină

Cea mai simplă eroare, semnalată clar de mediul de dezvoltare. Cauza obișnuită nu e codul scris de student, ci bibliotecile incluse - o bibliotecă grafică, de comunicație în rețea, sau folosirea aritmeticii în virgulă mobilă pot adăuga fiecare mii de octeți. Din cei 32768 de octeți, bootloader-ul consumă deja 512.

Soluții, în ordinea efortului: eliminarea bibliotecilor neutilizate, renunțarea la virgula mobilă unde întregii sunt suficienți, mutarea tabelelor constante în Flash cu PROGMEM, și, în ultimă instanță, eliminarea bootloader-ului și programarea prin ISP.

Memoria SRAM epuizată

Mult mai insidioasă - nu produce niciun mesaj. Programul se compilează, se încarcă, pornește, funcționează un timp, apoi dă rezultate absurde sau se resetează singur.

/* consuma SRAM */
Serial.println("Temperatura masurata: ");
/* pastreaza sirul in Flash */
Serial.println(F("Temperatura masurata: "));

11Ceasul și alte confuzii7 min

Ceasul configurat altfel decât presupune codul

Se manifestă prin întârzieri greșite și comunicație serială ilizibilă. Codul nu măsoară timpul, numără cicluri: _delay_ms calculează numărul de iterații pornind de la macroul F_CPU, definit la compilare; din același F_CPU se calculează și divizorul de viteză al interfeței seriale.

Alte confuzii frecvente

Un tip de placă greșit selectat duce la viteză de comunicație greșită cu bootloader-ul. Portul serial ocupat de altă aplicație face încărcarea să eșueze fără explicație clară. Un pin folosit simultan de aplicație și de interfața ISP (PB3, PB4, PB5) poate împiedica programarea dacă circuitul extern încarcă prea mult liniile. Omiterea volatile la variabile partajate cu întreruperi produce un program care funcționează la optimizare zero și se blochează la nivelul implicit - sugerând, greșit, o eroare de compilator.

12Erori frecvente4 min

• „Programul s-a compilat fără erori, deci este corect." Compilarea verifică doar sintaxa și tipurile. Un program care încape în Flash, dar epuizează SRAM la execuție, se compilează impecabil și se comportă aleatoriu pe placă. Citiți raportul de memorie afișat la sfârșitul compilării, nu doar linia „Done compiling", și urmăriți procentul de SRAM ocupat de variabilele globale.
• „Am modificat codul, dar placa se comportă la fel - probabil e o problemă de hardware." Cel mai adesea încărcarea nu a avut loc: portul selectat e greșit, placa aleasă în meniu nu corespunde, sau transferul a eșuat, iar în Flash a rămas programul anterior. Verificați mesajul de la sfârșitul încărcării (numărul de octeți scriși și verificați) înainte de a bănui hardware-ul.
• „Pot copia fișierul .elf direct pe microcontroler, e doar un executabil." Fals - ELF conține adrese, secțiuni și informație de depanare pe care programatorul nu le poate interpreta; microcontrolerul nu are sistem de fișiere și nici încărcător. Programatorului i se trimite fișierul Intel HEX, obținut prin conversie cu avr-objcopy; .elf se păstrează doar pentru depanare.
• „Am setat F_CPU în cod, deci microcontrolerul va rula la frecvența aceea." F_CPU nu comandă nimic în hardware - e doar o constantă folosită de compilator pentru a calcula bucle de întârziere. Frecvența reală vine din oscilator și din biții de configurare. Potriviți F_CPU cu oscilatorul real; dacă întârzierile ies de două ori mai lungi sau mai scurte, acolo e cauza, nu în cod.

13Rezumat și glosar5 min

A programa înseamnă a scrie într-o memorie nevolatilă la adrese fizice exacte, nu a instala un fișier. Lanțul de transformare merge din codul sursă prin preprocesare, compilare, asamblare și editare de legături până la un executabil ELF, apoi prin conversie la formatul textual Intel HEX, scris pe pagini în Flash de avrdude. Flash-ul lui ATmega328P se împarte în secțiunea de aplicație și secțiunea de pornire, unde locuiește bootloader-ul - un program care se scrie singur, prin spm, activat doar în zona lui, cu prețul a 512 octeți și al unei întârzieri la pornire. ISP e alternativa universală, care nu depinde de niciun cod prezent în cip și are acces la siguranțe. C domină programarea microcontrolerelor pentru apropierea lui de mașină; bibliotecile Arduino tranzacționează viteză și memorie pentru lizibilitate. Depanarea e structural mai grea decât pe un calculator - mesajele pe serială rămân unealta principală, iar cele mai insidioase defecte (SRAM epuizată, ceas nepotrivit) nu produc niciun mesaj de eroare.

14Întrebări de verificare7 min

1. Descrieți, în ordine, transformările prin care trece un fișier sursă C până la înscrierea codului în Flash, precizând unealta și fișierul rezultat pentru fiecare etapă.
2. Explicați de ce fișierul .elf nu poate fi transmis direct programatorului și ce informație se pierde la conversia în Intel HEX.
3. Care sunt cele trei sarcini ale editorului de legături? Ce înseamnă relocarea?
4. De ce un program obișnuit de aplicație nu poate scrie în propria memorie Flash, și ce condiție hardware trebuie îndeplinită pentru ca spm să aibă efect?
5. Comparați programarea prin bootloader cu ISP din punctul de vedere al hardware-ului necesar, al spațiului consumat și al accesului la biții de configurare.
6. Explicați mecanismul prin care o placă Arduino se resetează singură la începutul încărcării, și legați-l de faptul că deschiderea monitorului serial repornește programul.
7. Un program folosește douăzeci de mesaje constante de câte patruzeci de caractere. Estimați consumul de SRAM și explicați cum îl reduce macroul F().

15Direcții de aprofundare2 min

Cursul următor coboară de la lanțul de unelte la periferia cea mai simplă și mai folosită a unui microcontroler: porturile de intrare-ieșire - configurarea lor pe biți, citirea și scrierea directă prin registre, și capcanele electrice ale unui pin digital (flotant, pull-up, multiplexare).