Ci sono diversi motivi per avere un protocollo, anche molto semplice.
- Riduci il rischio di errori, forse quando il dispositivo è connesso, avviato, arrestato
- Consenti espansioni future: forse il dispositivo invia due tipi di dati in futuro
- Assicurati di leggere dal dispositivo giusto e non qualcosa di diverso.
- Aiuta il debug se riesci a vedere uno stream che puoi riconoscere.
Ci sono alcuni vantaggi nell'usare i caratteri ASCII, se vuoi eseguire il debug. Lo farò in binario e includerò un byte di lunghezza.
Suggerirei un semplice protocollo di 6 byte. Di ':
Serial.write(0xc5); // start
Serial.write(0x06); // total length of packet
Serial.write(0x01); // 1=temperature data
Serial.write(data & 0xff); // low byte of data
Serial.write((data >> 8) & 0xff)); // high byte of data
Serial.write(0x5c); // end
Semplice, facile da codificare, espandibile. Questa sarebbe la mia raccomandazione.
Ecco alcune note sulle mie scelte per questi articoli.
- Il byte iniziale (0xc5) è un modello di bit distintivo, relativamente improbabile che si verifichi per caso, in cui metà dei bit è disattivata e metà attivata. Ciò lo rende relativamente facile da trovare con strumenti di debug incluso un oscilloscopio.
- Il byte finale è lo stesso invertito, per ragioni simili.
- Includere la lunghezza è il tipo più semplice di controllo per errori di frame o byte persi. Se il byte iniziale, il byte finale e la lunghezza corrispondono al pacchetto è probabilmente valido.
- Il byte di comando di 0x01 consente spazio per l'espansione con futuri tipi di pacchetto. Tutti i pacchetti dovrebbero avere il formato
c5,length,cmd,data...,5c .
- I dati vengono inviati in formato little-endian, che può essere più semplice da leggere per alcuni server. Si prega di notare l'uso corretto di shift mask.
Come suggerito in un commento, l'aggiunta di un semplice checksum migliorerebbe la probabilità di rilevare errori su una linea rumorosa. Un semplice XOR rotante dovrebbe essere sufficiente e facile da codificare.