Newsgroup: it.comp.lang.c++
Titolo: [XPOST] approccio programmino per uindou,acquisisci-decodifica-disegna

Ciao,mi sono permesso un piccolo crosspost col ng 
it.hobby.elettronica.digitale,farò presenti eventuali risposte da questo ng 
più specializzato
 
 
dispositivo USB con  integrato convertitore USB-seriale FTDI,driver 
utilizzanti relativa DLL ,38400 bps,64
pacchetti al secondo da decodificare , tirarci fuori un campione a
pacchetto e stampare.
Sembrano velocità che non spaventano un PC degli ultimi 10 anni.
 
Per ora faccio un approccio a Timer,ogni 10 ms leggo quanti bytes pronti 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
 
 


Problema che affronto quotidianamente.
L'idea è di tenere un buffer contenente il pacchetto parziale in una 
variabile persistente (globale, in C, membro di un oggetto in C++), 
inserendo un carattere alla volta. Appena completi un pacchetto, lo 
interpreti, svuoti il buffer, e prosegui nella lettura dei dati in arrivo.
 
L'implementazione specifica dipende molto da come sono strutturati i 
pacchetti, ma assomiglia a:
 
while (ci sono dati da leggere)
{
   leggi dato D
   aggiungi D al buffer
   if(il buffer contiene un pacchetto completo)
   {
     interpreta buffer
     svuota buffer
   }
}
 
Quando hai letto tutti i dati, potresti avere un pacchetto parziale in 
'buffer', che completerai nel prossimo ciclo di letture.
 
-- 
Mickey

 -- 
Scusa,leggo solo ora,grazie
nel frattempo ho fatto una cosa sostanzialmente simile alla tua,nello 
specifico tiene conto dellla possibilità che vi siano più pacchetti 
completi,e in tal caso li interpreta e svuota consecutivamente,inoltre copia 
all'inizio del buffer il pacchetto incompleto al quale attaccherà i prossimi 
bytes
 
la cosa per me strana che ho notato invece era questa:
 
utilizzavo una funzione GetStatus della FTDI ,che mi dice quanti sono i 
bytes pronti da leggere,con la mia cadenza possono essere 15...17,se decido 
di saltare una lettura poi possono essere 30..34,la funzione li mette in un 
buffer dove da me indicato es in   ucmiobuffer[ucmioindice], con
unsigned char ucmiobuffer[256]
unsigned char ucmioindice;
per ogni operazione matematica su ucmioindice tuttofunziona come in 
teoria,es se volessi il contenuto di  ucmiobuffer[1 - 17] mi ritroverei 
giustamente il contenuto di ucmiobuffer[240]
Occhio ora:
ho un errore quando l'indice che mi punta a varie locazioni del buffer si 
"riavvolge" es: era a 240,mi trovo 17 bytes da sistemare per cui li alloca 
da ucmiobuffer[240] a  ucmiobuffer[1],ecco a questo punto la funzione FTDI 
GetStatus mi dice che nella coda vi sono es.  23454 bytes,e l'errore avviene 
sistematicamente ogni volta che vi è il "riavvolgimento" dell'indice
 
A me sembra strano...mi è sfuggito qualcosa?
Ho ovviato utilizzando il buffer in altro modo non "circolare".
 
Grazie ancora
 
 
 
 
 

 Ho ovviato utilizzando il buffer in altro modo non "circolare".
 
Mi autorispondo,a parte che la funzione che punta all'indice e sbaglia è 
FTRead,è chiaro che mi succeda un casino perchè io so che il mio indice a 8 
bit si riavvolge,ma la funzione che fa riferimento a quell'indice non lo sa 
e sfora il buffer.....