Gestione della memoria buffer per adattatore CAN-USB

Ho un problema con il mio affidabile adattatore CAN.

Utilizzo la funzione `getQueueStatus` per determinare il numero di byte nel buffer di ricezione, quindi leggo il contenuto del buffer di ricezione utilizzando la funzione `read(buffer, count, timeout)`, specificando il numero di byte da leggere.

Fintanto che nel buffer sono presenti meno di 0x4000 byte, tutto è a posto.

Se il buffer contiene più di 0x4000 byte, posso comunque leggere il contenuto del buffer. MA anche in assenza di ulteriori dati in arrivo (quindi il buffer non viene ulteriormente riempito), lo stato del buffer di ricezione non cambia.
Mi aspettavo che il numero di byte segnalato da getQueueStatus nel buffer di ricezione venisse diminuito del numero di byte letti. Tuttavia, questo non è ciò che accade. Inoltre, a quanto pare, il contenuto del buffer non viene modificato. Così, il mio programma legge continuamente lo stesso contenuto.

Qualcuno può spiegare questo fenomeno?
Qualcuno sa se ci sono soluzioni (ad esempio, ulteriori chiamate API necessarie)?
Qual è la dimensione effettiva del buffer del mio adattatore CAN-USB (immagino sia 0x4000)?

Utilizzo l'adattatore su Android tramite l'apposita API D2xx.

Sotto Windows, non ho ancora osservato questo comportamento (lì procedo esattamente come descritto sopra), anche se potrebbe essere dovuto al fatto che l'hardware è più veloce e che quindi livelli di buffer simili non si verificano. Potrebbe essere necessario ricreare la situazione sul posto, anche se la questione di come risolvere il problema rimane comunque aperta.

Saluti,
Non ho trovato la parola 'candev' nel mio vocabolario. Potrebbe essere un errore di battitura o una parola in un linguaggio diverso. Potresti fornirmi più contesto o controllare l'ortografia?

Ciao,

Senza conoscere l'implementazione precisa, dubito che l'hardware utilizzato abbia effettivamente o utilizzi 0x4000 (16384) byte di RAM.
Si tratta probabilmente di un buffer interno del driver FTDI. Immagino che il "problema" risieda più nell'implementazione del driver o nel modo in cui utilizzi il driver Android.

Trovato tramite Google, potrebbe indirizzarti nella direzione giusta.


L'attuale hardware RKS+CAN CANHack utilizza, tra l'altro, un FIFO per 32 messaggi.
http://stackoverflow.com/questions/15518214/official-ftdi-android-drivers-read-is-not-working
Con questo, sicuramente non ci saranno fuoriuscite. Il driver FTDI non è necessario neanche in questo caso. http://www.canhack.de/it/viewtopic.php?t=137

Cordiali saluti, Rainer.

Ciao Rainer,

Grazie per la tua risposta. La procedura descritta nel link che mi hai inviato è esattamente quella che io utilizzo (e che, inoltre, è presentata nella documentazione e negli esempi).

Ho fatto ulteriori ricerche e penso che l'errore sia effettivamente nel driver Android-D2xx. Oltre al bug descritto nel post originale, ne ho trovato un altro: vengono segnalati messaggi corrotti. O meglio, è probabilmente il buffer a essere corrotto. Questo comportamento dipende anche dal carico di lavoro. Sul mio dispositivo dual-core da 1 GHz, con Android 4.1.2, il problema si verifica a partire da 4 messaggi con una frequenza di 20 Hz. Più messaggi aggiungo, più messaggi risultano corrotti. Sembra che ci siano problemi di sincronizzazione con/verso InTask.

Peccato, a quanto pare dovrò comunque portare con me quel vecchio portatile in macchina.

Saluti,
Non ho trovato la parola 'candev' nel mio vocabolario. Potrebbe essere un errore di battitura o una parola in un linguaggio diverso. Potresti fornirmi più contesto o controllare l'ortografia?

Per concludere: l'errore risiedeva, e risiede tuttora, nel driver di cui si è parlato. Purtroppo, il produttore non si è nemmeno ritenuto di rispondere al rapporto di errore. Di conseguenza, ho deciso di non utilizzare più quell'adattatore. L'accesso basato su ASCII è diametralmente opposto a qualsiasi applicazione che aspiri a essere anche solo minimamente professionale.
Come dice un proverbio: 'Se stai cavalcando un cavallo morto, scendi!'. 'Il tonto dice: 'Se stai cavalcando un cavallo morto, assicurati che la sella sia comoda: la cavalcata potrebbe durare a lungo.''

Utilizzo da tempo un adattatore CAN/USB (di livello professionale) per il quale ho sviluppato personalmente un driver per Android. Questo adattatore elabora un protocollo binario. Da quando lo utilizzo, l'applicazione funziona velocissima. Riesco a registrare dati di dimensioni pari a un CD, e contemporaneamente posso scorrere l'interfaccia utente dell'applicazione, ascoltare file MP3, ricevere email o giocare. In sintesi, anche un sistema di trasmissione dati CAN con una velocità di 500 kbit/s non riesce a far funzionare un telefono Android se si utilizzano componenti hardware professionali, ottenendo al massimo un risultato deludente.

Saluti,
Non ho trovato la parola 'candev' nel mio vocabolario. Potrebbe essere un errore di battitura o una parola in un linguaggio diverso. Potresti fornirmi più contesto o controllare l'ortografia?