Proiectarea și Testarea Aplicațiilor cu Microcontrolere

1Obiectul și structura cursului6 min

Proiectele cu microcontrolere eșuează aproape întotdeauna din motive de metodă, nu de programare - rareori pentru că cineva nu a înțeles un prescaler, aproape întotdeauna pentru că nimeni nu a scris limpede ce trebuie să facă sistemul, pentru că partajarea pe module s-a făcut din mers, sau pentru că testarea a fost lăsată la sfârșit. Vom urmări întregul drum, de la cerință vagă la sistem documentat, pe un singur exemplu de referință: un sistem de udare automată pentru o seră, reluat identic în fiecare secțiune.

• Să explicați cele trei cauze principale pentru care eșuează proiectele cu microcontrolere
• Să transformați o cerință vagă într-o cerință verificabilă, cu criteriu de acceptare numeric
• Să partiționați un sistem în subsisteme cu interfețe fixate înainte de implementare
• Să descrieți logica unei aplicații ca mașină cu stări finite, pornind de la un tabel de tranziții complet
• Să distingeți nivelurile de testare (unitar, pe modul, de sistem, la limite, de robustețe) și să scrieți un plan de testare legat de caietul de sarcini
• Să aplicați cele trei principii ale depanării sistematice: caz minim reproductibil, măsoară nu ghici, separă hardware de software

2De ce eșuează un proiect: cele trei cauze11 min

Prima cauză: cerința neclară. Beneficiarul spune „vreau ca sistemul să reacționeze repede” sau „vreau să fie sigur”. Nimeni nu contrazice asemenea afirmații, pentru că nimeni nu știe ce înseamnă. La recepție, beneficiarul constată că sistemul reacționează în 300 ms și afirmă că nu este „repede”, proiectantul răspunde că nici nu s-a cerut altceva, iar discuția nu are cum să se încheie - nu există un criteriu obiectiv la care ambele părți să se raporteze. O cerință care nu poate fi verificată printr-o măsurătoare nu este o cerință, ci o dorință.

A doua cauză: delimitarea proastă a subsistemelor. Când codul crește fără o structură decisă dinainte, funcțiile încep să comunice prin variabile globale, fiecare modificând starea celeilalte. Un asemenea program funcționează, de obicei, până la prima modificare - atunci se descoperă că schimbarea unui prag impune modificări în rutina releului, care strică afișarea, iar corecția afișării reintroduce eroarea inițială. Sistemul devine imposibil de întreținut nu pentru că ar fi complex, ci pentru că nu are granițe interne.

A treia cauză, cea mai costisitoare: testarea amânată. Este tentant să scrii tot programul și abia apoi să îl încerci, pentru că testarea pe parcurs pare o pierdere de timp. În realitate, când integrezi zece module netestate și rezultatul nu funcționează, nu ai nicio informație despre locul erorii - oricare dintre cele zece, sau oricare interacțiune dintre ele, poate fi vinovat. Dacă fiecare modul a fost verificat separat și sistemul se strică la adăugarea celui de-al zecelea, spațiul de căutare s-a redus la un singur modul.

Cele două etape și ciclul dintre ele

Dezvoltarea se desfășoară în două etape mari: proiectarea, care începe cu descrierea sistemului și se încheie cu primul draft de cod, și testarea, care începe cu simularea și se încheie cu documentarea. Reprezentarea pașilor ca o listă e înșelătoare, pentru că sugerează o curgere într-un singur sens - în realitate există o buclă de reacție: dacă la testare sistemul nu se comportă conform caietului de sarcini, nu se corectează doar codul, ci se reia proiectarea de la nivelul la care s-a produs greșeala, uneori chiar caietul de sarcini însuși. Un proiect sănătos parcurge acest ciclu de mai multe ori, cu amplitudine din ce în ce mai mică.

De reținut: etapa de proiectare produce documente, nu cod. Diagramele bloc, tabelele de cerințe, tabelele de tranziții și harta pinilor rămân în urma proiectului și îi determină valoarea pe termen lung - un sistem funcțional despre care nu există niciun document este un sistem cu durată de viață egală cu memoria autorului lui.

3Exemplul de referință și caietul de sarcini13 min

Tot capitolul urmărește un singur exemplu: un sistem de udare automată pentru o seră mică. Măsoară umiditatea solului și, sub un prag, deschide o electrovalvă printr-un releu pentru un interval limitat; are un buton de udare manuală, un buton de oprire, două LED-uri de stare și transmite pe interfața serială un jurnal al evenimentelor. Din prima discuție cu beneficiarul rezultă întotdeauna un al doilea document, la fel de important ca descrierea: lista de întrebări - ce se întâmplă dacă senzorul se defectează și indică permanent sol uscat? Dacă cineva apasă simultan udarea manuală și oprirea? Dacă alimentarea cade în timpul udării? Un proiectant experimentat se recunoaște după calitatea acestei liste, pentru că fiecare întrebare pusă acum este o eroare care nu va mai fi descoperită în teren.

