Bus RS485: come rilevare se bus occupato

Il giorno 9 May 2007 01:15:43 -0700, snipped-for-privacy@yahoo.com ha scritto:

mm, mi sa che non ci siano molte scorciatoie, o almeno io non ne conosco.

Di solito prima di trasmettere si mette la UART in ricezione e si analizza la comunicazione in modo da intervenire sulla linea solo quando è richiesto.

In un sistema multimaster può essere più problematico, ma se comunque si sa qual'è il master al momento, (anche il token ring prevede l'istruzione per modificare il master) la trasmissione del comando resta a lui. Poi si debbono gestire con i checksum e degli ACK o NAK (o timeout) dopo il comando eventuali errori o collisioni.

-- ciao Stefano

a la

o=2E

si sa

per

il

intanto grazie per la risposta, la mia idea magari banale era quella di polarizzare il bus con le resistenze di terminazione (bias resistors) ed utilizzare l'uscita RO del transceiver rs485 anche per analizzare la situazione. Qualcosa di simile a: " ....... se c'=E8 traffico sul bus ci sarnno variazioni di livello, se il bus =E8 sempre ad livello logico fisso =E8 probabile che la situazione sia bus libero o occupato (in funzione dei casi) ....". Il circuito dedicato che analizza RO dovrebbe poi avere un'uscita binaria del tipo 1=3Dbus_probabilmente_occupato

0=3Dbus_probabilmente_libero da collegare poi ad un ingresso dedicato del micro Insomma immagino che non sia semplice essere sicuri se il bus sia sicuramente libero o occupato ma se si riesce a determinare una condizione che aiuta =E8 meglio perch=E8 fra le altre cose evito di disturbare troppo comunicazioni attive In ogni caso prevedo di utilizzare la rianalisi del segnale trasmesso ed un crc per i pacchetti o un meccanismo di ack

qualche suggerimento o la mia =E8 un'idea strampalata?

grazie

simile al valore

ha scritto nel messaggio news: snipped-for-privacy@w5g2000hsg.googlegroups.com...

Lasci la parte relativa alla ricezione sempre attiva. Quando trasmetti, verifichi di ricevere esattamente ciò che trasmetti. Quando rilasci il bus, verifichi l'esattezza di ciò che hai trasmesso, cancelli il buffer e ti metti in ricezione. Se ciò che ricevi non è ciò che hai trasmesso, attendi un tempo casuale (di solito un offset fisso + un tempo legato all'indirizzo della periferica) e poi se è passato un minimo di tempo dall'ultima ricezione (=bus libero), riprovi a trasmettere.

Un rilevamento di questo tipo potrebbe portare a problemi legati ai tempi di propagazione con:

- bus estremamente lunghi (la 485 può arrivare a oltre 1000m)

- velocità elevate

- pacchetti molto corti (pochi bytes).

Io adotto questa soluzione da diverso tempo con drivers SN75176BN, velocità

19200 con bus max 200m e fino a 28 periferiche senza problemi.

Roberto P.

g2000hsg.googlegroups.com...

uale (di

o),

di

t=E0

a mio avviso il problema di qusto tipo di approccio =E8 che: quando ho una collisione (rilevata con un valore tx !=3D valore ricevuto) il messaggio trasmesso non =E8 ovviamente valido ma di fatto distruggo anche il messaggio con cui ho fatto una collisione e quindi devono ritrasmettere in due. Per evitare una nuova collisione dovrei, come suggerivi tu, inserire un timer di attesa legato all'indirizzo del modulo+un tempo fisso di fatto pari almeno alla grandezza del pi=F9 grande pacchetto in rete =3DTmax.

vorrei se possibile evitare di aspettare un tempo =3DTmax + t perch=E8 ho un caso in cui il pacchetto =E8 lungo 500byte se non di pi=F9 (aggiornamento firmware etc) e per un solo caso fra l'altro raro non volevo penalizzare tutto il timing.

la mia idea =E8 quella di cercare di rilevare la condizione di traffico in rete da un punto di vista elettrico con l'idea di dire: .=2E........se ci sono almeno 10 Byte =3D0 (situazione non impossibile ma di fatto improbabile) allora Bus libero (es un driver con un circuito di scarica). In questo caso meglio attandere 10byte che 500.

