[C/C++] Teorema del campionamento

[gugoXX]

Originariamente inviato da misterx

ma per come è costruita la funzione di lettura, io passo un puntatore ad un buffer e questa lo riempie ed ogni volta il ciclo si ripete allo stesso modo ogni tot millisecondi da me imposti.

Non mi viene in mente come accodare

dipende da come e' scritta la funzione di lettura.

Se e' una funzione di lettura e basta, giusto prima di chiamarla potresti fare una new di 1024 byte, passare alla funzione il nuovo puntatore e accodare il risultato ripempito nella coda condivisa.

[misterx]

Originariamente inviato da gugoXX

dipende da come e' scritta la funzione di lettura.

Se e' una funzione di lettura e basta, giusto prima di chiamarla potresti fare una new di 1024 byte, passare alla funzione il nuovo puntatore e accodare il risultato ripempito nella coda condivisa.

è una funzione di libreria scritta dal produttore dell'apparato e al massimo posso giocare sul buffer.
In pagina 2 ho allegato il simulatore

[gugoXX]

Originariamente inviato da misterx

è una funzione di libreria scritta dal produttore dell'apparato e al massimo posso giocare sul buffer.
In pagina 2 ho allegato il simulatore

Si', ma a quel simulatore puoi far fare quello che vuoi, anche cose che potenzilamente potresti non poter fare, e ovviamente non fa testo.
E comunque giocare sul buffer, l'unica cosa che puoi fare, e' proprio quello che proponevo di fare.
PRIMA di chiamare la funzione di lettura (che non e' ovviamente presente nel simulatore), allochi 1024 bytes e passi il nuovo puntatore alla funzione.
Ottenuto il risultato accodi il tutto in una coda condivisa che ovviamente nel simulatore non c'e'.
E il consumatore leggera' dalla coda condivisa quando piu' gli fa comodo.

[misterx]

marco.r,
quasi quasi se implemento solo due thread mi semplifico la vita.

//TH1
- riempio buffer da ethernet
- ciclo buffer se cambiato qualcosa creo evento e risveglio TH2

//TH2
- vislualizza e memorizza su disco

[misterx]

Originariamente inviato da gugoXX

Si', ma a quel simulatore puoi far fare quello che vuoi, ovviamente non fa testo.

perhè non ho di mezzo la ethernet?

[misterx]

Originariamente inviato da gugoXX

Si', ma a quel simulatore puoi far fare quello che vuoi, anche cose che potenzilamente potresti non poter fare, e ovviamente non fa testo.
E comunque giocare sul buffer, l'unica cosa che puoi fare, e' proprio quello che proponevo di fare.
PRIMA di chiamare la funzione di lettura (che non e' ovviamente presente nel simulatore), allochi 1024 bytes e passi il nuovo puntatore alla funzione.
Ottenuto il risultato accodi il tutto in una coda condivisa che ovviamente nel simulatore non c'e'.
E il consumatore leggera' dalla coda condivisa quando piu' gli fa comodo.

però se il buffer viene elaborato quando più fa comodo, come determino i tempi di cambiamento di stato da zero a uno e viceversa?
Il mio problema è determinare il cambiamento di stato e il tempo di permamenza in tale stato

[banryu79]

Originariamente inviato da misterx

Il mio problema è determinare il cambiamento di stato e il tempo di permamenza in tale stato

E questo implica che c'è bisogno di un thread per fare "polling continuo", o sbaglio?
Sapendo che i valori/bit del dispositivo sono N, io teoricamente farei così:

a) polling continuo con il thread Lettore:
- ha un buffer di N elementi;
- prima lettura in avvio: copia lo stato del dispositivo nel buffer;
- ciclo infinito, ad ogni iterazione:
- se i valori che legge nel dispositivo sono diversi da quelli presenti nel buffer
- copia i valori del dispositivo nel buffer (per futuri confronti)
- fa una copia del buffer Copia;
- crea un Elemento con Copia e un timestamp (per consumo da parte del thread Scrittore);
- acquisisce mutex di Coda;
- infila Elemento nella Coda;
- rilascia mutex di Coda;
- sleep brevissima

b) una struttura che faccia da Coda, condivisa con una mutex

c) thread Scrittore (con parametro X tarabile: numero di elementi da estrarre dalla Coda ad ogni iterazione)
- ciclo infinito, ad ogni iterazione:
- acquisisce mutex di Coda;
- rimuovi al più X Elementi da Coda;
- rilascia mutex di Coda;
- scrivi al più X Elementi su file;
- sleep moderata