Ce înseamnă o cerință verificabilă

O cerință e verificabilă dacă, având sistemul în față și un aparat de măsură, două persoane independente ajung obligatoriu la aceeași concluzie despre îndeplinirea ei.

O cerință bine scrisă are patru elemente: un subiect, o acțiune observabilă, o condiție de declanșare și o valoare numerică cu unitate de măsură și toleranță. Cuvintele care trebuie să dea de gândit când apar într-un caiet de sarcini: „repede”, „stabil”, „sigur”, „prietenos”, „aproximativ” - fiecare ascunde o negociere care nu a avut loc.

Cerințele funcționale descriu ce face sistemul; sunt relativ ușor de formulat, pentru că decurg direct din descrierea beneficiarului. Cerințele nefuncționale descriu în ce condiții trebuie să facă acele lucruri, și sunt sursa majorității surprizelor târzii: consumul mediu decide dacă sistemul poate fi alimentat de la panou solar; domeniul de temperatură decide dacă oscilatorul poate fi cel intern sau trebuie cuarț; costul unitar decide între 8 și 32 KB de memorie de program. Niciuna dintre aceste cerințe nu apare în descrierea beneficiarului, dar toate schimbă proiectul dacă sunt descoperite târziu.

4Partiționarea sistemului și alegerea microcontrolerului13 min

Partiționarea înseamnă împărțirea sistemului în subsisteme, fiecare cu o responsabili- tate unică, și stabilirea modului în care comunică. Regula fundamentală: interfața unui subsistem se fixează înainte ca subsistemul să fie implementat. Motivul e practic - atât timp cât interfața nu e fixată, niciun alt subsistem nu poate fi scris, pentru că nu se știe ce va primi și ce va returna. Din momentul în care interfața e scrisă, fie și doar ca prototipuri de funcții cu comentarii, toate modulele pot fi dezvoltate în paralel.

Al doilea criteriu de partiționare bună: fiecare subsistem are un singur motiv de a se schimba. Dacă înlocuirea senzorului de umiditate cu altul obligă la modificarea codului care aprinde LED-urile, partiționarea e greșită. Sistemul de udare se împarte astfel în: achiziție umiditate, interfață operator (butoane + LED-uri), comandă valvă, bază de timp, jurnalizare serială, și, în mijloc, aplicația propriu-zisă, care ia decizii fără să atingă niciun registru.

Alegerea microcontrolerului

Alegerea nu se face după obișnuință sau după piesa din sertar, ci ca o consecință a caietului de sarcini și a partiționării: după ce se știe ce semnale intră și ies, numărul de pini e determinat; după ce se știu perioadele de lucru, se determină perifericele necesare. Abia atunci se deschide catalogul.

Un ATmega328P satisface toate liniile tabelului cu rezervă. Important: concluzia a rezultat din tabel, nu l-a precedat - dacă aplicația ar fi cerut opt canale analogice și un consum sub 100 µA, aceeași metodă ar fi condus la altă piesă. Regula practică: se păstrează o rezervă de cel puțin 20% la pini, memorie și timp de execuție - un proiect care folosește tot ce are e un proiect fără viitor, pentru care prima cerință suplimentară impune schimbarea microcontrolerului și reproiectarea cablajului.

5Arhitectura programului și mașina cu stări finite13 min

Cu subsistemele definite, urmează descrierea a ceea ce face fiecare înăuntru, prin diagrame de activități și de stări (limbajul UML). Criteriul de calitate al unei diagrame de activități e simplu și sever: din ea trebuie să se poată scrie codul direct, fără nicio decizie de proiectare suplimentară.

Buclă de scrutare sau arhitectură condusă de evenimente

În bucla de scrutare (polling), programul parcurge la nesfârșit aceeași secvență: citește toate intrările, calculează, actualizează toate ieșirile - simplă și previzibilă, dar timpul de reacție e, în cel mai rău caz, egal cu durata întregii bucle. În arhitectura condusă de evenimente, perifericele semnalează prin întreruperi momentul unui eveniment, iar bucla principală consumă fanioanele ridicate - reacție rapidă, dar apar probleme noi: partajarea variabilelor cu ISR-ul, volatile, secțiuni critice. În practică, aproape orice aplicație reală e un hibrid: întreruperile captează evenimentele rapide, iar bucla principală, ritmată de un tic al unui timer, ia deciziile.

Mașina cu stări finite

