Buoni protocolli basati su RS232 per la comunicazione da embedded a computer

Sto lavorando a un progetto che prevede una buona comunicazione dei dati tra un Arduino remoto e un computer. La connessione wireless avviene tramite una coppia di XBees, quindi abbiamo un collegamento RS232 tra Arduino e il computer. Per piccole quantità di dati, è abbastanza facile mettere insieme un semplice protocollo di comunicazione. Per progetti più grandi, tuttavia, quali sono alcuni buoni protocolli di comunicazione semplici?

Ho esaminato MODBUS, che sembra un'opzione praticabile, ma volevo vedere se c'erano altre opzioni migliori.

L'OP richiede un protocollo seriale per una situazione in cui " non molti [di dati] e la velocità non sono un grosso problema ". MODBUS è menzionato nell'OP MODBUS su RS-485 non è un protocollo veloce. Anche se questa non è una specifica, dà un'idea della nicchia.

Posso pensare solo a due protocolli standard comuni per questa nicchia:

• NEMA 0183 . Protocollo ASCII in testo semplice. Leggibile dagli umani. Solo punto a punto. Non supporta il bus multi-drop.
• MODBUS che è già stato menzionato nel PO

Molto spesso, quando i programmatori integrati si trovano in una situazione come l'OP, progettano da zero i propri protocolli di comunicazione seriale.

Alcuni protocolli di sistema integrati, molti dei quali estremamente semplici, sono elencati in Sistemi integrati: protocolli comuni , tra cui:

• Tiny Embedded Network (TEN)
• Interprete di microcontrollori per sistemi integrati in rete (MINES)
• Yet Another Scalable Protocol (YASP)
• Rete di interconnessione locale (LIN)
• Serial Servo Controller (SSC)
• Sistema operativo robot seriale (rosserial)
• netstring
• vari bus di campo
• Modbus
• Controller Area Network (CAN)
• Firmata (Grazie, jippie!)

Forse uno di questi protocolli sarebbe adeguato per l'applicazione così com'è, o con modifiche minori.

Vorrei votare il tuo e lo terrei il più semplice possibile.

Ho trattato molti protocolli seriali per varie applicazioni di controllo e alcune cose che posso consigliare di includere sono:

• Avvia e ferma personaggi che non sono usati altrove
• Una sorta di checksum / controllo degli errori
• Alcuni metodi di controllo / segnalazione del flusso, specialmente se hai bisogno di comunicazioni bidirezionali.

Come esempio molto semplice, potresti convertire i tuoi dati in caratteri ASCII e incollarli all'interno di caratteri start / stop in questo modo:

Per inviare il valore byte 0x7A, i dati inviati sarebbero (7A), dove () sono i caratteri di avvio / arresto scelti e 7 e A sono due caratteri ASCII. OK, aggiunge un sacco di sovraccarico, ma significa che è possibile eseguire il debug con il software terminale di base.

Se i tuoi dati passano attraverso XBees, dovresti mettere i moduli in modalità API con caratteri di escape, dividere i tuoi dati in pacchetti logici e trarre vantaggio dal fatto che in modalità API un pacchetto che viene dato a un XBee arriverà intatto o Affatto. Progetta il tuo protocollo attorno alla trasmissione di blocchi di 1-255 byte e lascia che i moduli XBee si preoccupino di come consegnare i dati all'interno di ciascun blocco. Non preoccuparti di mantenere l'integrità dei singoli pacchetti o le suddivisioni tra di essi. I moduli Digi faranno un buon lavoro nel prendersene cura. La cosa più importante di cui devi preoccuparti è il fatto che anche se il nodo che trasmette un pacchetto crede che non sia stato consegnato e che invii un rimpiazzo, il destinatario potrebbe finire per ottenerlo comunque - probabilmente anche dopo aver ricevuto il rimpiazzo. Le cose potrebbero essere più semplici se si progetta il proprio protocollo in modo che un lato sia il "master"; se il master richiede un dato, lo slave dovrebbe inviarlo una volta e non preoccuparsi se il master lo riceve. Se il master non ottiene i dati desiderati, può richiederli nuovamente.

Lo slave deve assegnare una sorta di numeri di sequenza ai dati e il master deve assegnare i numeri di sequenza alle richieste di modifica dello stato dello slave. Se la richiesta del master è nel formato "invia il primo elemento il cui numero di sequenza è maggiore di XXX" e ogni elemento di dati dallo slave include il proprio numero di sequenza e quello dell'elemento precedente (se non sono numerati consecutivamente ), i pacchetti in arrivo in ritardo possono far sì che lo slave invii in modo ridondante dati al master, ma il master non avrà difficoltà a ignorare le conseguenti risposte in arrivo. Se lo slave riceve una richiesta di cambio di stato il cui numero di sequenza è inferiore a quello di una richiesta precedente, dovrebbe ignorare quella richiesta, poiché è stata superata anche prima di essere ricevuta.

Che ne dici di Firmata ? Ha il supporto per vari sistemi operativi e linguaggi di programmazione. Il lato controller Arduino e PICduino sono supportati, ma non dovrebbe essere troppo difficile portarlo su un microcontrollore nudo.

Avevo una domanda simile a questa e non ho mai trovato nulla di semplice e abbastanza piccolo per piccoli AVR ecc. Quindi ho realizzato qualcosa ispirato a CAN. Si chiama MIN (Microcontroller Interconnect Network):

https://github.com/min-protocol/min

Ne ho un blog qui:

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

Ci sono hook lì per i dati di blocco, ma sono principalmente rivolti ai segnali per sensori / attuatori. Ho definito un formato JSON per descrivere i segnali e il loro impacchettamento all'interno dei frame MIN e spero di ottenere un dissettore Wireshark che lo usi.