Newsgroup: it.hobby.elettronica.digitale
Titolo: !!!!!!!! ANTI-COLLISIONI SUI BUS SERIALI  ---HELP ME---

Salve,
c'e' qualcuno che mi puo' aiutare a trovare una soluzione per gestire via
software le possibili collisioni nel trasferimento di dati fra periferiche
collegate ad un stesso bus?
Per essere pi? preciso:  devo gestire in remoto tramite una seriale tipo
RS485 (con dei PIC), circa 20 alimentatori piu' altre 8 periferiche.
Per vari motivi, che ora non sto' ad elencare, non devo vincolarmi ad un
sistema gestito da una periferica Master ma devo lasciare ad ognuno la
possibilit? di scaricare dati sul bus in maniera asincrona: da qui
l'esigenza di trasmettere solo quando la linea e' libera dovendo pero'
accorgermi se si sono verificati conflitti dovuti al fatto che piu'
periferiche trasmettono contemporaneamente.
Io qualche idea me la sono fatta, ma vorrei confrontarla con qualcuno che ne
s? piu' di me'.
Grazie
Claudio

 s? piu' di me'.
soluzione classica è quella di trasmettere quando il bus è vuoto e
(mentre si trasmette su TX) confrontarlo con quello che si riceve su RX.
Se ricevi qualcosa di diverso da quello che hai trasmesso allora hai avuto
collisione.
Io preferirei un arbitraggio preventivo del bus ma se hai problemi di
performance non è preferibile.
Ciao

performance non è preferibile.
Un altra soluzione potrebbe essere irrobustire il protocollo, con
inserimento di Indirizzo Origine, Destinazione e BCC.
STX, AddOR, AddDST, .....,ETX,BCC
a cui fai corrispondere un ACK verso AddOR
STX, AddOR, AddDST, ACK, ETX, BCC
ma è abbastanza incasinata come gestione.
Un altra potrebbe essere ritardare una comunicazione di un numero di
msec corrispondenti all' indirizzo del dispositivo.
Per esempio il dispositivo num.4 inizia la comunicazione da master
dopo 4 msec. di silenzio sul bus, il num.6 dopo 6 ecc.
Lo slave deve rispondere subito o entro un tempo minimo inferiore al
master più basso.
Si perde un po di tempo, ma si riduce drasticamente la possibilità di
collisioni e ritrasmissioni che seguono e la gestione sofisticata di
errori che rallenta comunque la comunicazione .
Io avevo fatto una cosa del genere anni fa e funzionava abbastanza
bene.
ciao
  Stefano

 performance non è preferibile.
Cosa intendi per arbitraggio preventivo?

 collegate ad un stesso bus?
Ti consiglio di darti al CAN bus, lě č tutto risolto via hardware se
utilizzi
un micro o un transceiver apposito.

 errori che rallenta comunque la comunicazione .
Anche qui dipende da che tipo di traffico hai sul bus. Se il master con
indirizzo più basso vuole trasmettere una grande quantità di dati, rischia
di monopolizzare la rete e di non permettere agli altri di trasmettere
mai.

mai.
Se monopolizza la rete solo un dispositivo allora non basta la banda o
il baud rate, sono altri problemi.
Comunque era solo accademia....
ciao
  Stefano

 RS485 (con dei PIC), circa 20 alimentatori piu' altre 8 periferiche.
Di solito i driver per RS485 hanno un segnale che indica la collisione
ossia una situazione di bus contention.
Quando avviene una collisione, i due o più dispositivi che vorrebbero
trasmettere un messaggio sospendono la trasmissione per x
microsecondi, dove x è un tempo casuale, e quindi ritentano.
E' un sistema semplice anche da realizzare in software, ed è anche
abbastanza efficiente se il bus non è molto occupato. Purtroppo non
garantisce il tempo massimo per la trasmissione di un messaggio.
In alternativa potresti usare un algoritmo del tipo token ring, in cui i
dispositivi, a rotazione e in un ordine prestabilito, trasmettono un
messaggio, anche solo per dire che non hanno niente da trasmettere.
E` un metodo meno efficiente e più impegnativo in termini di cpu se
viene realizzato in software, ma in questo caso hai un tempo massimo
garantito per la trasmissione di un messaggio.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

collisione.
Questa a me sembra la soluzione piu' semplice
Peraltro trovi anche un ottimo esempio gratuito sulla rete
Basta che cerchi e ti vedi per bene la picnet di Tanzilli
E' un progetto che se mi ricordo bene non ha mai portato a termine e
quindi c'è qualche piccolo baco ma ti posso assicurare che se te la
vedi per bene e correggi i difetti funziona egregiamente e gestisce
per bene le collisioni, supportando anche algoritmi di controllo dei
pacchetti con l'utilizzo di un crc su ognuno di essi


E' da un po che cerco un protocollo software proprio come serve a
te. Possibilmente sicuro gią collaudato ma č una ardua impresa.
Ho trovato questo che dalla descrizione sembra perfetto :
http://yaspnet.sourceforge.net/
perņ mi sa che nessuno a parte l'autore (forse) l'ha mai testato e
metterci mano come al solito č un casino.
Ciao

 ossia una situazione di bus contention.
Sicuro ?
Mi fai un esempio ?
Ciao
Paolo


Sicuro al 100% proprio no, era venuto un dubbio anche a me
ma non riesco a trovare il databook dei line driver.
Appena lo trovo confermo o smentisco quanto detto. ciao



Il DS3695 ha un uscita TS\ che dovrebbe indicare il thermal shutdown
del dispoditivo.
Dubito però che si possa utilizzare per gestire un bus collision,
anche perchè dipende dalla temperatura ambiente.
http://www.national.com/ds/DS/DS3695.pdf
ciao
  Stefano

 
http://www.national.com/ds/DS/DS3695.pdf
Ho trovato il databook. Si tratta del DS3696 e non 3695.
Il pin 3 veniva chiamato ~LF, cioe' Line Fault e indicava una condizione
anomala sulla linea come nel caso di un conflitto o collisione.
Ora ho visto che nel datasheet attuale il segnale ha cambiato nome
e si chiama ~TS, cioe' Thermal Shutdown, e questo cambiamento
e' evidenziato nella figura della prima pagina.
Non so dire se il cambiamento del nome corrisponda anche ad un
cambiamento del circuito interno, il datasheet non dice niente.
Bisognerebbe provare direttamente su un circuito.
