Segnali, seriali e protocolli eventuali....

Salve a tutti i componenti del forum

E' da pochissimo che mi sono iscritto e da qualche tempo a questa parte, ho acquistato la scheda "Arduino UNO" con un po' di shield (GSM, ETHERNET, RELE') che ho già utilizzato per piccoli esperimenti.

Adesso mi sto trovando di fronte ad un piccolo, ma grande problema, almeno per le mie conoscenze che mi sta facendo riflettere, sulla scelta eventuale, di utilizzare o meno, un protocollo di trasmissione e ricezione, per far comunicare più dispositivi, attraverso un BUS dati. Le mie domande sono semplici e spero che lo siano anche le eventuali risposte. In sostanza, come far comunicare più dispositivi seriali che non utilizzano un protocollo di comunicazione, ma solo di un collegamento seriale? Vedi ad es.: display, sensori, dispositivi di vario genere. Se in un progetto avessi bisogno di far comunicare 10 display lcd e altrettanti sensori, mi troverei costretto ad utilizzare un protocollo seriale? Se si, quale? "I2C" o "RS485"? Leggevo che "I2C" è sensibile alle interferenze esterne e quindi il BUS dati, potrebbe interpretarle come comandi, o falsare letture eventuali e se questo fosse vero, converrebbe utilizzare in partenza un protocollo meno "sensibile" come "RS485"? Come ultima domanda, si può convertire un collegamento seriale standard, in un altro, magari utilizzando i protocolli sopracitati e convogliando tutto, in un BUS dati ed indirizzando i segnali, sulla linea BUS e definendo a priori gli indirizzamenti?

Salve a tutti e buona Domenica

L'I2C gestisce già da sé la presenza di master e slave sul bus ma lavora sulle piccole distanze (decine di cm), l'RS485 è una semplice estensione del bus seriale per cui esiste un master che "parla" e gli altri che ascoltano ma può lavorare sulle grandi distanze.

I problemi di una comunicazione seriale sono che se un dispositivo impegna il bus, nessun altro può impegnarlo in trasmissione. Devi quindi implementare un protocollo affinché solo 1 dispositivo impegni il bus in un dato momento ed un modo per sbloccare il bus nel caso un dispositivo che lo impegna si "pianti".

Ma tu su che distanze devi lavorare? Che tipo di dati devi far transitare da un dispositivo all'altro? Quali saranno questi dispositivi che dialogheranno tra di loro?

Salve Leo72 e grazie per la tua dispinibilità,

Sostanzialmente devo realizzare una centralina che equipaggerà due lettori RFID e quindi i dati relativi, saranno principalmente dei TAG numerici ed in seconda istanza un display a 4 righe LCD.E qui che mi sono trovato in difficoltà, perchè tutti questi dispositivi, comunicano tramite bus seriale e non sfruttano un protocollo di trasmissione e ricezione; i vari progetti e tutorial che ho trovato, prendono come esempio, le singole istanze di trasmissione e ricezione dati, ma se uniamo questi tre componenti seriali che non sfruttano nessun protocollo, le cose, almeno per me, si complicano e non riesco a trovare una via d'uscita, di sicuro a causa della mia scarsa esperienza in questo contesto.Poi mi sono concentrato su dei progetti realizzati che sfruttano dei sensori di temperatura "I2c" nativi e che hanno un loro indirizzo HEX, chiedendomi del perchè componenti come RFID, non hanno questa caratteristica e di conseguenza la mia ricerca si è spostata su adattatori eventuali "i2c", o ad un qualcosa che attribuisca degli indirizzi, ai dispositivi collegati sul BUS dati, ma ho paura d'iniziare a sbagliar strada e sono quindi giunto su questo forum, in cerca di delucidazioni eventuali.

Ancora grazie Leo per la tua disponibiltà :)

Non hai però risposto alla mia domanda: su che ordine di grandezza ragioniamo per le distanze? Come ti ho detto l'I2C va bene per qualche decina di cm, al max diciamo un metro, ma poi dipende dai dispositivi collegati. Come hanno detto anche altri sul forum, è stato concepito per far dialogare dispositivi presenti sulla stessa scheda madre.

Se sono RFID immagino che quindi i primi dagli ultimi disteranno metri.

Si, hai ragione e per l'appunto, i dispositivi RFID, potrebbero distare all'incirca, dai 6 ai 10 metri, rispetto al circuito principale, il display è montato direttamente sulla scheda assieme al keypad.

Beh, se ragioni su metri devi usare l'RS485.

Ciao, in base ai tuoi suggerimenti, ieri mi sono messo a cercare un po' di info, per approfondire "RS485", l'ultima cosa adesso rimane e di far comunicare un dispositivo, non progettato per "RS485", ma che comunica solo tramite seriale. Pensi che l' integrato "MAX485" possa andar bene al mio scopo, oppure ci sono delle alternative? Saluti e grazie di nuovo.

Intanto ti suggerisco il 75176, è equivalente al MAX485 ma costa di meno ed è meno sensibile ai disturbi sulla linea. Questi integrati altro non fanno che "estendere" il concetto di seriale: hai un pin in uscita, un pin in entrata. Un terzo pin serve per commutare il dispositivo su RX/TX. Siccome i segnali RX/TX del micro sono inversi (RE e /DE), puoi collegarli ad un solo pin in parallelo: mandandolo HIGH attivi la ricezione, mandandolo LOW attivi la trasmissione. Su Arduino colleghi poi i segnali R e D ai pin RX e TX.

