Impariamo ad utilizzare un analizzatore di protocolli con il Protocol Simulator Board

Nell’articolo precedente vi ho illustrato un analizzatore logico della Zeroplus che, attualmente, é uno dei piú performanti sul mercato. Questa volta, invece, vi faccio vedere con quanta semplicitá é possibile tirare fuori da un segnale, in automatico, con un paio di click, tutte le informazioni di cui abbiamo bisogno. E per farlo andró ad utilizzare una board educativa, prodotta da Zeroplus, in grado di simulare decine e decine di protocolli di comunicazione.

Protocol Simulator Board

Attualmente in catalogo, Zeroplus, ha due board con questo nome, che si chiamano semplicemente Protocol Simulator Board 1 e Protocol Simulator Board 2. Le due board esternamente sono perfettamente e funzionalmente identiche (sono praticamente indistinguibili dal momento che non é riportata una indicazione 1 o 2 sul PCB) e si differenziano unicamente dalla confezione, dal manualetto incluso e quindi dai protocolli che possono emulare (si tratta in pratica della stessa board che é stata programmata in manierta differente). A me é stata inviata la Protocol Simulator Board 1 che puó simulare i seguenti 46 protocolli:

Up Counter, I2C (generico), SPI, UART, 1-wire, HDFQ, CAN2.0B, PS/2, I2S, USB1.1, I2S, Low Pin Count, SSI, Microwire (generico), LIN2.1, Manchester, Miller, S/PDIF, SD2.0/SDIO, Digital Logic, Arithmetical Logic MII, LCD1602, ModBus, 7-Segment LED, ST Bus, IrDA, DMX512, Flexray 2.1A, LPC-SERIRQ, JTAG2.0, DSA, ST7669, LCD12864, PCM, MCU-51 Decode, NEC PD6122, PM Bus 1.1, PSB, SM Bus 2.0, DIGRF, AC97, SLE4442, CCIR656, PECI, 3-Wire, J-K Flip Flop.

Mentre la Protocol Simulator Board 2 puó simulare i seguenti, diversi, 55 protocolli:

I2C (specifico EEProm tipo 24L), PCI, Modified Miller, ISO7816 UART, SDQ, HD Audio, UNI/O, Modified SPI, WIEGAND, DALI, SCCB, LPT, SAMSUNG K9 (NAND Flash), Compact Flash 4.1, OPENTHERM 2.2, Philips RC-5, MVB, PROFIBUS, WTB, Philips RC-6, HDMI CEC, HPI, DSI, Microwire (specifico EEProm tipo 93C), DM114/DM115, DS1302, SPI compatible (Atmel memory), SVID, PT2262/PT2272, I2C (specifico EEProm 24LC61/62), SHT11, LG4572, WWV/WWVH/WWVB, MIL-STD-1553, FWH, S2CWire/AS2CWire, DS18B20, GPIB, CMOS IMAGE, BDM, YK-5, HART, SWP, BMS, USB2.0, KEELOQ Code Hopping, Differential Machester, eMMC, 1-Wire (advanced), KNX, MIDI, SWD, SD3.0, LineCode, QuadSPI

Come vedete non ci sono protocolli in comune tra le due board (a parte qualcosina, ad esempio I2C, che per la 1 é generico, mentre per la 2 emula proprio una EEProm 24L) e la 1 forse contiene i protocolli piú comuni a livello didattico. 

Si passa da un protocollo all’altro tramite una selezione eseguita sui dipswitch. Nel paragrafo successivo vi spiego come vanno impostati i dipswitch e come funziona la board

Selezione del protocollo sulla Protocol Simulator Board

Osserviamo come é fatta la scheda:

In alto abbiamo un header maschio da 25×2 pin, con spaziatura standard da 0.1″: vediamo che, tranne i primi due pin sulla sinistra (PGDATA e PGCLOCK), la restante prima fila é occupata da pin di GND, la seconda fila, partendo da sinistra, ha due pin di reset (RST, PRST che immagino vadano insieme ai PGDATA e PGCLOCK per funzioni riservate o previste in futuro) ha un pin di VDD a 3.3V: se alimentiamo la board tramite USB, su questo pin sono presenti 3.3V, altrimenti possiamo evitare di usare la porta USB e dare su questo pin 3.3V per alimentare la board. Tutti i pin successivi sono le uscite del simulatore di protocolli, la cui funzione varia in base al protocollo selezionato.

