Newsgroup: it.hobby.elettronica.digitale
Titolo: RS232 a 9600 cps

Ho realizzato un progetto, dove circa 50 moduli elettronici installati in
altrettante camere leggono dei segnali analogici e digitali e li trasmettono
ad un computer che supervisiona l'interno impianto.
Il tutto è realizzato intorno a dei micro ST62txx che trasmettono attraverso
una rete RS485 le informazione rilevate dai propri ingressi, una volta
interrogati del circuito master (l'interfaccia PC d'ora in poi IPC).
L'interfaccia PC a sua volta trasmette al pc attraverso l'RS232 i dati
scambiati con la scheda slave di turno (pooling).
Il tutto funziona a meraviglia quando trasmetto ad un massimo di 1200 cps
sulla rs232, ma siccome il bus 485 sono riuscito a portarlo a 9600 cps senza
nessun problema, limitare l'interfacciamento col pc a 1200 comprometterebbe
seriamente la velocità complessiva dell'impianto.
Per realizzzare il programmino sul pc ho utilizzato il Visual Basic che
conosco un pò, ed ho usato l'evento CommEvents per controllare quando nel
buffer di ricezione sono presenti i 5 caratteri trasmessi dall'IPC. Quando
però leggo i caratteri trovo quasi sempre uno sdoppiamento del primo
carattere "170" che utilizzo come carattere di sincronizzazione e i
rimanenti caratteri quasi mai corrispondono a quelli realmente trasmessi.
Attraverso un oscilloscopio digitale ho campionato l'intero pacchetto di 5
caratteri che arriva nell'rs232, e sono corretti sia come temporizzazioni (i
singoli bit durano esattamente 0,104 ms) sia come struttura (bit start 8 bit
dati 2 bit stop) (del resto la stessa routines a 300 e 1200 cps funziona
bene).
Il mio dubbio è su la routines di lettura sul VB (Visual Basic), in più c'è
da dire che per un problema di programmazione sull'st6 ogni singolo
carattere dei 5 inviati all'rs232 è perfettamente conforme, ma il tempo
intercorso fra la trasmissione di un carattere ed un altro non è sicuramente
corretta, nel senso che i cincque caratteri non sono spediti in successione
perfetta, ma con una brevissima pausa nella quale il micro elabora il dato
che deve essere trasmesso. Non credo questo sia un problema perchè il bit di
stop rimane alto nel frattempo, e se il pc aspetta il bit di start come ho
fatto fare alle schede slave ha la possibilità di sincronizzarsi al
carattere successivo (almeno credo) se qualcuno può aiutarmi mi manca solo
questo per finire il tutto e vivere felice e contento... ;-)

 Il mio dubbio č su la routines di lettura sul VB (Visual Basic), in piů
c'č > da dire che per un problema di programmazione sull'st6 ogni singolo >
carattere dei 5 inviati all'rs232 č perfettamente conforme, ma.......
A occhio e croce sembra anche a me un problema di gestione del VB (su questo
non posso aiutarti), comunque  il discorso della pausa tra un carattere e
l'altro non causa problemi, in quanto come giustamente hai detto, il pc
attende il successivo start bit, anche se arrivasse dopo un secondo.
ciao
Claudio

 attende il successivo start bit, anche se arrivasse dopo un secondo.
da profano.....perchè non elebori tutta la stringa dei 5 caratteri poi la
invii così il ritardo di elaborazione lo avrai solo 1 volta e non su ogni
singolo carattere...magari salvi la stringa su memoria..poi lo invii.
ciao


Si potrebbe in effetti realizzare, ma non č conveniente, in quanto il
protocollo che ho ideato, non usa una stringa statica, ma dinamica, nel
senso che per risolvere il problema ora i caratteri inviati sono sempre 5,
ma una volta risolto la comunicazione tra pc ed interfaccia, i caratteri in
arrivo sul pc potrebbero essere da 4 a 256 in relazione a delle elaborazioni
interne, in ogni caso ho constatato che in effetti il ritardo tra la
spedizione di un carattere all'altro non č in effetti un problema se si
mantiene alto lo stop-bit, in quanto a 1200 cps dove tutto funge alla
perfezione, ho strasmesso sulla rs232 caratteri distanziati fra di loro
anche sull'ordine dei secondi e non ci sono problemi.
Grazie cmq e rimango in attesa di possibbili soluzioni Bye :-)


