ElectroYou

Ciao a tutti

Abbiamo un protocollo di comunicatione proprietario che dobbiamo modificare.
Il problema è che abbiamo un comando per leggere dei registri che attualmente ha un indirizzamento di 8 bit.
256 registri non ci bastano piú e quindi dobbiamo essere in grado di indirizzare i registri con 16 bit.

Vi mostro qui la versione attuale del protocollo di comunicazione (per ovvi motivi molto semplificata e un po' offuscata ) e due possibili soluzioni.
Mi interessere sapere quale implementereste voi.



In grigio la variante attuale.
Da sinistra a destra:
- Slave ID: indirizzamento di tutto il messaggio ad un certo slave sul bus
- Lunghezza payload: quanti bytes ci sono del campo payload (vedi oltre)
- Comando: identifica l'azione (reset, scrivi, leggi, identifica...), in questo caso si tratta di leggere
- Payload: il contenuto dipende dal comando, nel caso di una lettura viene passato un byte che identifica il registro da leggere
- CRC: checksum

La risposta è simile, le differenze sono le seguenti:
- Payload: viene ripetuto l'indirizzo del registro da cui si è letto, seguito da 4 bytes di dati contenuti nel registro. Se il registro non esiste, viene ritornato 0xFFFFFFFF e lo status riporta un errore (vedi qui sotto)
- Status: contiene un codice diagnostico generato dallo slave (OK, comando sconosciuto, CRC sbagliata, dati non validi...)

In giallo una delle proposte di soluzione:
- la lunghezza dell'indirizzo passato nel payload diventa variabile
- lo slave deve osservare il campo di lunghezza e da lì capire come interpretare il payload, se con 8 o 16 bit
- per slave che conoscono solo la versione vecchia del protocollo non cambia nulla
- master che cercano di richiedere un indirizzo a 16 bit da uno slave a 8 bit ricevono una risposta con status = lunghezza errata

In blu l'altra soluzione:
- il comando leggi non viene modificato
- viene definito un nuovo comando leggi_ext che supporta solo l'indirizzamento a 16 bit
- il vecchio comando continua ad esistere, ma il suo uso viene deprecato

Io ho la mia opinione... il mio collega ha un'altra opinione. Non vi dico chi pensa cosa... ditemi voi cosa pensate

Grazie, Boiler

Premesso che premerei per un'implementazione standard dei protocolli per quanto possibile, specialmente a questo livello di astrazione.

Pillola blu. Codici a lunghezza variabile introducono solo complicazioni per niente, specialmente su canali rumorosi. Magari non è il caso, ma non vedo benefici in questo contesto onestamente. I protocolli sono generalmente conservativi e cercano di contrattare un upgrade della connessione sulla base di un handshake basato sulla versione precedente. Vedo nella seconda opzione una scelta migliore anche se manca parte dell'informazione contestuale per dirlo con certezza.

Per contesto, questo problema è stato affrontato in passato quando da architetture 8086 a 16 bit si è passati a 32 col set istruzioni sui nuovi registri. La soluzione allora seguita è stata di utilizzare un opcode riservato in forma di prefisso decoratore per segnalare il prossimo comando come "wide", e mantenere il resto della compatibilità a livello binario.

La volta dopo da 32 a 64 si è scelto un approccio diverso. Un overlay dei comandi basati su una negoziazione configurando dei bit di controllo. Quindi ci sono tutti i gusti .

Pillola gialla.

Siete a questo punto perché, secondo me, non vi è una sostanziale differenza.
Tirate una monetina!

Direi la blu

Io sarei per la blu anche se farei in modo diverso.
Ogni master acquisisce ciclicamente con un comando broadcast tutte le periferiche di competenza e si memorizza la configurazione di ognuna (tra cui anche 8 o 16 bit di indirizzo, ecc).
E da quel momento in base alla tabella viene gestita ogni comunicazione.
Altrimenti al contrario. La periferica si annuncia alla rete (ogni volta che viene accesa ) e comunica a tutti (compresi i master) le sue generalità e le relative caratteristiche di comunicazione.
Queste informazioni vengono memorizzate dai Master in una tabella apposita che lega ad esempio nome, indirizzo, modalità 8/16, tipo di crc, ecc
E da quel momento in base alla tabella viene gestita ogni ulteriore comunicazione.
Ciao

Grazie a tutti per i contributi.
La mia scelta sarebbe in effetti la blu, quindi il tenore delle risposte mi fa piacere

La differenza tra blu e giallo c'è, ed è enorme.
Quando implementa l'interpretazione di un protocollo del genere, di solito la si suddivide almeno tra framer a parser. Il framer si occupa di verificare la CRC e che la lunghezza ricevuta sia quella corretta, poi passa il comando e il payload al parser che esegue l'operazione. Il parser non ha bisogno di conoscere quanto ci fosse nel campo lunghezza del preambolo.

È un approccio pulito, a layer, che si appoggia al modello OSI (anche se non implementandolo completamente).
E si attiene anche al principio dell'information hiding.

Chiaramente, modificare il framer in modo che passi la lunghezza al parser è un gioco da ragazzi. Ma la domanda è "voglio davvero farlo?".

Nel frattempo qui stiamo degenerando... è apparso il collega 3 che perora l'implementazione di ambedue le soluzioni
La gialla dovrebbe ritornare dei valori dalla cache dello slave, mentre quella blu ritornerebbe i dati dopo averli aggiornati.

Devo andare a vomitare, torno subito...

Boiler

Inferire la lunghezza della PDU dal codice comando è quello che fa MODBUS ad esempio, ma non avevi specificato che non passavate la lunghezza del payload ai livelli superiori.
Visto che era un po' tutto "offuscato" e che comunque vi sono lunghezze diverse già ora, e magari altri comandi, non pensavo che non la passavate già.
Da come racconti ora, sì, mi sembra più semplice la blu.
Però non c'è nulla di male a passare la dimensione del payload ai livelli superiori.

GioArca67 ha scritto:Inferire la lunghezza della PDU dal codice comando è quello che fa MODBUS ad esempio

È vero, hai perfettamente ragione.
Ma questo protocollo non si può paragonare a Modbus (per ovvi motivi ho dovuto omettere parecchi dettagli e capisco benissimo che possa essere stata percepita una somiglianza)

Però non c'è nulla di male a passare la dimensione del payload ai livelli superiori.

Sì, forse ho una posizione un po' estremista
Però definirla in due posti diversi a dipendenza del messaggio, questo no, dai!

Boiler