Newsgroup: it.hobby.elettronica.digitale
Titolo: Scelta protocollo (lungo)

Ciao!
Mi capita di dover progettare un sistema di acquisizione dati basato su 
una scheda centrale (connessa poi a un PC) che probabilmente sarà un 
modulo Rabbit o similare.
Vi saranno poi n schede periferiche ciascuna dedicata a un sensore o a 
un attuatore. Ogni scheda è composta da un'interfaccia adatta a 
comunicare con il suo sensore, da un piccolo microcontroller in grado di 
fare una prima elaborazione dei dati e di inviarli alla scheda centrale.
Il numero di queste schede è variabile e non è definito a priori, si 
tratta di una struttura modulare. Non saranno più di 10-12.
Il volume di dati è stimato in 50-60 byte al secondo da ciascuna scheda, 
con un massimo di 100 byte/sec.
Infine, il protocollo di scambio dati deve essere indipendente dal 
canale fisico: RS485, Ethernet, link RF, wifi, fibra, ecc...
Mi mancano più che altro due cose da decidere. E la decisione non presa 
deriva dal fatto che non riesco ancora a valutare i vantaggi e svantaggi 
delle possibili soluzioni:
1) Gestione delle interrogazioni. Come conviene acquisire i dati dalle 
schede periferiche? Si potrebbe interrogarle una a una, con una: 
facilmente implementabile, richiede un maggior traffico sulla "rete". 
Oppure una sorta di token ring: all'accensione la scheda centrale 
assegna un numero a ogni periferica, poi la prima inizia a trasmettere i 
suoi dati. Le altre in ascolto invieranno quando sarà terminato il 
pacchetto n-1. Questa è la più rapida ma ha l'inconveniente che se si 
blocca una scheda tutto il sistema è morto...
2) Protocollo da usare per lo scambio dati. Dati binari, dati ascii, 
modbus... ecc... cosa usereste voi? Non ho detto che le informazioni 
sono eterogenee: valori di temperatura, di tensione, stringhe di testo, 
ingressi/uscite digitali ecc....
E' un posto lungo, spero di essere riuscito a dare sufficienti 
informazioni per aprire una discussione :)
Grazie!
Marco / iw2nzm

 informazioni per aprire una discussione :)
Una domanda faccio:
Ma queste schede (una, qualcuna) hanno sempre qualcosa da trasmettere o
soltanto al verificarsi di un evento?
Ti serve un "monitoraggio" continuo quindi o no?
ciao
coals
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 facilmente implementabile, richiede un maggior traffico sulla "rete". 
[...]
Con quella "mole" di dati io non ci penserei su: domanda e risposta.
La tua scheda centrale fa da master sul bus ed inizia sempre la comunicazione 
inviando ad una determinata scheda un comando di lettura (ovviamente nel 
pacchetto di dati ci sarà l'indirizzo destinazione della scheda sensore).
L'overhead di cui ti preoccupi sarà sicuramente trascurabile...

 Ti serve un "monitoraggio" continuo quindi o no?
Continuo, si tratta di telemetria.
Ciao!
Marco / iw2nzm

 L'overhead di cui ti preoccupi sarà sicuramente trascurabile...
Ok, in effetti c'è tutto il tempo per interrogare.
Dal punto di vista dei dati che ci passano sopra come mi consigli di 
organizzarli?
Finora ho sempre accrocchiato qualcosa (tutto funzionante!) ma vorrei 
fare una cosa seria....
Ad esempio l'inviare dati binari riduce di molto la lunghezza del 
pacchetto e consente l'uso immediato dei dati ricevuti ma impedisce 
l'uso di funzioni di manipolazione stringa e rende difficoltosa 
l'introduzione di caratteri terminatori (perché nel pacchetto - di 
lunghezza variabile - possono esserci occorrenze di \r \n \0 o del 
terminatore stesso).
Viceversa trasmettere il valore in "chiaro" come caratteri ascii, 
elimina il precedente problema, permette un debug immediato ma di contro 
richiede una doppia elaborazione sia in fase di trasmissione che di 
ricezione.
Ciao e grazie!
Marco / iw2nzm

 ricezione.
Secondo me dipende molto dalla potenza di calcolo che hai. Se i tuoi 
microcontrollori (slave e master) hanno il tempo di fare le conversioni in 
stringa, perchè non farle? Inutile avere micro che stanno lì senza fare nulla 
giusto per ottimizzare il numero dei dati da inviare, visto che, a quanto pare, 
sono comunque molto limitati.
Con una stringa ASCII terminata con un new line hai una semplicità di debug ed 
anche di gestione dei pacchetti in ricezione (devi cercare il carattere di new 
line per determinare la fine del pacchetto).
Se invece hai dei piccoli microcontrollori e non riesci a fare la conversione in 
stringa (in pratica, il tuo compilatore non ha o ha difficoltà a fare sprintf), 
allora va benissimo il protocollo binario. Sarà più difficile il debug, ma 
funziona uguale. La scheda centrale dovrà comunicare con il PC, quindi neanche a 
lei servono i dati già convertiti in testo, la conversione potrebbe farla il PC.
Di protocolli ce ne sono tanti e puoi passare da quelli completamente 
proprietari (binari e ASCII) a quelli più standard. Ma alla fine la cosa 
importante è che funzioni...

 importante è che funzioni...
Questo è poco ma sicuro!
Ciao e grazie
Marco / iw2nzm

Marco Trapanese ha scritto:

Questo penso potrebbe fare al caso tuo, che ne dici ?
http://www.grix.it/viewer.php?page=1530&bakto=%2Fshowpages.php%3Fnavipage%3D1