Discussione: Protocollo
Visualizza messaggio singolo
  #10  
Vecchio 26-08-2006, 10.01.05
L'avatar di astrobeed
astrobeed astrobeed non è collegato
Robottaro sostenitore
 
Data registrazione: 18-03-2004
Residenza: Roma
Etŗ†: 59
Messaggi: 3,377
Potenza rep: 346
astrobeed La sua reputazione Ť oltre la sua famaastrobeed La sua reputazione Ť oltre la sua famaastrobeed La sua reputazione Ť oltre la sua famaastrobeed La sua reputazione Ť oltre la sua famaastrobeed La sua reputazione Ť oltre la sua famaastrobeed La sua reputazione Ť oltre la sua famaastrobeed La sua reputazione Ť oltre la sua famaastrobeed La sua reputazione Ť oltre la sua fama
Predefinito

Citazione:
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.

Citazione:
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.

Citazione:
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.
__________________
Bye