interrupt generato dal distacco del cavo seriale

Il 03/02/2010 10.10, stinf ha scritto:

Quando si sveglia di soprassalto ancora mezzo assonnato, prima di fargli suonare la carica visualizzando il messaggio, fagli prendere una camomilla e verificare che sia davvero arrivato un pacchetto dati. In caso contrario può tornare a dormire pacificamente.

Si, è molto facile.

Non credo che l'utente sia proprio contento di dover rispettare una procedura del genere per evitare di disturbare il micretto a riposo.

I "rimbalzi" dovuti alla connessione dei cavi credo. Cercare di eliminarli fisicamente la vedo abbastanza macchinosa come soluzione. Cercherei piuttosto di intervenire sul firmware rendendolo appunto un po' più intelligente. Del resto un disturbo sulla linea o un pacchetto di dati corrotto può sempre capitare (anche se in condizioni normali la probabilità è pressoché 0) e il programma non deve risentirne.

Marco

:)

In effetti è probabile che sia l'unica soluzione. La scocciatura per l'utente è il dover mandare due messaggi consecutivi (il PIC spegne il baud rate generator durante il sonno, e si sveglia a causa di una transizione alto/basso sul pin di ricezione seriale...), ma ovviamente questo può farlo il sw di gestione.

In effetti, sarebbe alquanto fastidioso.

Hai ragione, mi sa che mi orienterò su questa soluzione.

Grazie dell'aiuto.

stinf:

Se prendi esempio dal NMEA 0183, vedrai che tutti i messaggi iniziano con un carattere ('$') e terminano con un checksum che non comprende il carattere iniziale.

E' invece abbastanza banale: basta mettere un pull-up sulla linea che, in stato di "space" è alta ed un pull-down su quella che è bassa.

Mi hai letto nel pensiero... solo attenzione ad eventuali pull-up inseriti dal micro stesso (interni), che non conosco e potrebbero non esserci, quindi controlla e se sono in conflitto con quanto suddetto toglili.

ciao giorgio

Il 03/02/2010 10.19, Marco Trapanese ha scritto:

terza tavola, undicesimo comandamento.

saluti

--=20 lowcost

"Rusty" ha scritto nel messaggio news:pLfan.20489$ snipped-for-privacy@twister2.libero.it...

Ah, aggiungo che cmq è meglio rinforzare anche l'immunità software ai disturbi come è stato consigliato, un sistema con un'interrupt sui fronti della 485 non l'avevo mai immaginato:-DD riciao

"F. Bertolazzi" ha scritto nel messaggio news:1onwrn8nlrdd2$.1orxc5deik9fe$. snipped-for-privacy@40tude.net...

Questo è uno dei punti chiave di una RS485, essa DEVE essere polarizzata checchè ne dica il mondo, e ti dirò di più DEVE avere una massa o cmq un'equipotenziale fra i dispositivi, una o entrambe queste cose non soddisfatte generano funzionamenti anomali e spuri.

La DDP fra i due ingressi di un dispositivo RS485 in un sistema bidirezionale deve essere superiore ai 200mV pena avere funzionamenti toggle di molti driver:-)))

Mentre le terminazioni a 120 ohm sono sconsigliate, a meno che la linea non superi le centinaia di metri e la velocità di trasmissione sia superiore ai

Tutte cose provate sulla mia pelle e poi confermate da letture varie:-) ciao Rusty

Il giorno Wed, 03 Feb 2010 14:26:24 GMT, "Rusty" ha scritto:

In caso di spurie, la UART percepisce uno start bit che determina l' inizio delll'acquisizione di un carattere e quindi alla fine sarà comunque generato un'interrupt, ma la mancanza di uno stop bit al momento giusto sarà poi la causa di un FRAME ERROR che le UART appena decenti rilevano, non so quale sia la situazione dei pic.

Cooncordo sulla necessità di una polarizzazione in modo che la linea anche aperta sia ad un potenziale definito, riguardo alla resistenza di terminazione qualcosa è meglio mettere comunque, anche se non sono proprio 120 ohm ma qualcuno di più è lo stesso alle basse velocità.

-- ciao Stefano

Metterci uno snapper sulla linea ci permette di peccare?

Boiler

Il 03/02/2010 18.19, Boiler ha scritto:

sorry, sei troppo profondo, non ti capisco.

saluti

"SB" ha scritto nel messaggio news: snipped-for-privacy@4ax.com...

Be si io metto delle 10K , considera che in sistemi con decine di schede in parallelo poi tutto ciò carica la linea sia le polarizzazioni che altro ciao Rusty

Rusty:

Io le metto da 470 tra A e B, più 4,7k verso VCC e GND, ma solo agli estremi del bus, volanti sulle morsettiere (estraibili).

Rusty:

Dipende. Gli AVR si svegliano dal sonno più profondo (che disabilita le periferiche) solo con un pin change. Il carattere di sincronismo iniziale ha di bello il poter essere ignorato.

SB:

causa

Gli AVR lo segnalano, ma io lo ignoro, non metto la parità e mi fido solo del checksum. Già per pacchetti di pochi byte è più economico (sulla linea, non la CPU) e sicuro.

lowcost ha scritto:

Questo è uno snapper:

L'inverter di destra è costruito con transistor "mosci". In questo modo, lo attacchi alla linea e lui prende lo stato logico della linea.

Se la linea viene disconnessa dal driver o questo passa ad uno stato di alta impedenza, lo snapper la mantiene al livello precedente.

Boiler

Il giorno Thu, 4 Feb 2010 08:51:05 +0100, "F. Bertolazzi" ha scritto:

Io invece controllo anche il FRAME ERROR, e in un applicazione dove le risorse me lo permettono incremento una locazione di memoria ogni volta che ci sono errori, questo mi permette di vedere facilmente la qualità della linea.

-- ciao Stefano

SB:

Io uso solo linee bilanciate. Da quella volta che ho fatto passare 1 Mb/s su di una coppia di un rocchetto di cavo da 100 metri mentre con le altre coppie alimentavo un grosso trapano, mi fido ciecamente. ;-)

Interessante, questa non la sapevo... Motivo di ciò? Grazie Guido

Il 04/02/2010 10.49, Boiler ha scritto:

ah, ora l'ho capito.

la risposta alla tua domanda e': no, lo snapper risolve solo un problema, che in questo caso non e' rilevante.

saluti

--=20 lowcost