Newsgroup: it.hobby.elettronica.digitale
Titolo: Voi conoscitori di mille protocolli....

...sapete indicarmene uno che abbia queste caratteristiche:
+ valori in ascii
+ dinamico (cioè la lunghezza del pacchetto non è nota a priori)
+ flessibile (deve supportare valori 'binari', interi con e senza segno, 
decimali, stringhe)
+ protetto (crc)
+ essenziale (senza tanti fronzoli)
Sto valutando di migrare verso un protocollo in "chiaro" piuttosto che 
la solita trasmissione binaria che ho sempre usato per varie ragioni. 
Sono trasmissioni punto-punto quindi non ho bisogno di gestire le 
collisioni. Vorrei però che siano il più coincise possibile.
Io ne ho in mente uno mio, ma sicuramente altri l'hanno fatto meglio...
Quando dicevo essenziale mi riferivo a qualcosa di più banale del CAN 
per intenderci.
Suggerimenti?
Se non mi piacciono implemento il mio :)
Marco / iw2nzm

 + essenziale (senza tanti fronzoli)
Non è troppo chiaro cosa devi trasmettere: un file? Dei valori di
misura ogni tanto? Un burst di dati e poi niente per un po' di tempo?
Insomma, a cosa ti servirebbe?
Alcune caratteristiche (ma non proprio tutte) mi fanno pensare alla
lontana a protocolli di trasmissione file tipo YMODEM. Solo che erano
fatti per trasmettere file di lunghezza arbitraria e non credo che sia
esattamente il tuo caso, o sbaglio?

 + essenziale (senza tanti fronzoli)
Direi il Modbus in versione ASCII, se non è troppo
complicato per quello che devi fare. Se ti serve qualcosa
di più essenziale puoi sempre partire da questo e tagliare
le caratteristiche inutili.
A.D.

 Insomma, a cosa ti servirebbe?
Giusto, data l'ora tarda non mi sono ricordato di specificare bene: 
telemetria in genere. Quindi buona l'ipotesi di un burst (un centinaio 
di byte di informazione) ogni tanto - o anche ogni poco, diciamo 
plausibilmente ogni 50-100 ms.
La tipologia di dati però è varia, ingressi digitali, ingressi analogici 
(di varia precisione), stringhe, flag, ecc...
Ciao!
Marco / iw2nzm

 Suggerimenti?
In BeRTOS c'è un protocollo che potebbe andarti bene:
http://www.bertos.org/doxygen/reference/pocketbus_8c.html
E' binario, ma lo puoi adattare facilmente per convertire ogni 
carattere in ascii prima di inviarlo :-)
Ciao

 le caratteristiche inutili.
Vero, l'avevo visto tempo fa ma me n'ero dimenticato. In effetti 
potrebbe andare bene, anche se per la mia applicazione non ha senso 
rispettarlo alla virgola.
Sarei tentato perň di usare quello RTU... ma nel caso di trasmissioni 
binarie di lunghezza variabile il termine del pacchetto lo si identifica 
solo tramite timeout?
Marco / iw2nzm

 in ascii prima di inviarlo :-)
E' molto simile a quello che sto usando attualmente. Però a me 
interessava più che altro la codifica del payload. Cioè il poter 
trasmettere nello stesso pacchetto dati di diversa natura (digitali, 
numerici interci, decimali, ecc...)
Sono io che non ho visto la documentazione in proposito oppure il 
livello applicativo è lasciato all'utente e voi (anzi, tu!) hai 
implementato solo quello di data-link?
Ciao!
Marco / iw2nzm

 implementato solo quello di data-link?
C'è anche un layer comandi che si occupa del controllo dell'indirizzo e 
della chiamata di un eventuale callback:
http://www.bertos.org/doxygen/reference/pocketcmd_8c.html
L'implementazione dei singoli comandi è lasciata all'applicazione 
specifica, anche perché è un po' difficile prevedere comandi generici 
che vadano bene per tutto.
Ciao

 le caratteristiche inutili.
Quoto, anche perchè è facilmente adattabile alla trasmissione di pacchetti 
di lunghezza non prefissata, e soprattutto perchè si trovano diverse 
implementazioni in rete già pronte all'uso!
Ciao
CG 

 pacchetto lo si identifica solo tramite timeout?
Mi pare che nella versione RTU nel pacchetto è indicata
esplicitamente la lunghezza.
A.D.

 + essenziale (senza tanti fronzoli)
TX<ADDR><DATA...><CRC><CR><NL>
Hai un prefisso (TS, due caratteri ASCII) a cui il tuo ricevitore si 
aggancia. In interrupt ricevi l'indirizzo (2 byte ASCII che 
rappresentano l'esadecimale dell'indirizzo) e tutti i dati successivi 
(sempre 2 byte ASCII che rappresentano il valore esadecimale dei dati).
Ti accorgi della fine del pacchetto dalla terminazione <CR><NL> (ancora 
2 byte ASCII).
E' un protocollo che va bene anche su un BUS perchè è ad indirizzo.
Se ti metti con uno sniffer RS232, vedi tutta la comunicazione su un 
normale Hyperterminal, senza fare programmini appositi.
Rispetto al binario, ovviamente, trasmetti almeno il doppio dei byte, ma 
per la tua applicazione non dovrebbe essere un problema.
Questo ovviamente per quello che riguarda il livello di trasporto. Se 
vuoi entrare nei dettagli dell'applicazione, bisogna definire cosa c'è 
nella parte dati.
E qui ti puoi sbizzarrire come vuoi. La rappresentazione dei valori può 
essere sempre fatta tramite ASN.1, ma secondo me è una complicazione 
troppo elevata. E se abbandoni uno standard, devi per forza inventarti 
tu un livello di applicazione qualsiasi.
Se vuoi gestire la telemetria tramite parametri atomici, potresti 
pensare ad un protocollo del tipo (sempre parte dati):
   GET <num> <idx>
   SET <num> <idx> <valore>
<num> rappresenta il numero del parametro che vuoi leggere o impostare. 
<idx> è un indice (ci potrebbero essere delle tabelle). <valore> è il 
valore da impostare (la sua rappresentazione è ASN.1 o quella che ti pare).
Potresti anche pensare di indicare nello stesso comando più parametri:
   GET <num><idx> <num><idx> <num><idx> ecc.
   SET <num><idx><valore> <num><idx><valore> ecc.
Alla fine non è molto diverso dall'SNMP.

 valore da impostare (la sua rappresentazione è ASN.1 o quella che ti pare).
No no, in realtà è molto più semplice. I dati da trasmettere sono sempre 
quelli quindi non ho bisogno di implementare comandi.
Cercavo solo il modo più compatto per trasmettere dati.
Pensavo a qualcosa del genere:
digitali > numero binario espresso in hex (8 i/o alla volta)
per i valori interi (con o senza segno) semplicemente convertirlo in hex 
(BCD più correttamente).
Non vedo niente di più compatto.
Comunque il problema si è già risolto in partenza: continuo a fare 
quello che ho sempre fatto :)
Ciao!
Marco / iw2nzm