La porta USB di tipo B é utilizzata esclusivamente per l’alimentazione. Quando alimentiamo la board da porta USB, l’interruttore al disotto (ON/OFF nell’immagine) permette di accendere e spegnere la scheda. Quando invece alimentiamo la board fornendo 3.3V sul pin VDD, l’interruttore non funziona e la board rimane sempre alimentata finché é presente tensione sul pin VDD (questo é del tutto normale dato che l’interruttore stacca la linea dei 5V dalla porta USB).

Il dipswitch ad 8 posizioni siglato SW4 permette la scelta del protocollo secondo una tabella che é inclusa nella confezione ed é anche scaricabile dalla pagina del rispettivo prodotto (vedi paragrafo Links piú in basso). Nella tabella é anche indicato quali pin di uscita sono utilizzati per i segnali, ad esempio prendiamo, sulla Protocol Simulator Board 1, il protocollo utilizzato dai display LCD alfanumerici basati sul controller HD44780 e simili (ve ne parlavo nel 2009), che in questo caso é fissato su un display classico da 16 caratteri per 2 righe, ed é chiamato LCD1602:

Vediamo che dobbiamo mettere verso ON (versio l’alto) gli switches 2,3,6,7 e 8, mentre vanno verso OFF (verso il basso) gli switches 1,4 e 5. Avremo quindi le 8 linee dati del display sui pin di uscita da PTD0 a PTD7 (viene quindi emulato il display nella modalitá ad 8 bit anziché nella modalitá a 4 come siamo abituati qui), il pin di Register Select (RS) lo avremo su PTE0, il pin di Lettura/Scrittura (RW) su PTE1 e l’enable (E) su PTE2, in pratica verranno utilizzate tutte le prime 11 uscite dell’header da PTD0 a PTE2, in ordine. In pratica il simulatore di protocolli, in questo caso, fa finta di essere un microcontrollore al quale é collegato un display alfanumerico da 16×2 caratteri e invia i relativi segnali su quelle linee, alle quali non andremo a collegarci con un display ma con l’analizzatore logico per vedere come funziona.

Del dipswitch SW1 viene utilizzato soltanto lo switch 1, che in posizione ON fa in modo che il segnale venga inviato una volta soltanto, e per inviarlo bisogna premere il pulsante SW3 (che nell’immagine ho identificato come START), altrimenti se mettiamo tale switch in posizione OFF, il segnale viene inviato di continuo  e il pulsante SW3 non ha funzione. Tutti gli altri interruttori del dipswitch SW1 attualmente non hanno funzionalitá.

Infine, dietro al pulsante SW3, é presente un header maschio a 2 pin, di cui uno é GND e l’altro tira fuori un’onda quadra a 10MHz.

La selezione del protocollo da simulare va fatta a board spenta: quando la board viene accesa, il protocollo viene caricato e viene inviato di continuo (se lo switch 1 di SW1 é in OFF) oppure bisogna premere il pulsante SW3 per inviare solo un treno di impulsi completi (se lo switch di SW1 é in ON). Se la selezione del protocollo viene fatta a board accesa (ovvero: qualsiasi switch viene spostato dalla posizione che aveva all’atto dell’accensione), non ha efficacia e viene comunque simulato il protocollo rilevato all’atto dell’accensione, con la modalità (continua o a richiesta del pulsante) già selezionata.

Per cui: se cambiate protocolli da simulare o la modalità di invio e la board é alimentata da USB, ad ogni cambio dovete spegnere e poi riaccendere la board dall’interruttore. Se invece alimentate la board da VDD, semplicemente staccate e riattaccate l’alimentazione in quanto, ricordo, il pulsante di accensione funziona solo con l’alimentazione da USB.

Curiositá sulla board

Per quanto riguarda le considerazioni costruttive su questa scheda: a bordo c’é quella che dovrebbe essere una FPGA, sebbene di un marchio a me sconosciuto (ETOMS, o forse E-TOMS, o forse solo TOMS -meno probabile), siglata ET44M210Q, per la quale non si trova assolutamente nulla in rete (se non una pagina che vorrebbe fare un confronto con una FPGA della Altera fuori produzione, ma comunque senza dare informazioni).