@EDIT:
Invece di "salvare" tutto il buffer, se si salva in avvio lo stato iniziale del dispositivo (snapshot) poi si possono salvare solo le differenze (i delta).
Magari ogni tanto (se neccessario o si ritiene sia conveniente) si può fare un nuovo snapshot per poi continuare con i soli delta.

[misterx]

Originariamente inviato da banryu79

E questo implica che c'è bisogno di un thread per fare "polling continuo", o sbaglio?
Sapendo che i valori/bit del dispositivo sono N, io teoricamente farei così:

a) polling continuo con il thread Lettore:
- ha un buffer di N elementi;
- prima lettura in avvio: copia lo stato del dispositivo nel buffer;
- ciclo infinito, ad ogni iterazione:
- se i valori che legge nel dispositivo sono diversi da quelli presenti nel buffer
- copia i valori del dispositivo nel buffer (per futuri confronti)
- fa una copia del buffer Copia;
- crea un Elemento con Copia e un timestamp (per consumo da parte del thread Scrittore);
- acquisisce mutex di Coda;
- infila Elemento nella Coda;
- rilascia mutex di Coda;
- sleep brevissima

b) una struttura che faccia da Coda, condivisa con una mutex

c) thread Scrittore (con parametro X tarabile: numero di elementi da estrarre dalla Coda ad ogni iterazione)
- ciclo infinito, ad ogni iterazione:
- acquisisce mutex di Coda;
- rimuovi al più X Elementi da Coda;
- rilascia mutex di Coda;
- scrivi al più X Elementi su file;
- sleep moderata

aspetta scusa: la funzione che sto usando richiede un buffer di dimensione nota e lei la riempie

Inizialmente avevo tre thread con un semaforo comune tra produttore e consumatore ed un evento tra consumatore e scrittore.

Poi mi sono detto se ne valeva la pena mantenere un semaforo in quanto:
se produttore sta riempiendo consumatore non può accedervi e allora tanto vale eliminare consumatore e mettere in sequenza i due

//produttore
-------- riempe array
-------- cicla array e se trova bit a uno crea evento


//scrittore
----- attesa_evento
----- scrive tempi su disco
----- resetta evento

ma non so se ho fato bene ad eliminare consumatore, di primo acchito direi di si.

Sta di fatto che continuo a notare differenze di al max 20 millisecondi: forse significa che windows in determinate condizioni può essere usato a scopo real time?

[banryu79]

Originariamente inviato da misterx

Sta di fatto che continuo a notare differenze di al max 20 millisecondi: forse significa che windows in determinate condizioni può essere usato a scopo real time?

Che io sappia no, non ci si può appoggiare a Windows assumendo di avere a che fare con un sistema real time, perchè non lo è.

[misterx]

Originariamente inviato da banryu79

Che io sappia no, non ci si può appoggiare a Windows assumendo di avere a che fare con un sistema real time, perchè non lo è.

non avendo mai scritto programmi per sistemi operativi real time, anche se la risposta sembrerebbe scontata significa che se portassi il mio programma così com'è sotto un sistema operativo real time avrei tempi corretti?

un link che non è chiarissimo se intendano che windows 2000/xp possono diventare RT http://www.codeguru.com/cpp/w-p/syst...cle.php/c14457

[!fazz]

Originariamente inviato da misterx

non avendo mai scritto programmi per sistemi operativi real time, anche se la risposta sembrerebbe scontata significa che se portassi il mio programma così com'è sotto un sistema operativo real time avrei tempi corretti?

un link che non è chiarissimo se intendano che windows 2000/xp possono diventare RT http://www.codeguru.com/cpp/w-p/syst...cle.php/c14457

un sistema con un os. real time ti garantisce che il tuo codice girerà effettivamente ad una determinata frequenza: io uso spessissimo rtos su un pxi per fare acquisizione e controllo ma ha il difetto di essere piuttosto caro e di dover programmare con quello schifo che è G con tanti ringraziamenti a ni

in alternativa se il programma è semplice puoi pensare di portare l'acquisizione su un micro, salvare i dati su flash e postelaborarli offline

[misterx]

Originariamente inviato da !fazz

un sistema con un os. real time ti garantisce che il tuo codice girerà effettivamente ad una determinata frequenza: io uso spessissimo rtos su un pxi per fare acquisizione e controllo ma ha il difetto di essere piuttosto caro e di dover programmare con quello schifo che è G con tanti ringraziamenti a ni

