Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Seriale USB
13 views
Skip to first unread message
Stefano
May 9, 2013, 3:02:46 AM5/9/13
to
Ciao,
su un'applicazione che ho sviluppato e che si interfaccia con una
device esterna mediante seriale, si ￜ evinto un problema: la
visualizzazione dei dati recuperati sembra essere soggetta a buffering,
nel senso che vi ￜ un tangibile ritardo tra il movimento della device e
la visualizzazione dello stesso a schermo.
Il problema non si verifica sempre ma occasionalmente.
La velocitￜ di comunicazione ￜ di 9600 bps, la frame che viene inviata
alla device ￜ di 184 bit (circa 19,2 ms) ed il timeout tra una frame e
la successiva ￜ di circa 20-25 ms. Per espressa volontￜ (deprecata da
parte mia) di chi ha sviluppato il firmware della device, non esiste
alcun tipo di sincronizzazione (hw o sw) dei messaggi tra pc e device.
Per individuare il problema ho sottoposto il pc a stress della CPU e
della GPU, ho realizzato delle applicazioni che bypassavano la seriale
ed inviavano a polling lo stesso messaggio, ma nulla di fatto.
Potrebbe quindi essere fattibile l'ipotesi summenzionata, ovvero che
data l'elevata velocitￜ di trasmissione a fronte della lentezza della
comunicazione, i dati vengano bufferizzati e questo crei il ritardo
notato?
Grazie, ciao. Stefano.
su un'applicazione che ho sviluppato e che si interfaccia con una
device esterna mediante seriale, si ￜ evinto un problema: la
visualizzazione dei dati recuperati sembra essere soggetta a buffering,
nel senso che vi ￜ un tangibile ritardo tra il movimento della device e
la visualizzazione dello stesso a schermo.
Il problema non si verifica sempre ma occasionalmente.
La velocitￜ di comunicazione ￜ di 9600 bps, la frame che viene inviata
alla device ￜ di 184 bit (circa 19,2 ms) ed il timeout tra una frame e
la successiva ￜ di circa 20-25 ms. Per espressa volontￜ (deprecata da
parte mia) di chi ha sviluppato il firmware della device, non esiste
alcun tipo di sincronizzazione (hw o sw) dei messaggi tra pc e device.
Per individuare il problema ho sottoposto il pc a stress della CPU e
della GPU, ho realizzato delle applicazioni che bypassavano la seriale
ed inviavano a polling lo stesso messaggio, ma nulla di fatto.
Potrebbe quindi essere fattibile l'ipotesi summenzionata, ovvero che
data l'elevata velocitￜ di trasmissione a fronte della lentezza della
comunicazione, i dati vengano bufferizzati e questo crei il ritardo
notato?
Grazie, ciao. Stefano.
Marco Trapanese
May 9, 2013, 4:33:24 AM5/9/13
to
Il 09/05/2013 09:02, Stefano ha scritto:
> su un'applicazione che ho sviluppato e che si interfaccia con una device
> esterna mediante seriale, si ￜ evinto un problema: la visualizzazione
> dei dati recuperati sembra essere soggetta a buffering, nel senso che vi
> ￜ un tangibile ritardo tra il movimento della device e la
> visualizzazione dello stesso a schermo.
Definisci "tangibile": hai misurato il ritardo o lo vedi visivamente?
> su un'applicazione che ho sviluppato e che si interfaccia con una device
> esterna mediante seriale, si ￜ evinto un problema: la visualizzazione
> dei dati recuperati sembra essere soggetta a buffering, nel senso che vi
> ￜ un tangibile ritardo tra il movimento della device e la
> visualizzazione dello stesso a schermo.
Visualizzazione a schermo: parli di un terminale seriale (quale?) oppure
di un'applicazione?
Quale sistema operativo?
> Il problema non si verifica sempre ma occasionalmente.
> La velocitￜ di comunicazione ￜ di 9600 bps, la frame che viene inviata
> alla device ￜ di 184 bit (circa 19,2 ms)
La seriale lavora a byte quindi 184 bit = 23 byte.
In condizioni standard (8N1) ogni byte richiede 10 bit. A 9600 bps ogni
byte richiede dunque 1,04 ms e 23 byte circa 23,96 ms.
Marco
Stefano
May 9, 2013, 5:31:24 AM5/9/13
to
Marco Trapanese ha detto questo giovedￜ :
sistema operativo Windows Vista. Parte della frame contiene i valori di
accelerazione su due assi, ￜ tangibile visivamente in quanto, in
seguito al movimento della device, l'ago del controllo gauge si muove
in ritardo (1 s minimo).
Non vi sono perdite di frame in quanto il movimento ￜ fluido e la
registrazione dello stesso su db ￜ senza soluzione di continuitￜ; non
credo nemmeno imputabile alla CPU o alla GPU in quanto, oltre a non
muoversi a scatti, gli stress-test effettuati sul sistema non hanno
avuto effetto e le applicazioni create ad-hoc, che inviano con un
timeout di 25ms la stessa frame, non hanno evinto problemi.
>
> Parliamo di RS232?
> La seriale lavora a byte quindi 184 bit = 23 byte.
> In condizioni standard (8N1) ogni byte richiede 10 bit. A 9600 bps ogni byte
> richiede dunque 1,04 ms e 23 byte circa 23,96 ms.
>
Quindi peggiorativo rispetto alle mie considerazioni...
Parliamo di una RS232 virtuale su porta USB, configurata in 9600,N,8,1
nessun controllo di flusso hw o sw.
Ho trovato questo documento che pare avvalorare la mia ipotesi di
buffering: http://goo.gl/K1mXc
> Marco
Grazie, ciao. Stefano.
> Il 09/05/2013 09:02, Stefano ha scritto:
>
>
> Definisci "tangibile": hai misurato il ritardo o lo vedi visivamente?
> Visualizzazione a schermo: parli di un terminale seriale (quale?) oppure di
> un'applicazione?
> Quale sistema operativo?
>
I dati vengono visualizzati su controlli gauge sviluppati in DotNet,
>
>
> Definisci "tangibile": hai misurato il ritardo o lo vedi visivamente?
> Visualizzazione a schermo: parli di un terminale seriale (quale?) oppure di
> un'applicazione?
> Quale sistema operativo?
>
sistema operativo Windows Vista. Parte della frame contiene i valori di
accelerazione su due assi, ￜ tangibile visivamente in quanto, in
seguito al movimento della device, l'ago del controllo gauge si muove
in ritardo (1 s minimo).
Non vi sono perdite di frame in quanto il movimento ￜ fluido e la
registrazione dello stesso su db ￜ senza soluzione di continuitￜ; non
credo nemmeno imputabile alla CPU o alla GPU in quanto, oltre a non
muoversi a scatti, gli stress-test effettuati sul sistema non hanno
avuto effetto e le applicazioni create ad-hoc, che inviano con un
timeout di 25ms la stessa frame, non hanno evinto problemi.
>
> Parliamo di RS232?
> La seriale lavora a byte quindi 184 bit = 23 byte.
> In condizioni standard (8N1) ogni byte richiede 10 bit. A 9600 bps ogni byte
> richiede dunque 1,04 ms e 23 byte circa 23,96 ms.
>
Parliamo di una RS232 virtuale su porta USB, configurata in 9600,N,8,1
nessun controllo di flusso hw o sw.
Ho trovato questo documento che pare avvalorare la mia ipotesi di
buffering: http://goo.gl/K1mXc
> Marco
Grazie, ciao. Stefano.
Marco Trapanese
May 9, 2013, 5:45:15 AM5/9/13
to
Il 09/05/2013 11:31, Stefano ha scritto:
> I dati vengono visualizzati su controlli gauge sviluppati in DotNet,
> sistema operativo Windows Vista. Parte della frame contiene i valori di
> accelerazione su due assi, ￜ tangibile visivamente in quanto, in seguito
> al movimento della device, l'ago del controllo gauge si muove in ritardo
> (1 s minimo).
Ipotizziamo 3 possibili cause:
> I dati vengono visualizzati su controlli gauge sviluppati in DotNet,
> sistema operativo Windows Vista. Parte della frame contiene i valori di
> accelerazione su due assi, ￜ tangibile visivamente in quanto, in seguito
> al movimento della device, l'ago del controllo gauge si muove in ritardo
> (1 s minimo).
a) il device invia le informazioni in ritardo
b) il software le riceve/elabora/visualizza con un certo delay
c) il gauge implementa un filtro per cui introduce lui stesso il ritardo
Io verificherei prima di tutto la b e la c. In maniera molto semplice
visualizzando i dati ricevuti tramite terminale seriale (hyperterminal o
meglio realterm) se il dispositivo supporta la modalitￜ freerun.
Io inserire uno stopwatch subito dopo la read dalla seriale stampando
sulla finestra di debug la stringa ricevuta e aggiungendo il timestamp.
Cercherei poi di sincronizzare il movimento del dispositivo con un
evento sul software (es. la pressione di un pulsante) cosￜ da verificare
se i valori di accelerazione vengono ricevuti immediatamente o davvero
dopo un secondo.
> Non vi sono perdite di frame in quanto il movimento ￜ fluido e la
> registrazione dello stesso su db ￜ senza soluzione di continuitￜ;
> Quindi peggiorativo rispetto alle mie considerazioni...
> Parliamo di una RS232 virtuale su porta USB, configurata in 9600,N,8,1
> nessun controllo di flusso hw o sw.
> Ho trovato questo documento che pare avvalorare la mia ipotesi di
> buffering: http://goo.gl/K1mXc
o come suggerito dal documento.
Marco
Stefano
May 9, 2013, 6:20:30 AM5/9/13
to
Marco Trapanese ha spiegato il 09/05/2013 :
e questo si evince dalla serializzazione in db. E' però difficile
recuperare i dati stante alla tempistica. Ho provato con realterm ma mi
mancava il mezzo di sincronizzazione con il timestamp (per esempio un
tasto come da te indicato, lo implementerò)
> b) il software le riceve/elabora/visualizza con un certo delay
Vi è una procedura di parsing per l'estrazione del messaggio coerente e
compreso tra STX ed ETX. Però se così fosse dovrei notarlo anche
nell'applicazione di test che utilizza un timer in luogo della seriale.
> c) il gauge implementa un filtro per cui introduce lui stesso il ritardo
Ho scritto a tale proposito alla casa madre (produttrice del gauge) ed
hanno realizzato la medesima applicazione che ho sviluppato io (con
timer) senza rilevare nulla, non hanno filtri che possano cagionare il
problema. Pensavo potesse essere un problema di thread e di
assegnazione del tempo di carico ma non sono pervenuto ad una soluzione
- replicando il problema - nonostante le numerose prove effettuate.
>
> Io verificherei prima di tutto la b e la c. In maniera molto semplice
> visualizzando i dati ricevuti tramite terminale seriale (hyperterminal o
> meglio realterm) se il dispositivo supporta la modalità freerun.
una semplice applicazione con Arduino che inviasse la stessa frame su
seriale con le medesime tempistiche. Eventualmente potrei associarvi
anche un tasto hardware in modo da poter avere un'idea del tempo di
reazione.
>
>> Non vi sono perdite di frame in quanto il movimento è fluido e la
>> registrazione dello stesso su db è senza soluzione di continuità;
limitato a disconnettere e riconnettere la seriale, cambiare porta usb
e riavviare l'applicazione. In nessuno di questi casi si è notato alcun
miglioramento ma il ritardo persisteva. L'unico modo di risolvere pare
essere il completo riavvio della macchina, il che mi ha fatto pensare
al buffer. Non è un evento che capita sempre ma occasionalmente e
questo complica il debug. La prossima volta proverò ad azzerare il
buffer o configurarlo come descritto nel documento.
> Marco
Grazie, ciao. Stefano.
> Il 09/05/2013 11:31, Stefano ha scritto:
>
>
> Ipotizziamo 3 possibili cause:
>
> a) il device invia le informazioni in ritardo
La device invia informazioni in continuo, la frame risulta valorizzata
>
>
> Ipotizziamo 3 possibili cause:
>
> a) il device invia le informazioni in ritardo
e questo si evince dalla serializzazione in db. E' però difficile
recuperare i dati stante alla tempistica. Ho provato con realterm ma mi
mancava il mezzo di sincronizzazione con il timestamp (per esempio un
tasto come da te indicato, lo implementerò)
> b) il software le riceve/elabora/visualizza con un certo delay
compreso tra STX ed ETX. Però se così fosse dovrei notarlo anche
nell'applicazione di test che utilizza un timer in luogo della seriale.
> c) il gauge implementa un filtro per cui introduce lui stesso il ritardo
hanno realizzato la medesima applicazione che ho sviluppato io (con
timer) senza rilevare nulla, non hanno filtri che possano cagionare il
problema. Pensavo potesse essere un problema di thread e di
assegnazione del tempo di carico ma non sono pervenuto ad una soluzione
- replicando il problema - nonostante le numerose prove effettuate.
>
> Io verificherei prima di tutto la b e la c. In maniera molto semplice
> visualizzando i dati ricevuti tramite terminale seriale (hyperterminal o
>
> Io inserire uno stopwatch subito dopo la read dalla seriale stampando sulla
> finestra di debug la stringa ricevuta e aggiungendo il timestamp.
> Cercherei poi di sincronizzare il movimento del dispositivo con un evento sul
> software (es. la pressione di un pulsante) così da verificare se i valori di
> Io inserire uno stopwatch subito dopo la read dalla seriale stampando sulla
> finestra di debug la stringa ricevuta e aggiungendo il timestamp.
> Cercherei poi di sincronizzare il movimento del dispositivo con un evento sul
> accelerazione vengono ricevuti immediatamente o davvero dopo un secondo.
>
Purtroppo non ho sempre a disposizione lo strumento, volevo realizzare
>
una semplice applicazione con Arduino che inviasse la stessa frame su
seriale con le medesime tempistiche. Eventualmente potrei associarvi
anche un tasto hardware in modo da poter avere un'idea del tempo di
reazione.
>
>> Non vi sono perdite di frame in quanto il movimento è fluido e la
>> registrazione dello stesso su db è senza soluzione di continuità;
>
>
> Ottimo, verifica allora la coerenza con l'evento fisico.
>
>
>> Quindi peggiorativo rispetto alle mie considerazioni...
>> Parliamo di una RS232 virtuale su porta USB, configurata in 9600,N,8,1
>> nessun controllo di flusso hw o sw.
>> Ho trovato questo documento che pare avvalorare la mia ipotesi di
>> buffering: http://goo.gl/K1mXc
>
>
> Certo, ma come ti dicevo lo puoi azzerare tramite pannello di controllo o
> come suggerito dal documento.
>
Proverò, non disponendo della device se non per brevi periodi mi sono
>
> Ottimo, verifica allora la coerenza con l'evento fisico.
>
>
>> Quindi peggiorativo rispetto alle mie considerazioni...
>> Parliamo di una RS232 virtuale su porta USB, configurata in 9600,N,8,1
>> nessun controllo di flusso hw o sw.
>> Ho trovato questo documento che pare avvalorare la mia ipotesi di
>> buffering: http://goo.gl/K1mXc
>
>
> Certo, ma come ti dicevo lo puoi azzerare tramite pannello di controllo o
> come suggerito dal documento.
>
limitato a disconnettere e riconnettere la seriale, cambiare porta usb
e riavviare l'applicazione. In nessuno di questi casi si è notato alcun
miglioramento ma il ritardo persisteva. L'unico modo di risolvere pare
essere il completo riavvio della macchina, il che mi ha fatto pensare
al buffer. Non è un evento che capita sempre ma occasionalmente e
questo complica il debug. La prossima volta proverò ad azzerare il
buffer o configurarlo come descritto nel documento.
> Marco
Grazie, ciao. Stefano.
Marco Trapanese
May 9, 2013, 9:20:30 AM5/9/13
to
Il 09/05/2013 12:20, Stefano ha scritto:
> Pensavo potesse essere un problema di thread e di assegnazione
> del tempo di carico ma non sono pervenuto ad una soluzione - replicando
> il problema - nonostante le numerose prove effettuate.
Non avresti comunque ritardi di 1 secondo. E in ogni caso te ne
> Pensavo potesse essere un problema di thread e di assegnazione
> del tempo di carico ma non sono pervenuto ad una soluzione - replicando
> il problema - nonostante le numerose prove effettuate.
accorgeresti dai timestamp che risulterebbero ritardati.
Dici che il gauge a volte mostra i dati con un ritardo di 1 secondo
circa, ma il db registra correttamente tutti i frame inviati (tra
l'altro come lo deduci? c'è un counter?)
Considerato che hai la trasmissione di un pacchetto ogni 20-25 ms in un
secondo hai la bellezza di 40-50 pacchetti.
Per cui, ripeto, farei una cosa molto semplice:
1) avvia l'applicazione senza collegare la seriale e fai un flush del buffer
2) collega la seriale e stampa in debug le stringhe ricevute
*immediatamente dopo la read*, calcolando sempre il tempo tra la
ricezione di un pacchetto e il successivo
3) verifica contemporaneamente la lettura sul gauge
Un secondo è un tempo enorme... per cui dovresti poterti accorgere
facilmente a occhio di:
a) ritardo iniziale
b) nessun ritardo iniziale ma gap qua e là
c) nessun ritardo nelle stringhe stampate ma solo nella visualizzazione
Riporta poi l'esito!
Marco
Stefano
May 9, 2013, 9:58:03 AM5/9/13
to
Il 09/05/2013, Marco Trapanese ha detto :
grafici velocità/tempo e spazio/tempo.
Per questioni di performances però il salvataggio dei dati in db
avviene unicamente ad interfaccia grafica disabilitata. Dovrò eseguire
però delle modifiche per riportare anche il momento dell'avvio del
movimento device...attualmente viene preso come valore zero il
timestamp della prima frame ricevuta.
> Considerato che hai la trasmissione di un pacchetto ogni 20-25 ms in un
> secondo hai la bellezza di 40-50 pacchetti.
> Per cui, ripeto, farei una cosa molto semplice:
>
> 1) avvia l'applicazione senza collegare la seriale e fai un flush del buffer
> 2) collega la seriale e stampa in debug le stringhe ricevute *immediatamente
> dopo la read*, calcolando sempre il tempo tra la ricezione di un pacchetto e
> il successivo
> 3) verifica contemporaneamente la lettura sul gauge
>
> Un secondo è un tempo enorme... per cui dovresti poterti accorgere facilmente
> a occhio di:
>
> a) ritardo iniziale
> b) nessun ritardo iniziale ma gap qua e là
> c) nessun ritardo nelle stringhe stampate ma solo nella visualizzazione
>
> Riporta poi l'esito!
> Marco
Proverò non appena in possesso della device e farò sapere.
Ciao. Stefano.
> Il 09/05/2013 12:20, Stefano ha scritto:
>
>> Pensavo potesse essere un problema di thread e di assegnazione
>> del tempo di carico ma non sono pervenuto ad una soluzione - replicando
>> il problema - nonostante le numerose prove effettuate.
>
>
> Non avresti comunque ritardi di 1 secondo. E in ogni caso te ne accorgeresti
> dai timestamp che risulterebbero ritardati.
>
> Dici che il gauge a volte mostra i dati con un ritardo di 1 secondo circa, ma
> il db registra correttamente tutti i frame inviati (tra l'altro come lo
> deduci? c'è un counter?)
>
Viene serializzato il timestamp che serve per la visualizzazione dei
>
>> Pensavo potesse essere un problema di thread e di assegnazione
>> del tempo di carico ma non sono pervenuto ad una soluzione - replicando
>> il problema - nonostante le numerose prove effettuate.
>
>
> Non avresti comunque ritardi di 1 secondo. E in ogni caso te ne accorgeresti
> dai timestamp che risulterebbero ritardati.
>
> Dici che il gauge a volte mostra i dati con un ritardo di 1 secondo circa, ma
> il db registra correttamente tutti i frame inviati (tra l'altro come lo
> deduci? c'è un counter?)
>
grafici velocità/tempo e spazio/tempo.
Per questioni di performances però il salvataggio dei dati in db
avviene unicamente ad interfaccia grafica disabilitata. Dovrò eseguire
però delle modifiche per riportare anche il momento dell'avvio del
movimento device...attualmente viene preso come valore zero il
timestamp della prima frame ricevuta.
> Considerato che hai la trasmissione di un pacchetto ogni 20-25 ms in un
> secondo hai la bellezza di 40-50 pacchetti.
> Per cui, ripeto, farei una cosa molto semplice:
>
> 1) avvia l'applicazione senza collegare la seriale e fai un flush del buffer
> 2) collega la seriale e stampa in debug le stringhe ricevute *immediatamente
> dopo la read*, calcolando sempre il tempo tra la ricezione di un pacchetto e
> il successivo
> 3) verifica contemporaneamente la lettura sul gauge
>
> Un secondo è un tempo enorme... per cui dovresti poterti accorgere facilmente
> a occhio di:
>
> a) ritardo iniziale
> b) nessun ritardo iniziale ma gap qua e là
> c) nessun ritardo nelle stringhe stampate ma solo nella visualizzazione
>
> Riporta poi l'esito!
> Marco
Ciao. Stefano.
0 new messages