pic -> 485 -> bus -> 485 -> 232 -> pc

"Andrea" ha scritto nel messaggio news: snipped-for-privacy@uni-berlin.de...

sto'

(che

(ho

materiale

Immagino che tu sia RS485 a 2 fili, utilizzati sia per la ricezione che per la trasmissione. Quindi devi lavorare in half duplex, ovvero devi alternare la trasmissione e la ricezione agendo sul pin di abilitazione ricezione/trasmissione del max485 (RE e DE). Normalmente si abilitano i drivers in ricezione, quindi collegando con un pulldown entrambi i pin RE e DE. Quando una periferica deve trasmettere alza i suoi pin RE e DE e dopo un piccolo ritardo di assestamento linee inizia a trasmettere. Alla fine della trasmissione, quando tutti i dati sono stati effettivamente spediti (e non quando sono stati inviati al buffer di trasmissione), si attende un altro piccolo ritardo e poi si rimette il driver in ricezione per una eventuale risposta. I pin RE/DE dal lato pic li colleghi ad un pin libero che provvederai a comandare opportunamente. Dal lato pc normalmente si abilita la trasmissione utilizzando il pin RTS (anche qui comandato a basso livello prima e dopo la trasmissione, facendo attenzione alla temporizzazione di fine messaggio). Oppure per facilitare il tutto (ma raddoppi il cablaggio), vai in full duplex, aggiungendo un max485 sia dal lato pic che dal lato pc. Lasci così la ricezione sempre abilitata sia su pic che su pc, e provvedi ad abilitare solo la trasmissione quando necessario. In questo caso il cablaggio lo dovrai fare collegando TX+(pic) > RX+(pc), TX-(pic) > RX-(pc),

RX+(pic) > TX+(pc), RX-(pic) > TX-(pc). Inoltre, anche se a volte va tutto anche senza, consiglio di mettere le resistenze di terminazione e i pullup/pulldown sulle linee bilanciate.

Ciao, Robby

per

Esatto (scusa, non l'ho precisato) il sistema che intendo utilizzare è un half duplex su 2 fili

Io invece RE lo lascio sempre abilitato e mi limito ad abilitare DE solo nel momento in cui devo trasmettere... Ma non credo che potrebbe essere questo il mio problema, o sì?

"ritardo di assestamento"? ? ? Ops, ho come l'impressione che non aver valutato questa cosuccia potrebbe comprometterne il funzionamento...

effettivamente

per

Altra cosuccia che non ho debitamente considerato!

Anzichè l'RTS il utilizzo il DTR (se non ricordo male!) Il problema è che io controllo la seriale utilizzando MSComm.ocx (un ActiveX fornito dalla Microsoft) in ambiente Visual Basic 6.0; non posso proprio dire quindi che sto' comandando la seriale "a basso livello"!!! Questo potrebbe essere un altro problema? Mi tocca proprio impararmi il C o il C++?

Grazie ancora dell'aiuto! Andrea

PS: mi puoi consigliare qualche risorsa web (pdf, whitepapers vari, ...) tramite la quale mi possa istruire sulle "cosuccie" di cui non ho tenuto conto? (mi riferisco alle temporizzazioni di attesa per assestamento della linea, a quelle per essere sicuro che i dati siano stati ricevuti, ...)

"Andrea" ha scritto nel messaggio news: snipped-for-privacy@uni-berlin.de... [CUT]

ActiveX

C++?

Quando utilizzi il metodo Output dell'oggetto MsComm in Visual Basic, stai inviando dei byte al buffer di trasmissione della seriale del PC, ma non sai se questi byte sono stati effettivamente "espulsi" dalla porta seriale. Cosa comporta questo? Che le variazioni sul DTR potrebbero non essere sincronizzate con l'invio dei byte. Per esempio, se il PC deve trasmettere, deve abilitare la trasmissione, alzando (o abbassando) il DTR. Poi devi trasmettere i byte e SOLO DOPO che TUTTI i byte sono stati EFFETTIVAMENTE trasmessi puoi negare il DTR per riabilitare la ricezione. Ma in Visual Basic "puro" non mi risulta tu possa stabilire quando ESATTAMENTE il buffer hardware di trasmissione si è svuotato. Spero che mi sbagli poiché è una questione su cui mi sono imbattuto anch'io.

Naturalmente il discorso non vale dal lato microcontrollore dove la UART può fornirti l'indicazione della fine trasmissione.

"Andrea" ha scritto nel messaggio news: snipped-for-privacy@uni-berlin.de...

un

nel

Non, saprei, vista la comodità di avere i segnali complementari, io ho sempre preferito collegare RE e DE insieme e comandarli con un unico pin. Se lasci RE sempre abilitato, quando trasmetti dovresti ricevere prima i tuoi dati, poi uneventuale risposta in ricezione. Questo ti può essere utile dal lato pc. Infatti usando VB e mscomm c'è il tipico problema dovuto al fatto che il sistema operativo non gestisce gli eventi in modo sincrono e sequenziale, e al buffer fifo della uart. Così quando comandi il pin dtr (io uso rts ma non cambia nulla, verifica solo di settare il livello giusto, considerando che il max232 inverte il livello logico dei segnali), e poi inizi la trasmissione, potrebbe benissimo essere che inizi prima la trasmissione e poi venga commutato dtr.

Ti consiglio invece di:

-comandare dtr

-attendere un tempo di sicurezza (anche 0.5 sec se l'applicazione te lo permette)

-iniziare a trasmettere

-verificare quando hai trasmesso tutti i dati verificando il buffer di ingresso (quando hai ricevuto tutti i dati significa che li ha ricevuti anche il pic)

-resettare dtr Ovviamente devi fare qualche passaggio in + via sw per filtrare i dati.

Ti posso consigliare l'ottima pagina di Vincenzo Villa

Ciao, Robby

questo

benissimo

Infatti mi aspetto di avere in ricezione tutti i dati che invio; questo mi è utile lato PC (ma anche lato pic!) per capire quando la seriale ha finito la trasmissione (cosa a cui non avevo pensato, grazie dell'aiuto!), ma mi è anche utile (sia lato PC che lato pic) per capire se ci sono errori nella trasmissione dovuti ad esempio al fatto che più dispositivi si sono messi a trasmettere tutti assieme! (infatti in realtà ho più pic collegati al PC tramite questo unico bus dati, se due pic cominciano a trasmettere contemporaneamente ogni pic si accorge che i dati che riceve non sono quelli che sta' trasmettendo quindi decide di interrompere la trasmissione e di attendere un tempo "random" prima di ritentare)

della

Grazie dei link, li vado a vedere appena posso.

Ultimo dubbio RE è attivo basso? (dal datasheet sembra di sì ma su alcuni progetti che ho trovato in rete era segnato come attivo alto!)

Interfacciare una RS485 con Windows e in particolare con Xp è un problema, perchè in genere si deve rispettare un tempo molto breve prima di 'lasciare libera' la linea, e se il dispositivo risponde prima che si disimpegni la linea stessa con l'RTS\ a causa dei suoi multitasking si crea una situazione di errore. Oltretutto con Xp hanno cambiato l' api SetCommState e io ho avuto parecchi problemi con la RS485 su programmi che con W98 andavano benissimo.

Attualmente ho risolto con un converter RS232-RS485 dalla Intracom

ciao Stefano

Uhm... anche questa idea non è da scartare... Ci penso se proprio non riesco a risolvere il problema passerò a questa soluzione (anche se credo che il converter me lo costruirò da me!)

Grazie Ciao Andrea

"Andrea" ha scritto nel messaggio news: snipped-for-privacy@uni-berlin.de... dei link, li vado a vedere appena posso.

Nel max485 (e nella gran parte dei drivers/receivers 485) RE è attivo basso, ovvero quando è a livello basso i dati ricevuti escono dal pin RO. DE invece è attivo alto.

Ciao, Robby

alcuni

basso,

Grazie a tutti Ciao Andrea