Abbiamo anche un comune hex inverter SN74HC04N in formato DIP, zocolato, di cui, apparentemente (non mi sono soffermato piú di tanto ad indagare) solo un buffer é utilizzato (il primo sui pin 1 e 2) per portare fuori il segnale a 10MHz, che riceve dalla FPGA.

La porta USB non ha le linee dati collegate, per cui si esclude la possibilitá di eventualmente aggiornare/modificare la scheda in questa maniera cosí semplice. Sulla board é presente un jumper J5 che collega il pin indicato come RST ad un pin della FPGA, per cui potrei supporre che questo primo gruppo di 3×2 pin sull’header (PGCLK, PGDATA, RST, PRST e gli adiacenti GND e VDD) possano in qualche modo servire a riprogrammare la FPGA, o forse a questo scopo é dedicato l’header non popolato J3. Ad ogni modo meglio non toccare questi pin!

Sulla board sono presenti 4 led oltre a quello blu che indica la presenza della tensione di alimentazione: tra porta USB e header. Di questi led solo il primo, D1, é utilizzato per segnalare l’attivitá di trasmissione dati, mentre gli altri 3 sono apparentemente inutilizzati ma comunque collegati alla FPGA.

Il dipswitch SW1, anche se ha un solo switch utilizzato, ha comunque gli altri switch collegati alla FPGA.

La regolazione di tensione (dai 5V della USB ai 3.3V) viene fatta da U4, mentre U3 (7024A-1) dovrebbe essere uno stabilizzatore di tensione usato per la FPGA.

Simulazione UART

Vediamo adesso come va usata la Protocol Simulator Board 1 insieme all’analizzatore logico Zeroplus per imparare ad utilizzare la funzionalitá di analisi dei protocolli. Partiremo da un protocollo abbastanza semplice: l’UART (Universal Asynchronous Receiver Transmitter). Sappiamo che il protocollo UART trasmette i dati in maniera seriale e senza utilizzo di un clock, per cui quando si adopera una UART con i microcontrollori c’é bisogno che, in qualche modo, i dispositivi sulla linea siano settati per operare allo stesso baudrate. Con gli strumenti, per fortuna, non cé bisogno di conoscere la velocitá di trasmissione dal momento che questo dato viene calcolato automaticamente misurando il tempo piú basso rilevato trascorso tra due transizioni successive.

Il protocollo UART é, sulla tabella dei dipswitch della protocol simulator board, é alla riga numero 3:

Notiamo che sulla tabella viene riportato tra parentesi RS232-C/422/485, questo perché il protocollo UART (ed é compreso quello a livelli TTL 5V/3.3V/1.8V anche se non è indicato espressamente) funzionano (meglio: codificano il dato) tutti allo stesso modo: cambiano solo i livelli di tensione e/o il modo in cui va interpretata la transizione (es.: il livello logico 1 per una UART TTL corrisponde alla tensione di alimentazione del device, mentre per una RS232 corrisponde al livello di tensione negativa ecc): per cui l’UART, qualsiasi sia il layer fisico, utilizza in qualche modo sempre la stessa modalità di codifica del dato, solo che in fase di analisi, in alcuni casi, andremo a specificare che il livello logico va interpretato in maniera inversa rispetto al livello di tensione.

RS232/422/485 non sono protocolli ma definiscono solo il layer fisico (i livelli di tensione, come avvengono le transizioni e di conseguenza come si fa a capire quando si sta trasmettendo un 1 o uno 0 per intenderci) e normalmente o si trasmette “liberamente”, ovvero inviando i dati senza usare uno schema predefinito, oppure si utilizza un protocollo specifico sul layer fisico: cosa che oltre ad aumentare in qualche modo l’ordine permette di aggiungere livelli di sicurezza e aumentare l’immunità agli errori inviando appunto anche dei bytes di controllo e integrità del dato trasmesso. Esempi possono essere il protocollo modbus o profibus utilizzati su una linea RS485. Giusto per completezza di informazioni, anche se mi ripeto : Il Modbus è anche emulato dalla board 1, mentre il profibus dalla board 2

