Matrix Abfrage wird langsamer/schlechter
Moderator: Guido Körber
Matrix Abfrage wird langsamer/schlechter
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
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
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Matrix Abfrage wird langsamer/schlechter
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.
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.
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
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 wrote: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?
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
-
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm
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?
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?
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
-
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm
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.towaibw wrote: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 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.towaibw wrote: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?
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