Matrix Abfrage wird langsamer/schlechter

[CProbst]

Betrifft: IOW40 - Windows XP - VStudio 2003

Ich polle die Werte der Matrix über Report 0x19 - kommt dann ein 0x19 lese ich noch den 0x1A. Nach jedem erkannten Tastendruck (Matrix Tastatur von Conrad) wird die Erkennung langsamer bzw. funktioniert schlechter. Beim Programmstart wird subjektiv jeder Tastendruck quittiert im Lauf der Zeit treten Fehler auf und einige Tastendrücke werden ignoriert.

Jetzt steht im Datenblatt, dass der IOW40 bei erkannten Events den Report 0x19 und 0x1A selbst sendet. Wohin und wie wird das Programm darüber informiert? Woanders steht auch, dass der IOW gar nicht selbst senden kann.

Gruß
Christian

[Guido Körber]

USB Devices können nicht von sich aus Daten senden, sondern müssen vom Host dazu aufgefordert werden, genau das tut der HID Treiber regelmäßig. Wenn der IO-Warrior dann Daten hat sendet er sie auch.

Also auf Anwendungsebene sieht es so aus, als wenn der IO-Warrior von selbst die Daten sendet. Die Matrixfunktion jedenfalls schickt die Daten bei Änderung des Status los. Das Senden des $19 Reports ist eigentlich nur nötig um zu einem beliebigen Zeitpunkt den aktuellen Status abzufragen.

Das Empfangen der Daten macht sich am besten mit einem separaten Thread, der den iowkitRead absetzt und dann blockiert bis Daten kommen.

[CProbst]

Thread - das wars - habe ich jetzt vestanden. Kann es aber sein, dass wenn ich nie einen IowKitRead mache sondern immer nur mit 0x19 anfordere darunter die Kommunikation leidet? Anders gefragt, können die bereit stehenden Reports den Chip bei Immediate Abfragen ausbremsen?

[Guido Körber]

Thread - das wars - habe ich jetzt vestanden. Kann es aber sein, dass wenn ich nie einen IowKitRead mache sondern immer nur mit 0x19 anfordere darunter die Kommunikation leidet? Anders gefragt, können die bereit stehenden Reports den Chip bei Immediate Abfragen ausbremsen?

Den Chip nicht, aber die Queue des HID Treibers hält nur eine gewisse Zahl von Reports und wenn die ohnehin reinkommenden Reports nicht gelesen werden kann es zu Durcheinander kommen.

[CProbst]

Danke! Das hat mir schon mal sehr geholfen. Ich finde das Teil richtig klasse!

[CProbst]

Kann es sein, dass zuerst der 0x1A und dann der 0x19 gelesen wird?

[Guido Körber]

Dem ist so.

[towaibw]

Noch einer, der einen Hinweis im Datenblatt gut gefunden hätte ;-)

[Robert Marquardt]

Matrixabfragen sind etwas fuer das IOWKIT 2.0 API (kommt wahrscheinlich im Februar).
Im neuen API gibt es erstens Callbacks und zweitens laeuft auch auf der zweiten Pipe ein interner Lesethread.

[towaibw]

Was haltet Ihr davon, für jede Special Mode Function, einen eigenen Callback vorzusehen? Dann müßte man nicht mehr die Reports voneinander unterscheiden. Nachteil dieser Lösung wäre allerdings, das bei jeder neuen Special Mode Function die lib erweitert werden muß.

Was passiert eigentlich in der 2.0, wenn meine Callbackfunktion 2 Minuten braucht, ehe sie wieder zurückkehrt? Ist der Callback mit einem weiteren Thread entkoppelt?

[Guido Körber]

Wir haben vor eine Art "Demultiplexer" für die Reports zu machen, so dass eine Funktion praktisch die Reports einer bestimmten ID abonnieren kann.

[Robert Marquardt]

Die Callbacks sind nicht entkoppelt. Man kann sie ja speichern und dann im Hauptthread verarbeiten.

[wayoda]

Was haltet Ihr davon, für jede Special Mode Function, einen eigenen Callback vorzusehen? Dann müßte man nicht mehr die Reports voneinander unterscheiden. Nachteil dieser Lösung wäre allerdings, das bei jeder neuen Special Mode Function die lib erweitert werden muß.

Das Verteilen und Bearbeiten der Reports anhand ihrer Report-ID macht, glaube ich zumindest, auch für den Programmierer weniger Arbeit als für jede Special-Mode Function eine eigene Callback-Methode zu implementieren.

Was passiert eigentlich in der 2.0, wenn meine Callbackfunktion 2 Minuten braucht, ehe sie wieder zurückkehrt? Ist der Callback mit einem weiteren Thread entkoppelt?

Das Entkoppeln der Callbacks in einem eigenen Thread ist nicht möglich, weil man ansonsten je nach Datenaufkommen und Applikationslogik schnell mal einige hundert Threads erzeugt hat, die u.U.nur darauf warten das der User endlich "ok" anklickt.

Wenn dann auch noch eine GUI ins Spiel kommt braucht man z.B. unter Java sowieso einen eignen Thread (SwingUtilities.invokeLater()) um ein repaint() aufgrund des Report zu veranlassen.

Eberhard