Cosa dovresti poi comandare esattamente?

Beh. più che comandare, per adesso dovrei solo inviare dei tag tramite "RFID" ad Arduino che poi piloterà dei relè eventuali, allarmi, segnali trasmessi dal SIM900, devo ancora vedere cosa fare, ma per me era di fondamentale importanza, interfacciare tutti i dispositivi con un adattatore, in questo caso mi consigli il 75176 che proverò sicuramente, nel frattempo mi sto già leggendo il datasheet :)per me non sarà tanto facile all'inizio, perchè per adesso, mi sono limitato a gestire singole istanze e qui mi si apre un mondo nuovo con "RS485" che ho visto utilizzare, di solito, in ambiti professionali e per la comunicazione di dispositivi industriali.

Volevo sapere cosa ne pensi dei moduli Xbee, stavo prendendo in considerazione anche quelli. Ciao

Mai usati. Ma io sono un po' contrario alle onde radio quando si possono tirare 2 fili. Magari qualcun altro te ne decanterà le doti ma con il bus RS485 i problemi di interferenze sono ridotti al minimo.

Cmq tu avrai quindi un'unità centra che spedirà i comandi alle unità periferiche. Anche l'unità centrale sarà un Arduino?

Si esatto, solo che stavo guardando un po' di tutorial, ma non capisco alcune cose, ad esempio, con il protocollo "I2C" ogni periferica aveva un indirizzo in HEX e le periferiche si collegavano in parallelo, per un massimo di 127 dispositivi, ma con "RS485" il collegamento, si effettua sempre in parallelo? Bisogna utilizzare una resistenza di terminazione? E chi definisce l'indirizzo? L'integrato, mi sembra di capire, serva solo per estendere la portata della seriale e tramite un bit di controllo, si decide di trasmettere o ricevere, ma mi manca la parte d''indirizzamento verso i dispositivi, a meno che non si utilizzino tanti processori Atmega328, quanti "75176"? Spero di non averle sparate grosse. Ciao

Uhm... ma allora non hai anche degli Arduino (o comunque dei 328) a gestire i vari RFID?

Per adesso ho solo un Arduino UNO, ma avevo acquistato dei 328, con i relativi quarzi e condensatori, con l'intento di utilizzarli alla fine del progetto, ma adesso mi sembra di capire che mi serviranno per gestire le linee di comunicazione con "RFID" :).

Esattamente XD Quando si dice un acquisto oculato ;)

Ogni terminale avrà quindi il suo lettore RFID, ogni terminale sarà connesso al bus RS485. Ogni Atmega di ogni terminale avrà preprogrammato in EEPROM (o nel codice stesso) l'ID personale con cui la centralina identificherà i vari nodi. Quando la centralina dovrà spedire un comando ad un particolare terminale, non dovrà far altro che iniziare la trasmissione con un carattere speciale, poi far seguire l'ID del dispositivo con cui vuole comunicare, poi inviare il comando e gli eventuali dati accessori e terminale la trasmissione con un carattere di chiusura.

Tutti i nodi riceveranno i dati ma solo quelli a cui saranno "destinati" eseguirà il comando

Beh forse da un certo punto di vista qui "vince" il protocollo "I2C" infatti, se non ho capito male, ogni dispositivo può essere collegato in parallelo sul bus dati e gli indirizzi sono definiti a priori, o impostabili tramite jumper in certi casi e senza la necessità di "sprecare" processori su ogni linea :)

Adesso mi hai dato tutte le risposte che cercavo, ma il mio progettino si è un tantino complicato eheh, di conseguenza acquisterò altri atmega:)

grazie ancora per le preziose info che mi hai dato.

Ma l'I2C, come ti ho detto, ha il problema della distanza. Qualche decina di cm. E' nato per far comunicare dispositivi sulla stessa scheda. Certo, se hai dispositivi che comunicano in I2C è un bel vantaggio perché anche un sensore può essere interpellato e rispondere con i dati, avendo la circuiteria interna per fare ciò senza bisogno di "assistenza" esterna. Ma tu hai il problema della distanza.

E cmq così crei dei terminali "intelligenti".

Si beh certo, ho assimilato il concetto di RS485=lunghe tratte e senza interferenze, ma nel contempo, mi dispiace aver abbandonato, per questo progetto, “I2C”, per la sua comodità d’ implementazione, visto che non richiedeva ulteriori componenti :)d’altra parte come dici giustamente, aver un processore per BUS dati, ne fa sicuramente un sistema più robusto e configurabile. Col tempo imparerò ad apprezzarne tutte le potenzialità, ma tutto si legherà anche, ad un abilità sulla programmazione che sto cercando di far crescere piano piano:)

Ciao, ho acquistato i 75176, ma ho un piccolo dubbio in merito alla resistenza di terminazione, tu cosa mi consigli? In base ai datasheet e a qualche progettino in rete, ho visto utilizzare delle resistenze da 100 - 120 ohm.

RICAPITOLANDO: dovrei utilizzare due 75176, collegati ai relativi Atmega328, in configurazione "MASTER" e "SLAVE", i dispositivi RFID, si collegano agli atmega e l'anello si chiude, con la resistenza di terminazione. Il software deve essere fatto ad HOC, per gestire correttamente il flusso dati TX ed RX, senza che i dispositivi collegati, interferiscano tra di loro.

Spero che alla fine riuscirò a far funzionare qualcosa:)