In una situazione reale andremo a monitorare una (o Tx o Rx) o due linee UART (Tx e Rx), per cui potremo scegliere di applicare la decodifica del protocollo su un solo canale e poi, dato che la funzionalitá di decodifica UART dell’analizzatore prevede, a rigor di logica, solo un canale, applicarla anche all’altro canale, successivamente. Il simulatore di protocolli, dato che simula solo il dispositivo che trasmette, chiaramente avrà una sola linea dati, la Tx, il cui segnale andremo a prelevare dal pin PTD0 come indicato dalla tabella.

Poi sappiamo che RS422 e RS485, per minimizzare i disturbi, utilizzano due linee di trasmissione differenziali per canale (cioè se i dispositivi sono full-duplex avremo 4 linee in totale: 2 per Tx e 2 per Rx, se invece sono Half-Duplex ci saranno solo due linee che verranno usate a turno da chi trasmette e di conseguenza da chi riceve). Linee differenziali vuol dire che il livello logico è stabilito dalla differenza di tensione tra le due linee: nella fattispecie se una linea è a livello alto, l’altra linea sarà a livello basso e viceversa (il dispositivo che riceve poi fa il confronto tra le due linee e scarta i dati non congruenti).

La Protocol Simulator Board, per l’emulazione UART, utilizza comunque una sola linea dati, non simula anche l’altra (che sarebbe usata da RS422 e RS485) che trasmette il livello opposto perchè in questo caso specifico (stiamo simulando!) non è necessaria.

In una situazione in cui stiamo analizzando una linea RS485 “vera”, andremo, chiaramente se lo riteniamo opportuno, a prendere i segnali da entrambe le linee e andremo ad applicare la decodifica di protocollo ad entrambe (ricordandoci di invertire una delle due – la linea B, anche identificata a volte con Y oppure col segno meno) e fermo infine il confronto.

Dopo aver settato i dipswitch sulla protocol simulator board, personalmente preferisco inviare il treno di dati una volta sola, dopo aver premuto il pulsante, per cui lascio sempre settato il primo interruttore del dipswitch SW1 su ON.

Vi ricordo che la Protocol Simulator Board va spenta e riaccesa se abbiamo cambiato la posizione dei dipswitch quando era accesa, altrimenti non prende il settaggio.

Colleghiamo quindi il cavo del canale A0 (marrone) dell’analizzatore logico, sul pin PTD0 della board e il cavo nero (GND) dello stesso banco di porte A ad un punto di GND della board.

Per gli esempi mi riferiró al software Zeroplus ZP-Logic, che é quello utilizzato dal mio LAP-C PRO 32256, ma le considerazioni sono quasi del tutto identiche se utilizzate uno strumento della serie LAP-C (standard) con il rispettivo software.

Forniamo alimentazione alla board o tramite la porta USB (e accendiamo premendo l’interruttore) oppure con i cavetti jumper F/F in dotazione diamo alimentazione alla board sui pin VDD e GND prendendola dall’analizzatore logico.

Avviamo quindi il software e impostiamo l’acquisizione:

Io ho messo la quantitá di segnale da acquisire a 256Ksa (256mila  campioni), la frequenza di campionamento a 10MHz e la posizione del trigger al 10% (ovvero verrá acquisita anche una parte di segnale predente al trigger, impostata al 10% della memoria impegnata). Andiamo quindi ad impostare la condizione di trigger: conviene in questi casi mettere la transizione in qualsiasi verso:

Cliccate sul quadratino affianco al nome del canale dello strumento fino a che non esce il simbolo che sembra una X: ovvero transizione da alto a basso o dal basso all’alto. Siamo quindi pronti. Premiamo il tasto sul corpo dell’analizzatore logico oppure il tasto play nel selettore circolare. Compare la finestra di acquisizione che attende la condizione di trigger.

Se la finestra in questione appare e subito dopo scompare (con trasferimento dati) vuol dire o che non avete impostato la condizione di trigger (quindi l’acquisizione parte da subito, non essendoci condizioni) oppure avete settato la Protocol Simulator Board per inviare i dati in continuo.