questo =E8 il motivo per cui cerco di costruire una specie di rilevatore di stato bus per il quale chiedo il consiglio, ma in ogni caso grazie comunque per i suggerimenti

[...]

Quello che ti ho suggerito non è di trasmettere alla cieca e verificare se in seguito se è andato a buon fine... Dovresti invece prima verificare se il bus è libero utilizzando la parte di ricezione (non ti serve altro hw). Se ricevi qualcosa il bus è per forza occupato. Ogni byte che ricevi azzeri un timer. Quando è passato un tempo di guardia che ritieni opportuno (suggerisco dipendente dall'indirizzo, in modo da avere sempre tempi differenti per ogni periferica) assumi il bus come libero e inizi a trasmettere. Se però 2 periferiche iniziano a trasmettere nello stesso tempo, se non implementi anche ciò che ti ho suggerito, comprometti in ogni caso entrambi i messaggi...

Roberto P.

g2000hsc.googlegroups.com...

se

e di

gni

ambi

grazie per il consiglio. scusa l'ignoranza giusto per capire: nella pratica suggerisci di ascoltare il bus prima di trasmettere e se non si riceve niente allora si prova a trasmettere con le indicazioni che dicevi tu gusto? in pratica il rivelatore di traffico sul bus si realizza semplicemente ascoltando il bus per un po giusto? quindi devo polarizzare il bus per evitare lo stato di idle indefinito (che potrebbe generare false indicazioni) =E8 corretto? scusa per la pazienza ma mai fatto niente sul rs485 per ora ho solo letto qualcosa :-)

volevo evitare di fare prove senza capire prima. (sai con due bimbi il tempo libero =E8 una risorsa rara) grazie per i consigli

[...]

Se lasci la ricezione sempre attiva riesci effettivamente a minitorare tutto ciò che transita. Quando per qualche decina di ms non vedi transitare nulla, significa che la trasmissione è terminata e valuti se iniziare tu a trasmettere. Quando trasmetti, esegui anche un monitor della ricezione, se alla fine i checksum di tx e rx sono differenti significa che c'è qualche anomalia sul bus e valuti quando ritentare la trasmissione. Le mia applicazioni con la 485 prevedono una polarizzazione e una terminazione distribuita. Ogni periferica ha cioè una resistenza di pullup su A+ ,un pulldown su B-, una terminazione fra A+ e B-. In più come protezione una coppia di zener da 6V8 fra A+ e gnd e una coppia fra B- e gnd (A+ .. catodoD1.. anodoD1..anodoD2..catodoD2..GND, stessa cosa per B-).

Stai parlando con uno che di figli ne ha 3, oltre ad una attività da portare avanti.... Quella coppia di parole che hai scritto t...o l....o, io non so nemmeno leggerle ;-)

Roberto P.

Il giorno 9 May 2007 05:58:15 -0700, snipped-for-privacy@yahoo.com ha scritto:

Alcuni drivers RS232 >> RS485 incorporano già una funzione simile per evitare di dover usare il filo RTS\ della porta, tipo questo:

Dovresti prevedere una logica che tenga conto della durata della parola e riconosca lo start bit, un µC con la uart per fare quello

No, l'idea è buona e non e nemmeno nuova, ti ricordo che i bus di campo su RS485 come il ProfiChip hanno un firmware incasinatissimo proprio per superare il problema del data collision non facendo un semplice master-slave.

Io personalmente credo sia molto più semplice una normale architettura master-slave, mafari con la possibilità di cambiare il master magari dall'indirizzo 1 all'indirizzo 10 ma sempre con un master solo. Se lo slave non risponde entro un dato timeout rimandi il messaggio, dopo 3 tentativi senza risposta lo togli dagli indirizzi attivi, salvo poi fare una scansione ogni tanto per vedere se ci sono nuovi arrivi.

-- ciao Stefano

co.

izza la

esto.

que si sa

ne per

opo il

vitare di

su RS485

il

3

una

grazie per i suggerimenti ne far=F2 uso prezioso ciao alessandro