in alternativa se il programma è semplice puoi pensare di portare l'acquisizione su un micro, salvare i dati su flash e postelaborarli offline

scusa ed un qualcosa di più noto?
Ti risulta windows CE oppure Linux o anche Windows XP Embedded?


p.s
guardacaso qua dice di no http://it.wikipedia.org/wiki/Sistema...tivo_real-time

[starfred]

Un sistema operativo real-time ti può garantire con altissima probabilità (nulla è 100%) che lo scheduling dei processi avverrà nella deadline previste.
Il fatto che il tuo codice funzioni ora sulla tua macchina windows xp non garantisce affatto che funzioni su un 8-core con windows xp.
Non ti garantisce nemmeno che funzioni sulla tua macchina domani.

[misterx]

Originariamente inviato da starfred

Un sistema operativo real-time ti può garantire con altissima probabilità (nulla è 100%) che lo scheduling dei processi avverrà nella deadline previste.
Il fatto che il tuo codice funzioni ora sulla tua macchina windows xp non garantisce affatto che funzioni su un 8-core con windows xp.
Non ti garantisce nemmeno che funzioni sulla tua macchina domani.

dopo tutto quello che ho letto ed ho provato sulla mia pellaccia sono convinto!
Meno male che il bit relativo al dispositivo più "veloce", si fa per dire, cambia in circa 1,5 secondi.
Ciò vuol dire che dovrei riuscire anche con XP a determinare abbastanza frequentemente e con buona precisione tale tempo.

Ho provato anche con bit che cambiano ogni 188 ms come esperimento e tali 188 ms che sono stati rilevati prima strumentalmente, grande mistero per me, leggo la maggior parte delle volte proprio 188 ms con un errore di (+/- 16 ms) solo a volte.

E' un fatto che non riuscirò mai a spiegarmi boh.

[starfred]

Un modo per evitare di fare tutta la storia delle temporizzazioni è quello di modificare il dispositivo in modo tale da effettuare un handshake con il thread nel momento in cui è pronto un nuovo dato.

[misterx]

Originariamente inviato da starfred

Un modo per evitare di fare tutta la storia delle temporizzazioni è quello di modificare il dispositivo in modo tale da effettuare un handshake con il thread nel momento in cui è pronto un nuovo dato.

cioè il dispositivo mi dovrebbe dire quando ha dati da inviarmi?
Un metodo forse ci sarebbe ma non so se risolverebbe il problema. Mi pare che nel momento in cui viene fatto un refresh dei dati viene alzato un particolare bit.

[misterx]

dopo 3100 misurazioni ho ottenuto i seguenti risultati

          A      B      C        D
medie	401	199	600	797
max	422	204	610	797
min	390	187	593	719

[misterx]

ho scoperto solo ora di avere un grosso problema nella mia implementazione: quando TH2 setta l'evento, TH3 non risponde in maniera così decisiva e quindi si perde dati per strada in quanto nel tempo in cui TH3 stra per rispondere TH2 ha già modificato li buffer, che soluzioni ci potrebbero essere?

chari miobuf[80];

byte buf[1024];
//TH1
while(1)
{
      WaitForSingleObject(hMutex,INFINITE);

      RiempiArray(buf);

      ReleaseMutex(hMutex);

     Sleep(250);
}

//TH2
while(1)
{
      WaitForSingleObject(hMutex,INFINITE);
      
      for(int i=0; i<1024; i++)
      {
             if(bit cambia stato)
             calcola_tempo();
             sprintf(miobuf,"%d.%d",a,b);

             SetEvent ( hEvent2 );

      }
      ReleaseMutex(hMutex);

     Sleep(50);
}

//TH3
while(1)
{
            WaitForSingleObject(hEvent2 ,INFINITE);
      
             fprintf(fp,"X%s\n",miobuf);;

             ResetEvent( hEvent2 );


}

[tomminno]

Originariamente inviato da misterx

ho scoperto solo ora di avere un grosso problema nella mia implementazione: quando TH2 setta l'evento, TH3 non risponde in maniera così decisiva e quindi si perde dati per strada in quanto nel tempo in cui TH3 stra per rispondere TH2 ha già modificato li buffer, che soluzioni ci potrebbero essere?

Ma il buffer lo copi oppure ti passi un puntatore/riferimento?

[misterx]

Originariamente inviato da tomminno

Ma il buffer lo copi oppure ti passi un puntatore/riferimento?

in TH2 uso la sprintf(miobuf,"%d.%d",a,b); con miobuf che è un array globale