Avviamo quindi la protocol simulator board premendo il pulsante. La finestra di attesa cambia diciture (anziché wait compare prima Acquiring e poi Transferring) e avremo una situazione del genere:

Vediamo chiaramente che nel Navigator su A0 abbiamo delle transizioni che partono proprio in concomitanza del trigger (barra T) in quanto la linea era muta fino a che non abbiamo premuto il pulsante sulla board per farle inviare il treno dati (non abbiamo cioé segnali precedenti al trigger). Diminuendo lo zoom (premendo sulla lente di ingrandimento col segno meno), possiamo anche riuscire a vedere, in questo caso, tutta la porzione acquisita nella parte superiore:

Queste transizioni ovviamente per ora non ci dicono nulla. Sappiamo di aver acquisito segnali relativi ad una UART e basta. Tra l’altro non conosciamo nemmeno il baudrate. A questo punto entra in gioco l’analizzatore di protocollo che possiamo invocare in vari modi, ad esempio dal menú Acquisition ⇒ Add Protocol Decoder anche se il mio sistema preferito é quello di cliccare col tasto destro sul canale e selezionare Add Protocol Decoder:

Si presenta una finestra di selezione protocollo nella quale i protocolli sono raggruppati per tipologia e UART appare giá messo nei preferiti:

UART é normalmente presente alla categoria IC Interface. Potete aggiungere protocolli nella sezione Favorites semplicemente premendo il tasto destro e selezionando Add to my favourites. Analogamente per protocolli presenti nei preferiti é possibile rimuoverli.

Premiamo il tasto Next. Compare una finestra in cui andremo a settare il protocollo:

Vediamo innanzitutto che dove c’é scritto Baud Rate, oltre a poter selezionare il valore da una casella a discesa, é anche disponibile una checkbox Auto che elimina la casella di selezione e fa comparire il baud rate calcolato. E’ chiaro che qualsiasi baudrate non é mai preciso e in questo caso a me viene calcolato 9643 che fa capire subito che il dispositivo sta trasmettendo a 9600. Possiamo settare parametri di base di una comunicazione UART come il controllo paritá, i bit di stop e il numero di bit trasmetti per pacchetto: nella stragrande maggioranza dei casi i valori di default vanno bene. Se ci troviamo di fronte ad un macchinario molto vecchio (mi é capitato con alcune bilance Gibertini anni ’70) potremmo trovarci controlli paritá e bit di stop diversi da 1, in questi casi purtroppo o si ha il manuale a disposizione o si va per tentativi perché non é possibile determinare questi parametri in automatico trattandosi di un modo di trasmettere i dati che non ha un protocollo definito né un clock. Possiamo scegliere anche la direzione dei dati, che di default é dal bit meno significativo a quello piú significativo (LSB⇒MSB).

La seleziona Invert Signal Decoding é quella da flaggare, ad esempio, nel caso in cui abbiamo acquisito entrambi i canali, A e B, di una linea RS485, per cui il canale B segue l’andamento opposto della A: in questo caso specifico andremo a flaggare quell’opzione per il canale B (ovvero il fronte alto del segnale sará interpretato come livello logico 0 e viceversa). In questo modo possiamo applicare il protocol decoder prima ad A, poi a B, invertendo, e possiamo confrontare le due linee per vedere se stanno trasmettendo gli dati.

Premiamo quindi Next. Veniamo invitati a dare un nome al nuovo bus appena creato e a scegliere di eliminare i canali inutilizzati (per avere un grafico magari piú pulito):

Premiamo quindi Ok. Si ottiene quindi una situazione simile:

Vediamo che le transizioni sono state raggruppate in gruppi da 8 bit come impostato e ne é stato interpretato il valore (zone di colore verde). I bit di start sono stati colorati in ciano e quelli di stop in rosso.

Vediamo innanzitutto che il valore dei bit é scritto in esadecimale, potremmo volerne vedere il valore in ASCII o in binario: si fa in un secondo cliccando col tasto destro sul nome del bus e selezionando Numeric base/Encoding:

vediamo che abbiamo parecchie opzioni a disposizione!

Cliccando la freccia verso il basso affianco al nome del bus, possiamo espanderlo visualizzando i canali che sono stati raggruppati al suo interno (uno solo in questo caso specifico):