Forma naturală de organizare a logicii unei aplicații încorporate. Ideea: sistemul se află, în orice moment, într-una dintr-un număr mic de stări bine definite, iar comportamentul depinde nu doar de intrări, ci și de starea curentă - aceeași apăsare de buton înseamnă altceva când sistemul udă și altceva când așteaptă.

Tabelul trebuie să fie complet - pentru fiecare stare, toate evenimentele posibile, inclusiv cele care nu produc nicio tranziție; altfel rămân colțuri nedefinite ale comportamentului, exact locurile unde apar defectele. Traducerea în cod e mecanică:

typedef enum { ST_ASTEPTARE=0, ST_MASURARE, ST_UDARE, ST_PAUZA, ST_AVARIE } stare_t;
static stare_t stareCurenta = ST_ASTEPTARE;

void ruleazaMasinaDeStari(eveniment_t ev) {
    switch (stareCurenta) {
    case ST_ASTEPTARE:
        if (ev == EV_TIC_1S) { adcPornesteConversia(); stareCurenta = ST_MASURARE; }
        else if (ev == EV_BUTON_MANUAL) { valvaDeschide(); stareCurenta = ST_UDARE; }
        break;
    case ST_MASURARE:
        if (ev == EV_VALOARE_INVALIDA) { stareCurenta = ST_AVARIE; }
        else if (ev == EV_SUB_PRAG) { valvaDeschide(); stareCurenta = ST_UDARE; }
        else if (ev == EV_PESTE_PRAG) { stareCurenta = ST_ASTEPTARE; }
        break;
    /* ... celelalte stari, cate un caz per stare ... */
    }
}

6Activitatea principală: inițializări, buclă, butoane11 min

Diagrama de activități a programului principal descrie ce se întâmplă de la alimentare până la oprire. Începe invariabil cu inițializări: variabile, porturi cu direcțiile lor, timerul care dă baza de timp, ADC, interfața serială, apoi validarea globală a întreruperilor. Ordinea nu e indiferentă.

volatile uint8_t bTic = 0;    /* ridicat de ISR, citit de bucla principala */
ISR(TIMER1_COMPA_vect) { bTic = 1; }   /* ISR foarte scurt: doar marcheaza timpul */

int main(void) {
    valvaInchide();            /* stare sigura INAINTE de a configura iesirea */
    porturiInit();
    timerInit();                /* intrerupere la fiecare 10 ms */
    adcInit(); serialInit(9600);
    parametriIncarcaDinEeprom();
    sei();
    for (;;) {
        if (bTic) {
            cli(); bTic = 0; sei();   /* stergere protejata: ISR poate scrie oricand */
            eveniment_t ev = colecteazaEveniment();
            ruleazaMasinaDeStari(ev);
            cronometruTic();
            jurnalTrimiteUnCaracter();
        }
    }
}

Se observă că bucla nu conține nicio întârziere activă și nicio operație lungă - tot ce durează mult, precum transmisia jurnalului, e fragmentat sau lăsat pe seama întreruperilor.

Citirea butoanelor prin tranziție, nu prin nivel

Un buton nu se citește ca nivel, ci ca tranziție: sistemul trebuie să reacționeze la momentul apăsării, nu la faptul că e ținut apăsat. Metoda standard: se păstrează valoarea citită anterior a portului și se compară cu cea curentă; dacă diferă, s-a produs o schimbare, iar biții modificați arată care buton a fost acționat. Aceeași metodă rezolvă apăsarea simultană a mai multor butoane, pentru că valoarea întregului port se interpretează ca un cod, iar codurile nepermise se pot trata explicit - dacă utilizatorul apasă simultan oprirea și udarea manuală, programul poate decide explicit că oprirea are prioritate, decizie care trebuie să figureze în caietul de sarcini, nu lăsată la voia ordinii instrucțiunilor.

7Scrierea și testarea primară a codului11 min

Cu diagramele finalizate, scrierea codului devine în bună măsură transcriere. Regula esențială a acestei etape: nu se scrie tot programul deodată. Codul se dezvoltă pe straturi, de jos în sus - mai întâi se verifică frecvența reală a microcontrolerului (comutând un pin într-o buclă, măsurat cu osciloscopul), apoi ieșirea cu un LED, apoi intrarea cu un buton, apoi ADC-ul cu un potențiometru, apoi timerul, și abia la sfârșit se aduc împreună.

De ce nu se testează direct pe instalația reală

Două motive. Primul: o eroare de software poate distruge hardware scump - o comandă simultană a două brațe ale unei punți în H scurtcircuitează sursa, o valvă lăsată deschisă inundă sera. Al doilea, mai puțin evident: instalația reală nu poate fi adusă la comandă în situațiile care contează - nu poți face solul uscat în cinci secunde ca să verifici pragul, nu poți repeta de o sută de ori o cădere de tensiune.

