Se lo slave sta ricevendo un pacchetto, dati non deve interpretare i byte contenuti in esso. Lui deve solo riconoscere:
- il byte di start, ed iniziare a leggere;
E' qui che nasce il mio problema, ma senz'altro sono stato poco chiaro. Provo a spiegarmi con un esempio. Il master invia il seguente pacchetto secondo il protocollo che proponevo: 255, 0, 3, 5, 4, 2, 255, 6, 2, X
255 = Start
0 = IDMittente, il master ha ID = 0
3 = IDDestinatario, il master vuole interrogare lo slave con ID = 3
5 = IDComando, il master sta inviando il comando ID=5
4 = LunghezzaPacchetto, di seguito ci sono 4 bytes che, per esempio, rappresentano un long
2
255
6
2
X = Checksum, calcolato per esempio con uno XOR dei 9 bytes (escluso il checksum) che compongono il pacchetto
Ora supponiamo che uno slave si avvii (per esempio venga alimentato...) durante la trasmissione del pacchetto e quindi riceva il seguente frammento: 5, 4, 2, 255, 6, 2, X (ha perso i primi 3 bytes...)
Ignorerà i bytes 5, 4, 2 perchè aspetta un 255 di start, quindi interpreterà bytes seguenti come:
255 = Start
6 = IDMittente
2 = IDDestinatario
X = IDComando
e qui continuerà ad attendere in attesa dei rimanenti bytes del pacchetto che non arriveranno mai. Tuttavia interverrà il timeout ed i bytes verranno scartati con codice di errore = TIMEOUT.
In effetti mi pare che funzioni, volevo soltanto confrontarmi anche con voi sulla correttezza della soluzione, nel caso mi sfugga qualcosa.
- il byte contenente il numero di byte ulteriori che deve ricevere, e questo valore non può essere confuso con altri perché è in una posizione ben precisa, e poi i byte di stop e di checksum, che arrivano in determinate posizioni (dipendenti da quanti byte sono stati trasmessi).
Non avevo previsto un byte di stop... ti sembra necessario?
Quindi è una catena da verifica con timeout in ogni operazione critica, come hai capito anche tu.
Qui non so se basta il timeout, come dicevo nel post precedente, in caso di ritardo nella risposta dello slave, potrebbe verificarsi una collisione perchè il master non ricevendo risposta entro il timeout, pensa che lo slave sia down ed inizia una nuova trasmissione, magari verso un altro slave. Contemporaneamente lo slave precedente trasmette la sua risposta generando la collisione che rileveremo attraverso il controllo del checksum. Dobbiamo però capire come fanno tutti gli oggetti sul bus (il master e gli n slaves) a ritornare in una condizione stabile.