Newsgroup: it.comp.lang.visual-basic
Titolo: Evento OnComm

E' un dubbio che ultimamente mi è venuto... premetto che farò dei test su
questo... ma mi piacerebbe avere qualche riscontro da qualcuno di voi...
Io leggo una serie di dati che a ciclo continuo mi arrivano sulla seriale...
per far questo ho utilizzo fino ad oggi l'evento oncomm... bhe mi chiedevo
se per il sistema non fosse meno pesante se la pulizia del buffer non la
facessi al momento della generazione dell'evento oncomm ma utilizzando
l'evento timer di un oggetto timer settato ad una certa frequenza(ovviamente
più bassa di quella che avrai spontanenamente dall'evento oncomm con
l'arrivo dei dati)... premetto che non posso impostare un numero di byte max
per generare l'evento oncomm perchè non posso determinare tale valore che
cambia di volta in volta a secondo di circostanze esterne... Grazie per
eventuali pareri e consigli.

 qualcuno di voi...
Sono due strategie che ho utilizzato in situazioni diverse.
Se sei un master, sostanzialmente devi ascoltare le risposte degli slave, i
quali 'parlano' solo su tua richiesta. In questo caso, generalmente uso un
accrocchio dei due, ossia chiedo e poi vado in loop finchè non ho ricevuto
una risposta o sono andato in timeout.
Se sei uno slave, devi valutare quante comunicazioni arriveranno. Se
arrivano a getto continuo, tanto vale mettere un tuo timer e appendere
l'inputbuffer alla stringa globale, valutarla e poi aspettare nuovamente.
Se arrivano sporadicamente, o se devi rispondere in tempi rigorosi, occorre
usare l'OnComm, che ti consente di reagire immediatamente e di usare zero
risorse se non arriva niente per un po'.
Considera, comunque, che l'evento OnComm non avviene per ogni singolo
carattere che arriva in seriale, anche se setti a 1 RThresHold. Infatti, dal
momento in cui entri nell'evento OnComm, finchè non ne esci potrebbero
arrivare altri caratteri, e questi NON genererebbero alcun altro evento. Se,
al momento dell'EndSub, non li hai letti tutti, appena esci avviene un altro
OnComm.
Quindi, puoi fare una cosa che ritengo furba: Nell'evento OnComm, metti un
piccolo loop che attende finchè la stringa creata appendendo l'InputBuffer
non diventa un messaggio valido, o finchè non trascorre un certo tempo. In
questo modo, avresti il 99% dei pacchetti ricevuti in singoli eventi OnComm,
e ti agevoleresti parecchio la gestione di eventuali timeout di ricezione.
Ciao
Alberto
-- 
Rigore è quando arbitro fischia

Quello che dici è tutto giustissimo.... ma il mio obbiettivo è quello di
prendere meno risorse possibili al sistema.
Infatti la mia applicazione controlla e parla con ben 8 seriali (e temo che
dovranno essere anche molte di più) su cui arrivano in modo continuo (e
continuo vuol dire che è costantemente impegnata).
In più deve gestire molti altri eventi interni (compreso comunicazioni con
un database con ste cavolo di ado lentissime)... col tempo ho perfezonato
molto il sistema ma ultimamente con 8 periferiche attaccate il mio
processore raggiunge un utilizzo del 80% e onestamente mi sembra troppo. Il
perfezionamento è consistito nel ELIMINARE completamente tutti cicli di
attesa, i cicli do loop (che succhiano un casino di risorse al sistema,
meglio i for next), ed ottimizzato le mie subroutine... oggi sono
soddisfatto ma sono sicuro che si possa fare meglio!
Oggi sto sviluppando una classe in .net per il controllo di queste
macchine... implementerò su questa classe la possibilità di prelevare i dati
dal buffer di rx con una frequenza impostabile esternamente dall'utente...
facendo così spero di poter capire ulteriori i segreti sull'ottimizione di
questi tipi di codice!
CMQ grazie per la risposta!
"Albe V°" <vaccariTOGLI_QUESTO@TOGLI_QUESTOhotmail.com> ha scritto nel
messaggio news:ZSrjb.39480$vO5.1...@twister1.libero.it...