Soluția e un modul de simulare ieftin, care imită interfața electrică a instalației: intrări digitale de la butoane, intrări analogice de la potențiometre, ieșiri pe LED-uri - pentru sistemul de udare, un potențiometru în locul senzorului, trei butoane, trei LED-uri. Costul e de câțiva lei; câștigul e posibilitatea de a produce oricând orice combinație de intrări, inclusiv cele imposibile fizic, care sunt cele mai interesante pentru testare.

Cod ușor de testat

Se poate scrie cod care se lasă testat și cod care nu se lasă - diferența stă în separarea deciziei de accesul la periferice. O funcție care citește singură ADC-ul și scrie singură în portul releului nu poate fi verificată decât cu hardware. Aceeași logică, scrisă ca funcție pură care primește valoarea măsurată și returnează decizia, poate fi compilată și rulată pe calculator, cu mii de combinații, în câteva secunde.

/* histerezis: latimea zonei moarte, in aceleasi unitati ca umiditatea si pragul */
uint8_t decideUdarea(uint16_t umiditate, uint16_t prag,
                      uint16_t histerezis, uint8_t udaAcum) {
    if (udaAcum) return (umiditate < prag + histerezis) ? 1 : 0;
    return (umiditate < prag) ? 1 : 0;
}

8Planul de testare și nivelurile lui11 min

După ce modulul de încercare e gata, se scrie planul de testare - nu o listă de lucruri încercate „când vine în minte”, ci un document derivat din caietul de sarcini, în care fiecare cerință are cel puțin un test asociat și fiecare test are un criteriu de acceptare numeric. Legătura se face prin codurile cerințelor, astfel încât la sfârșit să se poată demonstra că nicio cerință n-a rămas neverificată.

Nivelurile de testare

Testele unitare se aplică funcțiilor pur logice, care nu ating periferice: conversia ADC în procente, medierea, decizia de udare. Se compilează pentru calculatorul gazdă și rulează automat, deci pot fi repetate la fiecare modificare a codului, cu efort nul. Un test unitar bun include valorile de la limitele domeniului.

assert(decideUdarea(300, 400, 50, 0) == 1);  /* sub prag, inchisa: porneste */
assert(decideUdarea(500, 400, 50, 0) == 0);  /* peste prag: nu porneste */
assert(decideUdarea(400, 400, 50, 0) == 0);  /* exact pe prag: comparatia e stricta */
assert(decideUdarea(430, 400, 50, 1) == 1);  /* in zona de histerezis: ramane deschisa */

Testele pe modul verifică un subsistem întreg, cu hardware simulat - se aplică o tensiune cunoscută și se compară valoarea afișată cu cea măsurată cu voltmetrul, verificând nu doar logica, ci și configurarea perifericului (referință, prescalare, aliniere). Testele de sistem verifică ansamblul prin scenarii de folosire reală, cronometrate și comparate cu limitele din caietul de sarcini. Testele la limite exercitează valorile extreme - un contor de milisecunde pe 16 biți se rotește după ~65 s, iar o comparație scrisă neatent dă un rezultat greșit exact atunci; testul trebuie să existe în plan, altfel defectul apare la beneficiar. Testele de robustețe verifică situații nedorite: deconectarea senzorului, alimentare instabilă, resetare în timpul udării, apăsare simultană a butoanelor. Criteriul nu e ca sistemul să facă ceva util, ci să nu facă ceva periculos.

9Depanarea sistematică9 min

Oricât de bine organizat un proiect, vor exista defecte, iar modul în care sunt căutate face diferența între o oră și o săptămână. Depanarea nu e o activitate de inspirație, ci o procedură cu trei principii.

Primul: reducerea la un caz minim reproductibil. Un defect care apare „uneori, după vreo jumătate de oră” nu poate fi studiat. Trebuie găsită cea mai scurtă secvență de acțiuni care îl provoacă de fiecare dată, apoi eliminată, una câte una, orice parte a sistemului care nu e necesară pentru reproducere - deconectăm afișajul: mai apare? Oprim jurnalul serial: mai apare? De cele mai multe ori defectul se lămurește singur în timpul acestei reduceri, pentru că partea eliminată la care defectul dispare arată direct cauza.

Al doilea: măsoară, nu ghici. Majoritatea ipotezelor plauzibile sunt false, iar verificarea lor costă adesea mai puțin decât discuția despre ele. Dacă bănuiți că o întrerupere nu se declanșează, comutați un pin în ISR și priviți-l cu osciloscopul - în trei minute aveți un răspuns sigur.

#define PIN_TEST_SUS (PORTD |= (1<