Show page

Differences

This shows you the differences between two versions of the page.

--- pm:lab:lab1-2023 [2024/03/11 11:12]
dan.tudose [2. Instrumente necesare]
+++ pm:lab:lab1-2023 [2025/03/11 19:32] (current)
cezar.zlatea [4. Exerciții]
@@ Line 3: / Line 3: @@
 Ca în toate lucrările de inginerie, bug-uri pot și vor apărea si în sisteme incorporate. În condiții de funcționare, este important să avem o modalitate de comunicare cu dispozitivul integrat. Pentru o imagine de ansamblu asupra metodelor de depanare posibile, vom face o scurtă introducere, apoi vom studia în detaliu interfața serială USART, folosită în mod uzual pentru comunicația serială dintre două dispozitive.
-===== 1. Ce este diferit fata de depanarea software uzuala? =====
+===== 1. Ce este diferit față de depanarea software uzuală? =====
 Motivul pentru care depanarea embedded este mai dificilă decât depanarea obișnuită a software-ului provine din mai multe probleme:
-  * Sistemele embedded sunt mult mai complicat de depanat deoarece produsele dedicate debugging-ului hardware (Software, IDE, Lauterbach, etc) sunt mult mai scumpe si greu de folosit decat depanarea software.
+  * Sistemele embedded sunt mult mai complicat de depanat deoarece produsele dedicate debugging-ului hardware (Software, IDE, Lauterbach, etc) sunt mult mai scumpe și greu de folosit decât depanarea software.
-  * Folosirea unui debugger generic (ex. Remote GDB) vine la pachet cu o serie de probleme ce pot aparea. Debuggerele generice necesita o stiva de retea conforma cu hardware-ul folosit. Chiar daca am implementa o astfel de stiva , nu putem fii siguri ca aceasta functioneaza perfect si ar necesita foarte mult timp.
+  * Folosirea unui debugger generic (ex. Remote GDB) vine la pachet cu o serie de probleme ce pot apărea. Debuggerele generice necesită o stivă de rețea sau protocoale conformă cu hardware-ul folosit. Chiar dacă am implementa o astfel de stivă, nu putem fi siguri că aceasta funcționează perfect.
   * Chiar dacă ați avut un debugger specializat (de exemplu, o sondă Lauterbach), cel mai probabil veți avea nevoie de configurații specializate pentru debugger, pentru a lucra cu hardware-ul vostru (de exemplu, Practice Scripting Language for Lauterbach T32)
   * Depanarea invazivă poate afecta comportamentul codului vostru - gândiți-vă la RTOS (sisteme de operare în timp real), SMP (sisteme multiprocesor) sau la circuitul dvs. (de exemplu, modificați circuitul pentru a măsura intensitatea curentului).
-  * Hardware-ul in fazele incipiente pot avea erori de proiectare ceea ce influenteaza procesul de debug.
+  * Hardware-ul în fazele incipiente poate avea erori de proiectare, ceea ce influențează procesul de debug.
   * Chiar și tipărirea mesajelor de eroare ar putea să nu funcționeze, deoarece uneori trebuie să implementați o astfel de funcție și ar putea avea bug-uri în sine.
-Cu toate acestea, principiile de debugging sunt aceleasi ca si în cazul software-ul de nivel înalt: Trebuie sa comparați ce se dorește de la sistem (cod / circuit) cu ceea ce, de fapt, face si, pentru asta, ai nevoie de vizibilitate.
+Cu toate acestea, principiile de debugging sunt aceleași ca și în cazul software-ul de nivel înalt: trebuie să comparați ce se dorește de la sistem (cod / circuit) cu ceea ce sistemul face de fapt.
 ===== 2. Instrumente necesare =====
-Vizibilitatea la nivel hardware se realizează printr-o formă de InputOutput (dacă este disponibilă):
+Vizibilitatea la nivel hardware se realizează printr-o formă de Input/Output (dacă este disponibilă):
-  * Depanare LED - verificarea stării true/false
+  * Depanare cu LED-uri - verificarea stării true/false
-  * **mesaje pe interfața serială / USART - depanare prin USART, bluetooth, etc**
+  * **mesaje pe interfața serială / USART - depanare prin USART, Bluetooth, etc.**
-  * Debuggere avansate pentru afisarea si modificarea memoriei / registrelor (a se vedea JTAG de mai jos)
+  * Debuggere avansate pentru afișarea și modificarea memoriei/registrelor (a se vedea JTAG de mai jos)
-  * Loopbacking (conectarea ieșirilor la intrări) poate oferi informații despre modul în care comenzile sunt trimise  dispozitivelor externe.
+  * Loopback-ing (conectarea ieșirilor la intrări) poate oferi informații despre modul în care comenzile sunt trimise  dispozitivelor externe.
 Instrumente de măsură:
@@ Line 32: / Line 32: @@
     * Curent: Conectați multimetrul în serie cu circuitul pe care doriți să-l verificați.. Trebuie să plasați sonda roșie pe cablul unei componente și sonda neagră pe următorul conductor. Multimetrul acționează ca și cum ar fi fost un fir în circuitul tău. Dacă deconectați multimetrul, circuitul nu va funcționa.
     * Începeți întotdeauna prin a seta scara multimetrului la maxim, apoi corectați progresiv scara până când aveți cea mai precisă măsurare.
-    * Pentru a verifica polaritatea diodelor: Selectați verificare diodă. Daca plasați sonda negativă pe anod și sonda pozitivă pe catod, multimetrul va face un sunet.
+    * Pentru a verifica polaritatea diodelor: Selectați verificare diodă. Daca plasați sonda negativă pe anod și sonda pozitivă pe catod, multimetrul va face un sunet sau va arăta o cădere de tensiune de pe joncțiunea p-n.
     * Pentru a verifica scurtcircuite/conectivitate: utilizați modul buzzer dacă acesta este prezent ca setare în modul măsurare rezistență – dacă aparatul emite un sunet atunci înseamnă că există un scurtcircuit/conexiune între acele două puncte.
@@ Line 47: / Line 47: @@
 Un exemplu de flux de depanare ar putea fi următorul:
-  * Verificați de două ori datasheet-ul și schema. Verificati daca accesati registrele potrivite. O alta probleme poate fi conectarea gresita dintre periferice si pini.
+  * Verificați de două ori datasheet-ul și schema. Verificati daca accesați registrele potrivite. O altă problemă poate fi conectarea greșită dintre periferice și pini.
-  * In prima faza verificam daca este posibila depanarea folosind mesaje de debug.
+  * În primă fază verificăm dacă este posibilă depanarea folosind mesaje de debug și/sau mesaje pe interfața serială.
-  * Daca ai o stiva ethernet poti lua in considerare folosirea SSH, NFS, etc pentru a folosi depanarea prin mesaje.
+  * Dacă există o stivă ethernet funcțională pe dispozitiv, poți lua în considerare folosirea SSH, NFS, etc pentru a folosi depanarea prin mesaje.
-  * In cazul in care avem o stiva de retea, verificam daca avem acces la protocoale mai simple precum UART. Testam conectand prin UART un periferic de exemplu un PC, modul Bluetooth, LCD, etc.
+  * În cazul în care nu avem o stivă de rețea, verificăm dacă avem acces la protocoale mai simple precum UART. Testăm conectând prin UART un periferic, de exemplu un PC, modul Bluetooth, LCD, etc.
-  * De asemenea in anumite cazuri de probleme hardware, putem folosi si depanarea prin LED-uri.
+  * În cazuri extreme sau pentru programe foarte simple, atunci când nu avem la dispoziție nimic din ce este enumerat mai sus, putem folosi și depanarea prin LED-uri.
   * Izolați problema folosind instrumente de măsura: multimetre, osciloscoape, analizoare logice.
-  * In cazul in care stim ca dispozitivul nostru este compatibil cu debuggere hardware (JTAG, Lauterbach, etc.) folosirea lor este de multe ori cea mai eficienta metoda de debug.
+  * În cazul în care știm că dispozitivul nostru este compatibil cu debuggere hardware (JTAG, Lauterbach, etc.) folosirea lor este de multe ori cea mai eficientă metodă de debug.
 ===== 3. Interfața serială USART =====
@@ Line 77: / Line 77: @@
 <note warning>Pentru ca două dispozitive, în cazul nostru PC-ul și placa de laborator, să poată comunica între ele prin USART în mod asincron, trebuie configurate **identic**. Dacă placa este configurată cu baud rate 115200, 9 biți de date, 1 bit de stop și fără paritate atunci PC-ul trebuie configurat **exact la fel** pentru a comunica.</note>