Affianco al Navigator la finestra del Packet List dove sono elencati tutti i pacchetti trasmessi:

Possiamo anche esportare questi pacchetti in un file di testo cliccando sul tasto a forma di contenitore con la freccia in su:

Analisi RS485 reale

Per provare il decoder su una linea RS485 reale, piuttosto che con l’emulator board, ho fatto due semplici schedine basate sul MAX3088 e scritto un programmino su Arduino che mi invia, sulla UART, la semplice stringa “settorezero”:

void setup() 
  {
  Serial.begin(9600);
  }
 
void loop()   
  {
  Serial.print("SETTOREZERO");
  delay(50);
  }

Ho quindi collegato il Tx di Arduino al convertitore RS485 e ho collegato due canali dell’analizzatore alle uscite A e B del modulo RS485 per acquisire entrambi i canali, dopodiché ho caricato il protocol decoder sul canale A, come abbiamo visto prima, e dopo l’ho caricato sul canale B, impostando per questo canale il flag Invert Signal Decoding, ottenendo questo:

Come vedete, per la RS485, le due linee A e B hanno le transizioni  che vanno in direzioni opposte e i due protocol decoder applicati alle due linee tirano fuori gli stessi dati (ho dovuto ovviamente ricordarmi di, come dicevo prima, invertire la decodifica per il canale B).

Nel caso della RS485, ancora, un sistema veloce per verificare che i dati trasmessi sulle due linee A e B siano corretti potrebbe essere quello di applicare delle funzioni logiche. Ad esempio abbiamo la possibilitá di invertire i segnali dei canali cliccando col tasto destro e selezionando Invert Signals:

Un canale che abbiamo invertito manualmente verrá rappresentato come tratteggiato e con una linea al di sopra del nome del segnale: 

Giá da qui riusciamo, a colpo d’occhio, a vedere se in qualche punto, ad esempio, i due segnali differiscono.

Simulazione CAN

Per il Canbus (che ormai é alla versione 2.0 dappertutto) la selezione da eseguire sulla Protocol Simulator Board é la numero 6:

Anche il Canbus (che é definito sia a livello fisico che a livello protocollo) adotta un sistema di tramissione differenziale: ci sono quindi due linee identificate come CAN HI e CAN LOW. Settiamo i jumper sulla board, spegniamola e riaccendiamola e colleghiamo il canale A0 dello strumento a PTD0 della board e A1 al canale PTD1. Impostiamo la quantitá di segnale a 1M, frequenza 50MHz e trigger su A0 su entrambi i fronti. Otteniamo qualcosa del genere:

Applichiamo il protocol decoder come visto prima: tasto destro su un canale: Add Protocol Decoder. Il protocollo CAN si trova nella sezione Automotive:

Anche qui, come per la RS485, nonostante le linee di trasmissione siano 2, siamo invitati a scegliere un solo canale (ma a differenza della simulazione dell’UART, che era generica in quanto poteva anche essere un esempio di RS232 o di UART TTL, qui comunque la board simula entrambe le linee di comunicazione). Nei casi in cui c’é da specificare un baud rate io consiglio di mettere sempre la spunta su Auto:

Proseguiamo e otteniamo questo:

Nel caso del canbus peró, essendo definito un protocollo di comunicazione, é sicuramente piú interessante la vista pacchetti:

Considerazioni finali

Le Protocol Simulator Board sono sicuramente due schede molto interessanti soprattutto dal punto di vista didattico: una cosa é studiare come funziona un protocollo su carta e un’altra cosa é avere tra le mani un dispositivo che ne simula il funzionamento e fare dei test di decodifica. Mi é stato molto utile, difatti, per capire il funzionamento del Canbus per poi collegarmi con l’analizzatore logico su una board industriale e andare a colpo sicuro. Come giá detto, la Protocol Simulator Board 1 contiene sicuramente i protocolli piú diffusi.

Links

• Protocol Simulator Board 1
• Protocol Simulator Board 2
• Sparkfun: introduzione al CAN bus
• Sparkfun: introduzione a RS485
• Video Zeroplus: come analizzare l’UART
• Playlist video ZeroPlus: utilizzo delle funzionalità del LAP-C Pro e analisi dei vari protocolli