Legge i dati da un dispositivo tramite porta USB ad alta frequenza

Naviga le tue risposte
3

Ho bisogno di sapere se posso ottenere dati di accelerazione da un IMU a 500Hz via USB.

Ho letto il codice fornito dal produttore e sto cercando di migliorarlo. Al momento non posso andare più veloce di 166Hz. Cose che ho provato:

  • Passa dalla modalità streaming al polling. Il motivo è che in modalità streaming l'SDK del produttore utilizza la libreria ioctl per sapere se ci sono nuovi dati da leggere. Il più veloce andrei era 10Hz. Nella modalità di polling, ogni dato N millisecondi viene letto dalla porta usando un comando di lettura standard. Sono passato da 10 Hz a 166 Hz, ovvero, per N = 6. Ma con N < 6 non ho alcun miglioramento. 166Hz è un soffitto in questo momento.

  • Aumentata la priorità del processo. Questo non ha alcun effetto. Forse perché sto solo eseguendo il browser e il codice su cui sto lavorando?

Sì, so che Linux non è un sistema in tempo reale. Alla fine del giorno dovrò vivere con quello. Potrei usare xenomai più tardi nel codice. Ma adesso ho bisogno di sapere quanto posso andare veloce. Non in teoria, ma in una vera applicazione. Qualche idea su come aumentare le prestazioni?

EDIT: Questi sono i timestamp del momento in cui ottengo i dati, in millisencod. Nota gli scoppi. 

 1449258970519 
 1449258970519 
 1449258970525 
 1449258970531 
 1449258970531 
 1449258970543 
 1449258970543 
 1449258970543 
 1449258970549 
 1449258970555 
 1449258970555 
 1449258970562 
 1449258970567 
 1449258970567 
 1449258970573 
 1449258970579 
 1449258970579 
 1449258970585

EDIT: La quantità di dati che devo trasferire è molto piccola ... diciamo al massimo 16 float, più alcune intestazioni. Posso tranquillamente supporre che 128 byte siano sufficienti. Quindi 128x1000 è ancora MOLTO inferiore ai 480 Mpbs che USB 2 offre.

    
posta cauchy 03.12.2015 - 15:46
fonte

3 risposte

0

Dopo aver guardato un bel registro, aver letto i manuali e aver ricevuto un po 'di output dalla mailing list del kernel Linux Linux, ho intenzione di dire che non è una buona idea usare un USB per il trasferimento continuo dei dati a 500Hz.

All'inizio pensavo che sarebbe stato possibile, e la matematica lo ha dimostrato. Significato, se USB 2.0 offre 480 Mb, dovrei essere in grado di eseguire il polling del mio imu per alcuni float a 500Hz. Penso che mi servisse al massimo 128kps. Bene, come proposto da qualcuno alla mailing list del kernel di Linux (qualcuno che ha risposto molto gentilmente a tutte le mie domande!) Ho profilato il trasferimento dei dati ed è arrivato a 27 Kbs, che è molto più basso del teorico 480 Mpbs di USB 2.0.

Quindi, in diversi punti ho trovato riferimento ai problemi di "burst" nei dati USB. Per ragioni che non comprendo ancora completamente, è così che funziona il driver USB.

Quindi, per frequenze superiori a 150 (forse anche inferiori), USB non è il tuo ragazzo se hai bisogno di ottenere dati a intervalli regolari.

Ho testato driver diversi, su computer diversi, ottenendo sempre un risultato simile. Dati in burst dopo un intervallo di campionamento di 6 ms.

    
risposta data 07.12.2015 - 16:48
fonte
5

Puoi ottenere 166Hz .. è interessante perché pensavo che il tasso di polling predefinito per USB fosse 125Hz.

Tuttavia, probabilmente dovrai modificare il tuo kernel, i driver / usb / input / hid-core.c - imposta il tasso di polling lì. C'è un bel po 'di informazioni su internet sull'aggiornamento dei tassi di polling del mouse a 1000Hz (quei giocatori ....) con un tweak alla configurazione. Potrebbe avere alcune informazioni rilevanti per il tuo dispositivo.

Probabilmente dovrai pubblicare questa domanda su una scheda Linux per ottenere comunque informazioni dettagliate.

L'altra alternativa è il buffer: la maggior parte dei casi non importa se si esegue il polling a 100Hz se ognuno legge 10 comandi di dati!

    
risposta data 03.12.2015 - 16:44
fonte
3

Da 500 Hz a USB, assumendo dati a 8 o 16 bit, non dovrebbe essere un problema. Ho lavorato su un'applicazione che campionava 4 canali a 16 bit a 8kHz, e non ho nemmeno dovuto prendere in considerazione l'idea di leggerlo così velocemente.

Come stai colpendo il tuo soffitto 166Hz? Sei al 100% di utilizzo della CPU sul client? Stai colpendo il 100% di utilizzo sul tuo dispositivo USB? Quale interfaccia USB stai usando? È personalizzato dal produttore del dispositivo o utilizza qualcosa di simile a un chip USB-UART FTDI?

Per alcuni dispositivi e interfacce c'è un modo per specificare quanti byte devono essere memorizzati nel buffer prima che il sistema operativo indichi che c'è qualcosa da leggere. Impostalo su 1 byte e verifica se questo risolve i tuoi problemi.

Senza ulteriori dettagli specifici su quale dispositivo, quale interfaccia e come stai comunicando via USB, non possiamo risolvere i tuoi problemi, possiamo solo ipotizzare.

Modifica: se hai bisogno del tuo software per prendere una decisione e rispondere a una granularità di 500hz, sei sfortunato, poiché nessun sistema operativo desktop è abbastanza in tempo reale per farlo in modo affidabile. Se hai solo bisogno di leggere i dati e prendere una decisione "ogni tanto" come in ogni 10 secondi di millisecondo o meno frequentemente, allora starai bene.

    
risposta data 03.12.2015 - 20:35
fonte

Leggi altre domande sui tag

Dovremmo dedicare tempo alle riparazioni e alle implementazioni UAT come parte di uno sprint? Qual è il modo più idiomatico per iterare la raccolta con azioni diverse per il primo elemento?