Grazie dell'indicazione, che ho cmq avuto modo di verificare, ma non ho
ancora risolto l'enigma... ho cmq notato, che a volte dopo diversi riavvii
del software sul pc può capitare che il tutto funge fino a quando non si
resetta il software oppure si spegne il sistema, sarà errato come termine ma
dà bene l'idea, è come se il computer e l'interfaccia non riescono a
"sincronizzarsi", infatti delle volte dà l'impressione che tutto sia andato
ok, ma in effetti poi qualcosa non và...

......ho cmq notato, che a volte dopo diversi riavvii del software sul pc
può capitare che il tutto funge fino a quando non si resetta il software
oppure si spegne il sistema, sarà errato come termine ma dà bene l'idea, è
come se il computer e l'interfaccia non riescono a "sincronizzarsi"
mi sa che e' proprio questo l'inghippo, hai detto che con il vb attendi un
evento che si verifica quando l'ipc ha mandato 5 chr, secondo me dovresti
controllare i singoli bytes uno alla volta. il problema dello sdoppiamento
del chr di sync puo' essere dovuto a un dato residuo non letto dal buffer di
ricezione? hai modo di svuotarlo o di specificarne le dimensioni? a me una
volta e' successa una cosa del genere e ho dovuto riscrivere tutta la
gestione della comunicazione in modo da lavorare con meno automatismi
(eventi) possibili e creando un mio buffer circolare (un volgare array) in
cui scrivevo i vari bytes in arrivo per poi rileggerli con comodo, anzi se
ben ricordo il comEvent (non parlo di VB comunque) funzionava proprio
male... ho usato il timer per fare il polling sul buffer hardware
(chiamiamolo cosi') e trasferirne il contenuto nel mio array.
ciao
Claudio

 Claudio
Ci avevo pensato ma non sapevo come realizzarlo, non mi intendo troppo di
programmazione su pc perchè ho lasciato la programmazione moolto tempo fà...
Cmq ho risolto il problema che era nel software dell'ST6, in pratica la
sobroutines per la trasmissione sul bus rs232 conteneva un banalissimo
errore e una linea di codice che doveva essere jrz è per errore diventata
jrnz (una "n" di troppo) per cui i singoli bit elaborati venivano processati
quando erano diversi da 0 e non viceversa, per incredibile coincidenza la
stringa che componeva i 5 byte processati male, era costituita da caratteri
che nonostante questo inconveniente risultavano molto simili a quelli giusti
ma semplicemente spostati di a destra di un carattere intero.
La cosa non succedeva sul bus 485 perchè la routines di
trasmissione/ricezione non era uguale a quella sulla rs232 che avendo
bisogno di temporizzazioni molto più precise che ho realizzato senza usare
il timer del micro ma calcolando i cicli di ogni istruzione.
Grazie a tutti e mi rituffo nel resto delle problematiche che stò già
riscontrando con la parte finale del prg ùbye :))

Hai provato ad impostare la proprietā InBufferSize del controllo MSComm a 1
per
eliminare totalmente il buffer?
in questo modo la routine di gestione degli eventi OnComm verrā chiamata
molto pių spesso,
ma tu in compenso avrai una migliore gestione della comunicazione.
Mi chiedevo se i moduli non aspettino una risposta dal computer e in
mancanza di questa ritrasmettessero
il carattere iniziale. se mi potessi fornire maggiori dettagli sul
funzionamento delle routine, magari un
diagramma degli stati del firmware magari potrei darti una risposta esatta.
--
Alessio Morale 
alessi...@interfree.it
Home page del progetto Java automation:
http://alessiomorale.interfree.it