Protocollo

[marnic]

RS232, 485, CAN, EIB, I2C, MODBUS.......
insomma, come le vogliamo far comunicare ste schede e oltre al livello fisico (tensioni numero di fili ecc.) quali sono i messaggi che si devono scambiare?

Volontari?

[calo]

Orginalmente inviato da marnic

RS232, 485, CAN, EIB, I2C, MODBUS.......
insomma, come le vogliamo far comunicare ste schede e oltre al livello fisico (tensioni numero di fili ecc.)

perdona l'ignoranza, ma rs232, rs422 o rs485 sono solo il livello fisico, mica sono il protocollo? CAN, I2C, MODBUS invece sono protocolli, dico bene?

[astrobeed]

Orginalmente inviato da calo

perdona l'ignoranza, ma rs232, rs422 o rs485 sono solo il livello fisico, mica sono il protocollo? CAN, I2C, MODBUS invece sono protocolli, dico bene?

Anche l'I2C non è un protocollo, le specifiche descrivono solo il mezzo trasmisssivo e come devono codificati i dati, poi come protocollo software ci metti quello che vuoi, p.e. il modbus.

[marnic]

Ok, era per dare il via alla discussione, il punto era ed è: volontari?

[astrobeed]

Orginalmente inviato da marnic

Ok, era per dare il via alla discussione, il punto era ed è: volontari?

Fino a che non definiamo le specifiche di base dell'hardware e del bus è difficile stabilire quale protocollo usare, però ti dico subito evitiamo di impegolarci con cose troppo complesse perchè nel nostro caso non servono.
Il protocollo deve essere semplice da implementare e snello da gestire.

[fiser]

usare la seriale mi pare la cosa più ovvia..... poi se implementata via radio o via rs485 o altro deve essere a libera scelta

[selfservice]

credo si parli del protocollo e interfaccia fisica per connettere tutte le schede varie

io dico SPI perchè ci sono una marea di integrati giÃ* fatti che fanno le peggio funzioni, solo che c'è il problema del chip select, ci vorrebbero 3 fili più N fili quante sono le schede, ma si arriva anche a 20mbit

altrimenti RS485, tanti megabit, fino a 32 schede, ma ci vuole necessariamente un micro per ogni scheda, cosa che comunque era quasi prevista...

[astrobeed]

Orginalmente inviato da fiser

usare la seriale mi pare la cosa più ovvia..... poi se implementata via radio o via rs485 o altro deve essere a libera scelta

Stiamo parlando del bus di comunicazione tra le schede, con la seriale pura e semplice non ci fai nulla.
Il bus deve essere multidrop pertanto le scelte possibili sono tre, I2C, RS485, CAN.

[nonno_62]

Mi pare che abbiamo giÃ* deciso rs485 ... mi vado a cercare come funzia

Per il protocollo direi

chiamante:
1) indirizzo --> credo basti un byte, al limite due volte lo stesso indirizzo per prevenire errori
risposta:
1) indirizzo --> come sopra se errore basta non rispondere

chiamante
1) dati --> credo che si possa pensare ad un numero fisso di byte oppure ad un primo byte che indica quanti seguono.
2) byte di controllo ---> un semplice algorimo per verificare se i dati sono corretti
risposta:
1) byte di controllo se errore basta non rispondere

per il timing vediamo .....

la rs485 prevede il multimaster? nel senso se una periferica ha bisogno comunicare una notizia importante e urgente puÃ* prendere la linea? e le collisioni a livello hardware come sono risolte? o ci deve essere sempre una scheda (master) che chiede a tutti come va? in i2c si usa una linea di interrupt collegata al master ... è perseguibile come strada?

saluti Nonno

[astrobeed]

Orginalmente inviato da nonno_62

Mi pare che abbiamo giÃ* deciso rs485 ... mi vado a cercare come funzia

Per il momento non è stato deciso nulla, i candidati possibili sono I2C, SPI, RS485, ognuno di questi sistemi ha i suoi pregi e i suoi difetti.

Per il protocollo direi
chiamante:
1) indirizzo --> credo basti un byte, al limite due volte lo stesso indirizzo per prevenire errori
risposta:
1) indirizzo --> come sopra se errore basta non rispondere

Ok farlo semplice ma così è un po troppo
Il sistema da te descritto può andare benissimo fino a che devi far discutere tra loro due-tre schede di cui a priori tutto quello che serve, inteso come tipo di dati e flusso.
Nel nostro caso abbiamo un sistema che potrÃ* comprendere molte schede, anche più di dieci, nella sua versione "de luxe", schede delle quali non si ancora nulla, o quasi, pertanto tocca prevedere un protocollo che sia si semplice ma anche flessibile che non tocchi buttarlo via domani perchè non regge il sistema.
In tutti i casi studiati la RS485 perchè sicuramente prima o poi ti servirÃ*, in ambito industriale è usatissima.

la rs485 prevede il multimaster? nel senso se una periferica ha bisogno comunicare una notizia importante e urgente puÃ* prendere la linea? e le collisioni a livello hardware come sono risolte? o ci deve essere sempre una scheda (master) che chiede a tutti come va? in i2c si usa una linea di interrupt collegata al master ... è perseguibile come strada?

Le specifiche RS485 descrivono solo il mezzo trasmissivo e le sue caratteristiche tecniche, per quanto riguarda il protocollo software puoi fare quello che vuoi.
La RS485 di base la puoi considerare come un BUS bifilare half duplex multidrop, cioè più device si connettono in parallelo sullo stesso cavo e parlano uno per volta.
Le collisioni non sono possibili perchè chi trasmette prima deve controllare l'impegno della linea, solo se è libera puoi trasmettere.
Poi se usi un sistema master/slave oppure multimaster quella è solo una tua scelta.
Quando parli di eventi urgenti questi devono sempre essere rapportati al timing del bus e il tempo di latenza massimo.
Detto in altre parole l'unitÃ* collegata al bus, qualunque esso sia, deve essere in grado di gestire autonomamente qualunque evento per un tempo comparabile al delay massimo introdotto dal mezzo trasmissivo e dalla latenza.