Newsgroup: it.hobby.elettronica.digitale
Titolo: approccio programmino per uindou,acquisisci-decodifica-disegna

Ciao,consiglio generale cercasi
 
dispositivo USB con  FTDI,driver utilizzanti relativa DLL ,38400 bps,64 
pacchetti al secondo da decodificare  e tirarci fuori un campione a 
pacchetto e stampare.
 
Per ora faccio un approccio a Timer,ogni 10 ms leggo quanti bytes ci sono,me 
li porto in un buffer... e poi?Potrebbe succedere di iniziare con un 
pacchetto già  iniziato,leggermi 2 o 3 pacchetti completi e finire con un 
pacchetto incompleto che completerei nella prossima lettura.Non vorrei 
perdermi nessun pacchetto.
 
Nel noto sistema operativo è possibile far si che la funzione di 
interpretazione del pacchetto e disegno venga interrotta dall'evento timer e 
riprenda poi dallo stesso punto??
 
Cosa si fa di solito in questi casi?
 
Grazie 
 
 


ma in che modo va a vedere se ci sono dati??Polling continuo?
E se mentre li sta scaricando arriva l'evento timer cosa succede?


 E se mentre li sta scaricando arriva l'evento timer cosa succede?
 
 
Tipicamente puoi scegliere se avere un interrupt quando i byte nella 
fifo di ricezione supera una certa soglia oppure andare tu a vedere 
quanti ce ne sono (polling).
 
Io utilizzo un sistema misto, ovvero in un thread separato ogni x ms 
(tipicamente ogni 50, ma dipende dall'applicazione) vado a leggere tutto 
il contenuto del buffer seriale e lo restituisco all'applicazione 
tramite un interrupt (signal nelle qt).
 
Nella isr relativa (thread principale) accodo quanto ricevuto nel buffer 
locale e immediatamente dopo vado a estrarre i pacchetti completi 
presenti aggiungendoli a una coda.
 
In un altro punto del programma vado a svuotare questa coda secondo le 
necessità.
 
I vantaggi che vedo sono:
 
- la ricezione a basso livello dalla seriale avviene in un thread 
separato quindi non impatta sulla GUI
 
- la gestione tramite "doppia fifo" (dati grezzi e pacchetti completi) 
permette proprio di risolvere i problemi di ricezione incompleta o 
errori di trasmissione.
 
- la coda sui pacchetti decodificati risolve il problema di quanto 
ricevi ad esempio due pacchetti di fila oppure non hai il tempo per 
processarli tutti al volo.
 
Ah, aggiungo sempre un timeout per accorgermi di eventuali problemi che 
viene resettato ad ogni evento di ricezione.
 
Marco

 Marco
 
Ancora grassie 
 
 

 oppure se per favore hai link con esempi me li guardo,
 
 
Vedi sopra per quanto riguarda la seriale.
Per i thread puoi pensarci in seguito. Conviene forse fare un passo alla 
volta e avere la seriale funzionante. Poi quando ti accorgerai che rende 
poco reattiva la GUI verrà naturale :-)
 
Ciao
Marco

OnTimer_Event
 
Il polling in questi casi è conveninente solo se il pc è poco utilizzato e puoi
inserire un thread ad alta priorità, altrimenti non hai la certezza di arrivare
in tempo a servire il timer.
 
 
--
ciao
  Stefano

 Diverso in che senso?
 
domanda evidentemente impropria da uno che non ha ancora capito bene i 
thread


 thread
 
 
Semplicemente è una funzione che gira in un thread diverso, per il resto 
non cambia nulla. Ma, ripeto, secondo me puoi benissimo pensarci in seguito.
 
Marco

 Cosa si fa di solito in questi casi?
 
Si usa SetCommTimeouts() e un thread separato.
 
-- 
Fletto i muscoli e sono nel vuoto.

 ha scritto nel messaggio 
news:uxm1dwyq1i97$.xe2w010pltr2.dlg@40tude.net...

questa settimana ci riprovo e ti dico