CAN-USB Adapter Pufferverwaltung

Ich habe ein Problem mit meinem treuen CAN Adapter.

Ich ermittele mit getQueueStatus die Anzahl Bytes im Empfangspuffer und lese dann mit read(buffer, count, timeout) unter Angabe der zu lesenden Anzahl von Bytes den Empfangspuffer aus.

Solange weniger als 0x4000 Bytes im Puffer sind ist auch alles ok.

Sind mehr als 0x4000 Bytes im Puffer, kann ich den Puffer zwar auslesen. ABER auch ohne weiteren Empfang (der Puffer wird also nicht weiter befüllt) ändert sich am Zustand des Empfangspuffers nichts.
Ich hatte erwartet, dass die von getQueueStatus gemeldete Anzahl Bytes im Empfangspuffer um die Anzahl gelesener Bytes reduziert würde. Das ist aber nicht der Fall. Auch wird offenbar der Pufferinhalt nicht verändert. So liest mein Programm dann ewig immer den gleichen Inhalt.

Kann jemand dieses Phänomen erklären?
Weiss jemand Abhilfe (z.B. weitere erforderliche API-Calls)?
Wie groß ist eigentlich der Puffer meines CAN-USB Adapters (ich tippe auf 0x4000)?

Ich verwende den Adapter unter Android mittels entsprechender D2xx-API.

Unter Windows habe ich das Verhalten noch nicht beobachtet (dort gehe ich genauso vor wie oben beschrieben), was aber auch daran liegen kann, dass dort die Hardware schneller ist und ähnliche Pufferstände erst gar nicht auftreten. Muss ich evtl. dort auch mal nachstellen - wobei dann nach wie vor die Frage nach der Abhilfe bleibt.

Gruß,
candev

Hallo,

ohne die genaue Implementierung zu kennen, bezweifle ich daß die verwendete Hardware überhaupt 0x4000 (16384) Bytes RAM hat/nutzt.
Es dürfte sich um einen internen Puffer des FTDI Treibers handeln. Vermute das "Problem" eher in der Treiberimplementierung oder in der Art und Weise, wie Du den Android Treiber nutzst.

Per Google gefunden und bringt Dich evtl in die richtige Richtung:
http://stackoverflow.com/questions/15518214/official-ftdi-android-drivers-read-is-not-working

Die aktuelle RKS+CAN CANHack Hardware nutzt übrigens einen FIFO für 32 Nachrichten:
http://www.canhack.de/viewtopic.php?t=137
Damit gibts sicher keine Überläufe. Der FTDI-Treiber ist auch nicht notwendig.

Viele Grüße, Rainer

Hallo Rainer,

danke für Deine Antwort. Das in Deinem Link beschriebene Vorgehen ist exakt das von mir praktizierte (und zudem das in der Doku und in den Samples vorgestellte).

Ich habe ein wenig weiter geforscht und denke, dass der Fehler in der Tat im Android-D2xx-Treiber zu suchen ist. Neben dem im Eingangspost beschriebenen Bug habe ich noch einen anderen gefunden, es werden Messages korrumpiert gemeldet. Oder besser gesagt ist wohl der Buffer korrumpiert. Dieses Verhalten ist zudem lastabhängig. Auf einem Dualcore mit 1GHz tritt es bei mir unter Android 4.1.2 ab 4 Messages mit je 20 Hz auf. Je mehr Messages ich dann dazu nehme, desto mehr Messages werden korrumpiert. Scheint als ob das Syncen mit/in der InTask Probleme bereitet.

Schade eigentlich, dann muss ich wohl doch immer den ollen Laptop mit zum Auto schleppen.

Gruß,
candev

Um die Sache abzuschließen: der Fehler lag bzw. liegt - wie vermutet - im o.g. Treiber. Der Hersteller sah sich leider nichtmal zu einer Antwort auf den Fehlerreport genötigt. Ich habe mich daraufhin von dem Adapter verabschiedet. Der ASCII-basierte Zugang ist eh diametral zu jeglicher halbwegs professionellen Anwendung.
Wie heißt es so schön? Der Kluge sagt: 'Wenn du ein totes Pferd reitest dann steig ab!'. Der Dumme sagt: 'Wenn du eine totes Pferd reitest dann sorge für einen bequemen Sattel - der Ritt könnte länger dauern.'

Ich verwende seit dem einen (Profi-)CAN/USB-Adapter, für den ich mir einen entsprechenden Android-Treiber selbst geschrieben habe. Der Adapter frisst selbstmurmelnd ein binäres Protokoll. Seitdem rennt die Anwendung wie ein Windhund. Ich logge Datenaufschriebe in CD-Länge, kann dabei noch in der Anwendung die UI scrollen und nebenher noch MP3s hören, Mails empfangen oder Spielen. Kurzum. selbst ein mit 500 kBit/s blasender Antriebs-CAN entlockt dem Android-Handy nur eine müdes Lächeln sofern man auf Profi-Hardware setzt.

Gruß,
candev