Blog

Jan 22, 2024

Cosa potrebbe andare storto: edizione seriale asincrona

È la cosa più semplice del mondo: dati seriali semplici e diretti. È il protocollo di comunicazione di fallback per quasi tutti i sistemi embedded disponibili, quindi è quello che desideri davvero

È la cosa più semplice del mondo: dati seriali semplici e diretti. È il protocollo di comunicazione di fallback per quasi tutti i sistemi embedded disponibili, quindi è quello su cui vuoi davvero lavorare quando i chip sono inattivi. E ancora! Quando ne hai più bisogno, potresti scoprire che anche il seriale asincrono può costarti qualche ora di debug e aggiungere qualche capello grigio al tuo cuoio capelluto.

In questo articolo tratterò la maggior parte (tutte?) delle cose che possono andare storte con i protocolli seriali asincroni e come diagnosticare ed eseguire il debug di questo utilissimo metodo di trasferimento dati. L'obiettivo è renderti sufficientemente consapevole di ciò che può andare storto in modo che, quando ciò accada, potrai risolverlo sistematicamente in pochi minuti invece di sprecare qualche ora.

Immagina di avere otto bit di dati che vuoi inviarmi elettronicamente. Se abbiamo otto fili (più terra) tra di noi, puoi semplicemente girare gli otto interruttori e mettere tensioni alte o basse su ciascun filo. Se dall'altra parte mi trovo con alcuni LED, leggo semplicemente quali si accendono e il gioco è fatto. Ma otto fili sono tanti rame. Quindi decidi invece di inviare un bit alla volta, utilizzando un solo filo (più terra). Questa è l'essenza della comunicazione seriale: i bit vengono inviati in serie variando con precisione la tensione su un cavo nel tempo.

Sembra facile, ma ora abbiamo alcune scelte da fare. Quanto velocemente invii ogni bit? Un LED acceso rappresenta un 1 o uno 0? Come faccio a sapere quando il tuo messaggio inizia o finisce? E infine, se entrambi dobbiamo scambiarci dati, avremo bisogno di due cavi. Come facciamo a sapere quale sto inviando e quale stai inviando tu? Ognuna di queste scelte è un luogo in cui si possono sbagliare cose e in cui si insinuano bug.

L'ultimo punto, quali fili trasmettono dati in quale direzione, è sorprendentemente una comune fonte di confusione, quindi è un buon punto di partenza per il debug.

“RX” e “TX” stanno rispettivamente per “ricezione” e “trasmissione”. La maggior parte dei sistemi di comunicazione seriale ne avrà uno ciascuno. Spesso la configurazione avviene in questo modo: ti ritroverai a collegare “GND” su un dispositivo fino a “GND” dell'altro. Forse condivideranno anche una barra di alimentazione, quindi collegherai il "VCC" dell'uno al "VCC" dell'altro. E poi, in un attimo, collegherai "RX" su un dispositivo fino a "RX" sull'altro.

E questo è l'errore numero uno. Entrambi i dispositivi si aspettano di ricevere dati sulla loro linea "RX", quindi entrambi si siedono lì ad aspettare mentre le due linee "TX" finiscono per parlare tra loro. No, il modo “giusto” per farlo è collegare la porta “RX” di un dispositivo alla porta “TX” dell’altro e viceversa. È semplicemente logico, vero? Per aiutarti a ricordartelo, a volte il "TX" sarà etichettato come "TXD" dove la "D" sta per "dispositivo" e questo dovrebbe ricordarti che stai guardando le cose dalla prospettiva di questo dispositivo.

Comunque lo si chiami, collegare una porta chiamata "TX" a una porta chiamata "RX" causa problemi nei moderni programmi CAD, dove si nomina la rete anziché le singole porte. Come si chiama un cavo che collega i pin "GND" di entrambi i dispositivi? “GND” è un buon nome. Come si chiama il filo che collega “TX” a “RX”? Che ne dici di quello che collega “RX” a “TX”? Regna la confusione.

(Nota che SPI, che ha i suoi problemi di cui parleremo la prossima volta, chiama queste linee "master in, slave out" e "master out, slave in". I nomi delle linee sono coerenti e se sai quale dispositivo che stai guardando, sai immediatamente in quale direzione stanno fluendo i dati. Questo è molto meglio.)

Quindi la prima domanda di debug da porsi è se hai attraversato correttamente o meno le linee del segnale. E anche se lo hai, prova comunque a scambiarli perché anche se non sei confuso, non puoi essere sicuro che l'ingegnere a monte di te non lo fosse. (Lo abbiamo visto accadere.)

Abbiamo capito bene il cablaggio, quindi che ne dici della velocità con cui invii (e ricevi) i dati? Questo è importante, perché se vedi un'alta tensione sul cavo per un po', devi sapere quanti bit quel “mentre” avrebbe dovuto rappresentare. Se ti mando quattro zeri, vedrai una tensione costante per il doppio del tempo che se te ne mandassi due, ma dobbiamo concordare una base temporale in modo che tu possa essere certo che non ho inviato solo due zeri, o otto .