+<note tip> **Video explicativ** (~10 min): [[https://www.ti.com/video/6313217959112|UART protocol and error overview]] </note>
 ==== 3.1 Registre ====
@@ Line 139: / Line 141: @@
 {{ .:lab1:ubrr.png?nolink |Registrul UBRRn}}
-''UBRRn'' este registrul care selectează **baud rate**-ul. Are 12 biți. Primii 4 se află în ''UBRRnH'', ceilalți 8 în ''UBRRnL''. Valoarea pe care o scriem în ''UBRRn'' depinde de frecvența procesorului și de baud rate-ul dorit. Tabelul de mai jos este folosit pentru clock-uri de 8Mhz, 11.0592MHz si 14.7456MHz, in cazul placii noastre, clock-ul este de 12MHz , putem cauta valoarea pentru baud rate [[https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html|aici]], sau o putem calcula folosind formula: (F_CPU/(UART_BAUD_RATE*16)-1)
+''UBRRn'' este registrul care selectează **baud rate**-ul și are 12 biți. Primii 4 se află în ''UBRRnH'', ceilalți 8 în ''UBRRnL''. Valoarea pe care o scriem în ''UBRRn'' depinde de frecvența procesorului și de baud rate-ul dorit.
-Unde F_Cpu este frecventa clock-ului, UART_BAUD_RATE este ales de noi (ex. 4800, 9600, 14400).
+Tabelul de mai jos este folosit pentru ceasuri de 8Mhz, 11.0592MHz și 14.7456MHz. În cazul plăcii noastre, ceasul este de 12MHz și putem căuta valoarea pentru baud rate [[https://cache.amobbs.com/bbs_upload782111/files_22/ourdev_508497.html|aici]], sau o putem calcula folosind formula: **(F_CPU/(UART_BAUD_RATE*16)-1)**, unde F_CPU este frecvența de ceas iar UART_BAUD_RATE este ales de noi (ex. 4800, 9600, 14400).
 {{ pm:lab:brate324.png?nolink |Tabel baud rate}}
@@ Line 146: / Line 149: @@
 <note important>Este de dorit alegerea unui baud rate care să poată fi obținut exact din frecvența de ceas. În caz contrar se definește o toleranță (eroarea maximă a baud rate-ului) pentru care comunicația se poate realiza în condiții acceptabile. Dacă doriți să aprofundați subiectul, găsiți multe informații [[https://www.allaboutcircuits.com/technical-articles/the-uart-baud-rate-clock-how-accurate-does-it-need-to-be/|aici]]</note>
-<note important>Pentru a seta baud rate-ul exista si libraria util/setbaud.h care este menita sa simplifice procesul. Este nevoie sa setati frecventa ceasului procesorului. Gasiti [[https://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html|aici]] mai multe detaii despre aceasta si exemple de utilizare.</note>
+<note important>Pentru a seta baud rate-ul există și biblioteca util/setbaud.h care este menită să simplifice procesul. Este nevoie să setați frecvența ceasului procesorului. Găsiți [[https://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html|aici]] mai multe detaii despre aceasta și exemple de utilizare.</note>
 ==== 3.2 Exemplu de utilizare ====
@@ Line 195: / Line 198: @@
 {{:pm:lab:lab1-usart.zip|Schelet}}
-**Task 1**
+**Task 1 (3p)**
-Folosind scheletul de laborator configurează USART0 cu următorii parametri : baud rate 28800, 8 biți de date, 2 bit de stop, fără paritate. Transmiteți către PC mesajul “Butonul 1 a fost apasat” dacă butonul 1 (PB2) este apăsat.
+Folosind scheletul de laborator configurează USART0 cu următorii parametri: baud rate 19200, 8 biți de date, 1 bit de stop, cu verificare de paritate. Transmiteți către PC mesajul “Butonul 1 a fost apasat” dacă butonul 1 (PB2) este apăsat.
 <note warning>
@@ Line 210: / Line 213: @@
 Pentru a preciza baud rate-ul consolei seriale din VSCode cu PlatformIO, folosiți următoarea variabilă din ''platformio.ini'':
 <code>
-monitor_speed = 28800
+monitor_speed = 19200
+</code>
+Pentru a vedea mesajul scris de la tastatura in serial monitor puteti adauga:
+<code>
+monitor_echo = true
 </code>
 </note>
-**Task 2**
+**Task 2 (3p)**
 Folosind scheletul de laborator, implementează o nouă funcție USART_exec(unsigned char command) care să accepte următoarele comenzi venite pe USART:
@@ Line 227: / Line 234: @@
   * Blue – PB3
-**Task 3**
+**Task 3 (4p)**
-Trimiteți numele vostru prin interfața serială. Folosind “morse_alphabet” din scheletul de laborator și buzzerul, generati codul Morse aferent acestuia.
+Trimiteți numele distribuției voastre preferate de Linux prin interfața serială. Folosind “morse_alphabet” din scheletul de laborator și buzzerul, generați codul Morse aferent acestuia.
-**Bonus**
+**Bonus (1p)**
 Implementează un semafor controlat pe USART. Folosește ledul RGB de la Task-ul 1. Culoarea led-ului va fi în permanență roșie, până când mesajul "pieton" va fi primit pe USART. Când mesajul este primit, se va seta culoarea galbenă pentru 2 secunde, după aceasta culoarea verde pentru 5 secunde, revenindu-se la culoarea roșie până la primirea unui mesaj nou. În cazul în care se va primi un mesaj diferit de "pieton", se va trimite pe USART mesajul "cerere incorecta". În timpul execuției comenzii de schimbare a culorilor, mesajele pe USART vor fi ignorate.