Introduzione al protocollo SNAP
Introduzione
S.N.A.P. è un protocollo per la comunicazione tra diversi host collegati. Esso fornisce:
- indirizzazione
- bandierine
- richiesta ack/nak
- rilevamento degli errori (sono disponibili diversi metodi di rilevamento degli errori)
Può essere eseguito su diversi supporti, tra cui RS485. È ottimizzato per un piccolo ingombro (risorse di calcolo e di memoria limitate), ma scalabile a seconda delle vostre esigenze.
Fondamentalmente, se si desidera collegare diversi sistemi di calcolo e le applicazioni in esecuzione su di essi, per esempio un Raspberry Pi e diversi microcontrollori Atmel attraverso le loro rispettive UART, utilizzando RS485 come media, si vuole qualcosa per avvolgere i dati, consegnarli agli host corretti, ricevere conferme che i dati sono stati ricevuti correttamente, ecc. Questo è ciò a cui serve SNAP. È in qualche modo un'alternativa, per esempio, al protocollo Modbus.
SNAP è stato sviluppato da HTH, High Tech Horizon, una società svedese.
La homepage del protocollo è: http://www.hth.com/snap/
Per poter comunicare usando il protocollo dovreste ottenere un vendor id, per il quale potete fare domanda con HTH gratuitamente. Ti chiedono di includere un PDF del protocollo SNAP, o un link al loro sito web http://www.hth.com/snap/ con le applicazioni/prodotti. L'id del fornitore NON è incluso nei byte del protocollo reale parlato nella vostra domanda. Potete quindi valutare il protocollo prima, e poi usare la valutazione come implementazione effettiva, senza bisogno di modifiche.
Ecco l'elenco dei venditori attualmente registrati:
http://www.hth.com/snap/vidlist.html
Ecco un link direttamente alla scheda tecnica:
http://www.hth.com/filelibrary/pdffiles/snap.pdf
Alcune proprietà di base di SNAP
- protocollo binario
- set di funzioni scalabili, a seconda della vostra applicazione
- lavora con comunicazioni sincrone e asincrone (= per esempio UART)
- gratuito per uso commerciale e privato. Richiede l'id del venditore gratuito per gli id commerciali
La comunicazione tra i nodi avviene sotto forma di pacchetti. Discutiamo un pacchetto di esempio, che utilizza alcune delle caratteristiche di SNAP:
fonte: Documentazione SNAP, esempio di un semplice pacchetto SNAP
preambolo: Il preambolo è opzionale, può usare qualsiasi carattere purché non sia il byte di sincronizzazione, SYNC.
- SYNC: byte unico con la seguente struttura: 01010100, indica l'inizio del pacchetto
- HDB2, HDB1: I byte di definizione dell'intestazione HDB2 e HDB1 definiscono quanto sarà lungo il pacchetto e quali caratteristiche saranno utilizzate.
- DAB1: Byte dell'indirizzo di destinazione
- SAB1: Byte indirizzo sorgente
- DB1: Data Byte 1 - il carico utile per la vostra applicazione
- CRC2: byte alto di CRC-16
- CRC1: byte basso di CRC-16
indirizzo 0 è riservato come indirizzo di trasmissione e non dovrebbe essere usato per altro. (DAB / SAB)
nota: i dispositivi che arrivano nel mezzo delle comunicazioni potrebbero sincronizzarsi su un "regolare" 01010100 nella posizione sbagliata (dove non era inteso come SYNC). Perciò dovrebbe essere usato un checksum, in modo che il dispositivo possa riconoscere che i dati "non vanno bene", e dovrebbe continuare ad ascoltare il prossimo pacchetto che inizia con lo 01010100. (Questo è necessario per proteggere dagli spostamenti di frame). Ovviamente il dispositivo scarterà tutti i byte prima di ricevere il primo 01010100, poiché non ha ricevuto il pacchetto completo.
byte di definizione dell'intestazione
SNAP è costruito in modo modulare ed estensibile. Si possono definire indirizzi di destinazione (DD) con lunghezza da 0 a 3 byte nel DAB, byte di indirizzo di destinazione. Con un indirizzo di destinazione di 3 byte (DD = 11) otterrete fino a 16 777 215 nodi indirizzabili. Con un indirizzo di destinazione di 1 byte (DD = 01), usato nell'esempio precedente, potrete indirizzare 255 indirizzi.
Lo stesso vale per la lunghezza dell'indirizzo sorgente (SS) nei byte dell'indirizzo sorgente (SAB). Nell'esempio SS = 01 per indirizzi di 1 byte.
PFB: lunghezza byte specifica del protocollo. 0 - 3 byte, come sopra (PP). Nell'esempio PP = 00. Questa caratteristica non è ancora implementata in SNAP, e quindi dovrebbe essere impostata come 0, come nell'esempio. Un'implementazione specializzata di SNAP potrebbe probabilmente farci qualcosa (ad esempio un contatore di pacchetti, ecc.) - vedi la documentazione SNAP per alcune idee.
ACK: questa è un'area importante della definizione dell'intestazione. Indica se il nodo di invio richiede un pacchetto ACK / NAK in cambio, e agisce anche come l'effettiva risposta ACK / NAK del nodo ricevente:
- 0 0 = Nessuna richiesta di Ack (Tx)
- 0 1 = Richiesta di Ack (Tx)
- 1 0 = risposta Ack (Rx)
- 1 1 = risposta NAK (Rx)
CMD - bit di modalità di comando. Impostatelo a zero, è una caratteristica avanzata di SNAP che molto probabilmente non userete nella vostra applicazione.
EDM: metodo di rilevamento degli errori. Questi tre bit vi permettono di definire il metodo di rilevamento degli errori che volete utilizzare. Leggete la documentazione SNAP per i dettagli. Nell'esempio è stato impostato come 1 0 0 = 16 bit CRC, aggiungendo due byte di checksum (CRC2, CRC1) in coda al pacchetto.
NDB: quattro bit per determinare quanti byte di dati ci sono nel pacchetto.
1 byte, come nel nostro esempio (un databyte: DB1) è impostato da 0 0 0 1
ACK / NAK
Se impostate l'ACK a 00 nell'Header definition byte 2 (HDB2), il nodo trasmittente non si aspetterà alcun pacchetto ACK o NAK in cambio.
Se si invia un ACK / NAK dal nodo ricevente, nell'esempio a pagina 23, il byte di dati è presente con la stessa lunghezza (1 byte di dati) come nella richiesta originale del mittente, e riempito di 0es.
L'idea alla base di ACK / NAK è che il nodo di invio può, dopo un time out, prendere le misure appropriate.
Il byte di dati POTREBBE essere usato per ulteriori informazioni sul problema se viene inviato un NAK, questo è al di fuori della specifica SNAP.
Cose a cui dovreste pensare
- come faranno i nodi a determinare i loro indirizzi?
Per il master questo è facile: riceverà un indirizzo definito. Gli slave dovrebbero ricevere gli indirizzi in un modo prevedibile, in modo che sia ripetibile. Idealmente legato ad alcune caratteristiche dell'hardware.
- struttura del pacchetto
Userete sempre la stessa quantità di byte di dati? Questo permetterà una tempistica più deterministica e un'implementazione più facile, ecc.
- rilevamento degli errori
Quale algoritmo di rilevamento degli errori dovrebbe essere scelto?
Notate che il byte SYNC non è incluso nel calcolo del checksoum.
CRC è in grado di riconoscere gli errori, e idealmente anche di correggerli (per una quantità inferiore di errori).
La pagina 14 della specifica del protocollo fornisce una panoramica dei valori di controllo EDM precalcolati per testare la propria implementazione del checksum per le stringhe "SNAP" e "snap".
- lunghezza totale del pacchetto
HTH raccomanda di mantenere i pacchetti piccoli (< 40 byte) su mezzi come la linea elettrica, RF o IR per migliorare le prestazioni.
- bandiere specifiche del protocollo (PFB)
Questi potrebbero essere usati in un'implementazione specializzata del tuo protocollo, permettendoti di spostare qualche logica applicativa all'interno di questo, e di usare i dati come dati effettivi. (ad es. i bit PFB potrebbero impostare quale comando vuoi che il nodo esegua, e i dati potrebbero essere il payload richiesto per i singoli comandi). oppure potresti impacchettare comando + dati completamente nei dati, e usare solo SNAP per il trasporto, l'indirizzamento e garantire che il pacchetto arrivi senza errori.
Implementazione Python
C'è un'implementazione Python di SNAP disponibile. Notate che questo è per Python 2.
http://www.hth.com/snap/
Ecco la documentazione per questo modulo:
http://diyhpl.us/reprap/trunk/users/stef/pyRepRap/docs/reprap.snap.html
http://diyhpl.us/reprap/trunk/users/stef/pyRepRap/reprap/snap.py
Ecco un esempio di file di utilizzo:
http://diyhpl.us/reprap/trunk/users/stef/pyRepRap/examples/demo.py
Probabilmente è più conveniente scaricare il codice qui:
https://github.com/CarlosGS/Cyclone-PCB-Factory/tree/master/Software/PythonScripts/Replath/pyRepRap
Questa implementazione Python implementa un sottoinsieme di SNAP per una certa applicazione, ma è un buon punto di partenza per la vostra implementazione.
Strumenti di debugging e biblioteca
http://www.hth.com/snap/snaplab.html
http://www.hth.com/snap/snaptest.html
Si tratta di un'applicazione di test generica che è scritta in DELPHI e utilizza la porta COM per comunicare. Snaplab può spiare il traffico di rete SNAP e generare pacchetti SNAP con dati casuali.
Esiste una libreria C per il protocollo SNAP:
http://www.hth.com/snap/libdl.html
Non implementa il set completo di funzionalità di SNAP.
Ecco un'implementazione C++:
https://github.com/alx/reprap-arduino-firmware/blob/master/library/SNAP/SNAP.cpp