Ohne genauere Infos kann ich da nicht viel sagen.
Welche Delphiversion, welche Windowsversion und genaue Fehlermeldung sind noetig.
8x8 Tastatur
Moderator: Guido Körber
Hallo zusammen,
Ich möchte auch den Matrix-Mode brauchen, allerdings nicht aus VB (...
), sondern aus C/C++, und zwar unter Windows und Linux, und ohne Polling (ich will also die im Matrix-Mode "unaufgefordert" gesendeten $19/$1A-Report-Paare erwischen).
Wenn ich die bisherige Diskussion plus die Doku richtig verstanden habe, dann fällt eine Event-Loop Lösung mit iowKitReadImmediate() schon deshalb weg, weil iowKitReadImmediate() nicht vom Interface 1 lesen kann (Zitat aus der Doku: "There is no non-blocking read for pipe 1 (Special Mode Functions) because pipe 1 has a command interface where you write a command and then read the answer." - was für den Matrix-Mode m.E. nicht ganz stimmt...)
Gehe ich richtig in der Annahme, dass der "richtige" Weg sowohl in Win als auch Linux ein separater Lesethread ist, der in einer Schleife dauernd iowKitRead() auf dem Interface 1 macht? Und dass die Implementation von iowKitReadImmediate() an sich genau das auch macht (allerdings nur für das Interface 0)? Was mir unklar ist: Der thread, dessen Handle man unter win mit IowKitGetThreadHandle() bekommt, ist das eben der Hilfsthread für iowKitReadImmediate() oder noch ein weiterer Hilfsthread?
Schlussendlich: ist die iowKit Library soweit Thread-fest, das ich so einen Lesethread auf einem Interface laufen lassen kann und aus dem Haupthread gleichzeitig iowKitWrite()s an dasselbe Interface absetzen darf? Beide Threads würden dasselbe Handle aus einem einzigen IowKitGetDeviceHandle() verwenden. In der Doku steht zwar, dass die Library ab 1.4 thread-safe sei, aber das sagt mir noch nicht, ob die Handles das auch sind.
Vielen Dank im Voraus für ein paar klare Jas oder Neins...
Ich möchte auch den Matrix-Mode brauchen, allerdings nicht aus VB (...
), sondern aus C/C++, und zwar unter Windows und Linux, und ohne Polling (ich will also die im Matrix-Mode "unaufgefordert" gesendeten $19/$1A-Report-Paare erwischen).Wenn ich die bisherige Diskussion plus die Doku richtig verstanden habe, dann fällt eine Event-Loop Lösung mit iowKitReadImmediate() schon deshalb weg, weil iowKitReadImmediate() nicht vom Interface 1 lesen kann (Zitat aus der Doku: "There is no non-blocking read for pipe 1 (Special Mode Functions) because pipe 1 has a command interface where you write a command and then read the answer." - was für den Matrix-Mode m.E. nicht ganz stimmt...)
Gehe ich richtig in der Annahme, dass der "richtige" Weg sowohl in Win als auch Linux ein separater Lesethread ist, der in einer Schleife dauernd iowKitRead() auf dem Interface 1 macht? Und dass die Implementation von iowKitReadImmediate() an sich genau das auch macht (allerdings nur für das Interface 0)? Was mir unklar ist: Der thread, dessen Handle man unter win mit IowKitGetThreadHandle() bekommt, ist das eben der Hilfsthread für iowKitReadImmediate() oder noch ein weiterer Hilfsthread?
Schlussendlich: ist die iowKit Library soweit Thread-fest, das ich so einen Lesethread auf einem Interface laufen lassen kann und aus dem Haupthread gleichzeitig iowKitWrite()s an dasselbe Interface absetzen darf? Beide Threads würden dasselbe Handle aus einem einzigen IowKitGetDeviceHandle() verwenden. In der Doku steht zwar, dass die Library ab 1.4 thread-safe sei, aber das sagt mir noch nicht, ob die Handles das auch sind.
Vielen Dank im Voraus für ein paar klare Jas oder Neins...
-
Robert Marquardt
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm
> was für den Matrix-Mode m.E. nicht ganz stimmt...
Genau, das ist ein kleiner Designfehler.
IowKitRead und IowKitReadImmediate verden intern von einem Thread beliefert, der die ankommenden Reports in eine kleine Queue stellt.
IowKitGetThreadHandle() liefert genau diesen Hilfsthread. Die Funktion ist nur der Vollstaendigkeit halber da damit man noetigenfalls die Threadprioritaet oder die Prozessorzuweisung aendern kann (auf eigenes Risiko).
Lesen und Schreiben ueber verschiedene Threads ist sicher, da Lesen und Schreiben jeweils eigene File-Handles haben.
Das sichert gegen eventuelle Serialisierungen im Treiber und Windows-Events (WaitForSingleObject etc) sind threadlokal und deshalb ist es besser einen Handle nur in einem Thread zu verwenden.
Ein Lesethread fuer Interface 1 ist der richtige Weg.
Genau, das ist ein kleiner Designfehler.
IowKitRead und IowKitReadImmediate verden intern von einem Thread beliefert, der die ankommenden Reports in eine kleine Queue stellt.
IowKitGetThreadHandle() liefert genau diesen Hilfsthread. Die Funktion ist nur der Vollstaendigkeit halber da damit man noetigenfalls die Threadprioritaet oder die Prozessorzuweisung aendern kann (auf eigenes Risiko).
Lesen und Schreiben ueber verschiedene Threads ist sicher, da Lesen und Schreiben jeweils eigene File-Handles haben.
Das sichert gegen eventuelle Serialisierungen im Treiber und Windows-Events (WaitForSingleObject etc) sind threadlokal und deshalb ist es besser einen Handle nur in einem Thread zu verwenden.
Ein Lesethread fuer Interface 1 ist der richtige Weg.
Hallo luz,
was Linux angeht noch ein paar Hinweise :
Ein kleiner Vorteil der Linux-Version ist jedoch dabei, daß man einen per IowkitSetTimeout eingestellten timeout für das Lesen völlig beliebig wählen kann. Auch ein Wert von 0 ist absolut problemlos. In diesem Fall kehrt die Lesefunktion einfach sofort zurück und hat dann entweder einen Wert gelesen, wenn er vorhanden war, oder nicht. Insofern gibt es unter Linux ein ReadImmediate auch für interface 1.
Die Empfehlung in der IowKit-Doku einen Wert >=1000ms zu wählen, kann unter Linux ignoriert werden.
Aber zum Thema timeout auch hier ein Hinweis. Ein per IowKitSetWriteTimeout eingestellter Wert wird unter Linux schlichtweg ignoriert. Statt dessen ist hier ein fester Wert von 5 Sekunden gesetzt, was nach der Spezifikation für den USB-Bus eben genau der Zeitspanne entspricht, die einem angeschlossenen Gerät zugestanden wird um einen Befehl (in diesem Fall Schreiben) auszuführen.
Eine größere Verzögerung in einem Write-Befehl ist allerdings, nach meinen bisherigen Erfahrungen, nur zu erwarten, wenn von der Gesamtheit der Geräte am USB-Bus ein großes Datenaufkommen erzeugt wird. 3 IOWarrior gleichzeitig zu bedienen war bei mir kein Problem. Bei einem Disconnect (ausstöpseln des IOWarrior) kehrt die Write-Funktion sofort zurück. Allgemein: Liefert IowKitWrite unter Linux 0 zurück, ist es Zeit eine Fehlermeldung auszugeben.
Eberhard
was Linux angeht noch ein paar Hinweise :
Ja, auch für Linux.luz wrote: Gehe ich richtig in der Annahme, dass der "richtige" Weg sowohl in Win als auch Linux ein separater Lesethread ist, der in einer Schleife dauernd iowKitRead() auf dem Interface 1 macht?
Ein kleiner Vorteil der Linux-Version ist jedoch dabei, daß man einen per IowkitSetTimeout eingestellten timeout für das Lesen völlig beliebig wählen kann. Auch ein Wert von 0 ist absolut problemlos. In diesem Fall kehrt die Lesefunktion einfach sofort zurück und hat dann entweder einen Wert gelesen, wenn er vorhanden war, oder nicht. Insofern gibt es unter Linux ein ReadImmediate auch für interface 1.
Die Empfehlung in der IowKit-Doku einen Wert >=1000ms zu wählen, kann unter Linux ignoriert werden.
Ja, auch für Linux.luz wrote: Schlussendlich: ist die iowKit Library soweit Thread-fest, das ich so einen Lesethread auf einem Interface laufen lassen kann und aus dem Haupthread gleichzeitig iowKitWrite()s an dasselbe Interface absetzen darf? Beide Threads würden dasselbe Handle aus einem einzigen IowKitGetDeviceHandle() verwenden. In der Doku steht zwar, dass die Library ab 1.4 thread-safe sei, aber das sagt mir noch nicht, ob die Handles das auch sind.
Aber zum Thema timeout auch hier ein Hinweis. Ein per IowKitSetWriteTimeout eingestellter Wert wird unter Linux schlichtweg ignoriert. Statt dessen ist hier ein fester Wert von 5 Sekunden gesetzt, was nach der Spezifikation für den USB-Bus eben genau der Zeitspanne entspricht, die einem angeschlossenen Gerät zugestanden wird um einen Befehl (in diesem Fall Schreiben) auszuführen.
Eine größere Verzögerung in einem Write-Befehl ist allerdings, nach meinen bisherigen Erfahrungen, nur zu erwarten, wenn von der Gesamtheit der Geräte am USB-Bus ein großes Datenaufkommen erzeugt wird. 3 IOWarrior gleichzeitig zu bedienen war bei mir kein Problem. Bei einem Disconnect (ausstöpseln des IOWarrior) kehrt die Write-Funktion sofort zurück. Allgemein: Liefert IowKitWrite unter Linux 0 zurück, ist es Zeit eine Fehlermeldung auszugeben.
Eberhard
Hallo,
es ist ja auch nicht meine Schuld, dass VB nichts taugt. Ich hatte nur kritisiert, dass nirgendwo die eingeschränkte VB Tauglichkeit erwähnt war. Schließlich werben Sie (bzw. Ihre Distributoren) ja mit der VB - Unterstützung. Also bitte.
Im Gegensatz zu vielen Informatikern hier im Forum (wenn ich mal deren Probleme zu Grunde lege), komme ich nun mal von der Hardware-Seite und habe es nicht so, mit den komplizierten Hochsprachen. Ich hatte zwar auch einige Wochensemesterstunden C++ aber nur für die Programmierung von MC’s usw.. VB habe ich nebenbei erlernt. Da gehört ja nicht viel zu, wenn man schon mal was vom Programmieren gehört hat. Damit ist es eben recht einfach mal eine Windows Applikation zu erstellen und auch ganz nützlich für Word und Excel. Ich habe auch keine Zeit jetzt noch nebenbei für mein privates Vergnügen noch eine Programmiersprache zu lernen. Es kann ja nun nicht jeder alles können. Soweit dazu.
Nun habe auch ich es geschafft, die Beispielprogramme unter Delphi ans laufen zu bringen. Aber Herr Marquardt hat völlig Recht, mir fehlt es an elementaren Kenntnissen in Delphi um mein Programm umzuschreiben bzw. ein in VB verwendbares OCX zu erzeugen.
Der Hersteller meiner bisher genutzten ISA-Karte hat ebenfalls die Zeichen der Zeit erkannt und bietet dieses System jetzt auch als USB Version an. Damit ist mein bisheriges Programm (mit 60 Eu’s kosten) in weniger als einer Stunde USB – Tauglich und es lohnt beim besten Willen nicht weiter darüber zu diskutieren.
Trotz allem Vielen Dank für die Hilfe!
Gruß
Mike
es ist ja auch nicht meine Schuld, dass VB nichts taugt. Ich hatte nur kritisiert, dass nirgendwo die eingeschränkte VB Tauglichkeit erwähnt war. Schließlich werben Sie (bzw. Ihre Distributoren) ja mit der VB - Unterstützung. Also bitte.
Im Gegensatz zu vielen Informatikern hier im Forum (wenn ich mal deren Probleme zu Grunde lege), komme ich nun mal von der Hardware-Seite und habe es nicht so, mit den komplizierten Hochsprachen. Ich hatte zwar auch einige Wochensemesterstunden C++ aber nur für die Programmierung von MC’s usw.. VB habe ich nebenbei erlernt. Da gehört ja nicht viel zu, wenn man schon mal was vom Programmieren gehört hat. Damit ist es eben recht einfach mal eine Windows Applikation zu erstellen und auch ganz nützlich für Word und Excel. Ich habe auch keine Zeit jetzt noch nebenbei für mein privates Vergnügen noch eine Programmiersprache zu lernen. Es kann ja nun nicht jeder alles können. Soweit dazu.
Nun habe auch ich es geschafft, die Beispielprogramme unter Delphi ans laufen zu bringen. Aber Herr Marquardt hat völlig Recht, mir fehlt es an elementaren Kenntnissen in Delphi um mein Programm umzuschreiben bzw. ein in VB verwendbares OCX zu erzeugen.
Der Hersteller meiner bisher genutzten ISA-Karte hat ebenfalls die Zeichen der Zeit erkannt und bietet dieses System jetzt auch als USB Version an. Damit ist mein bisheriges Programm (mit 60 Eu’s kosten) in weniger als einer Stunde USB – Tauglich und es lohnt beim besten Willen nicht weiter darüber zu diskutieren.
Trotz allem Vielen Dank für die Hilfe!
Gruß
Mike
Hallo,
nach dem Erscheinen der SDK 1.5 habe ich meinen IOW 40 wieder herausgeholt. Seit 3 Wochen läuft meine Anlage nun auch mit dem IOW. Bei der Umsetzung hatte ich allerdings einige Probleme.
Um den IOW zu schützen wollte ich die Taster und Schalter möglichst galvanisch vom IOW trennen. Dazu habe ich an den Sense Lines zwei vierfach Optokoppler LTV847 verwendet. An den Drive Lines habe ich von Anfang an auf die Optokoppler verzichtet und nur eine Transistor - Treiberstufe verwendet. Leider war die Falltime der Optokoppler (max. 18µs) höchstwahrscheinlich größer als die Lesegeschwindigkeit der Sense Lines des IOW. Damit hat dieser zwei übereinander liegende Tasten gelesen, obwohl nur Eine gedrückt war. Erst mit einem schnellen Optokoppler (Falltime 5µs) und einem zusätzlichen Pullup von 2,2k an den Sense Lines funktionierte das Lesen der Matrix einwandfrei.
Seit der IOW 40 Verbaut ist, und ich gefallen an dem Chip gefunden habe, besitze ich seit kurzem einen IOW 56. Beim experimentieren sind mir einige Kleinigkeiten aufgefallen. Falls ich recht habe, könnten Sie dies in einer späteren Version ja mal korrigieren.
1. In dem Beispiel für VB6 SPI Maxim6675 in der Routine
Private Sub Form_Unload(Cancel As Integer)
....
If Pid = IOWKIT_PID_IOW24 Then
I = IowKitWrite(IOWarrior, IOW_PIPE_SPECIAL_MODE, Report(0), 8)
Else
I = IowKitWrite(IOWarrior, IOW_PIPE_SPECIAL_MODE, Report(0), 8)
....
In der Zeile drüber sollte die 8 durch eine 64 ersetzt werden. Wenn ich Richtig liege.
Ich glaube nicht das es was macht, aber der Form halber.
2. Im Datenblatt für den IOW 56
Unter Punkt 4.2.5. Switch Matrix Mode Pins
In der Tabelle bei Y6 und Y7 steht 3.7. Ich denke das es bei Y6 0.6 und bei Y7 0.7 heißen sollte.
3. im Datenblatt für den IOW 56
Nach dem Punkt 5.10.5 fehlen entweder die Punkte 5.10.6 und 5.10.7 oder der Punkt 5.10.8 (Getting current pin status) sollte Punkt 5.10.6 werden.
Das sind sicher alles nur Kleinigkeiten, aber können den ein oder anderen ungeübten IOW - Nutzer doch etwas verwirren. Danke das Sie bis hier her gelesen haben.
nach dem Erscheinen der SDK 1.5 habe ich meinen IOW 40 wieder herausgeholt. Seit 3 Wochen läuft meine Anlage nun auch mit dem IOW. Bei der Umsetzung hatte ich allerdings einige Probleme.
Um den IOW zu schützen wollte ich die Taster und Schalter möglichst galvanisch vom IOW trennen. Dazu habe ich an den Sense Lines zwei vierfach Optokoppler LTV847 verwendet. An den Drive Lines habe ich von Anfang an auf die Optokoppler verzichtet und nur eine Transistor - Treiberstufe verwendet. Leider war die Falltime der Optokoppler (max. 18µs) höchstwahrscheinlich größer als die Lesegeschwindigkeit der Sense Lines des IOW. Damit hat dieser zwei übereinander liegende Tasten gelesen, obwohl nur Eine gedrückt war. Erst mit einem schnellen Optokoppler (Falltime 5µs) und einem zusätzlichen Pullup von 2,2k an den Sense Lines funktionierte das Lesen der Matrix einwandfrei.
Seit der IOW 40 Verbaut ist, und ich gefallen an dem Chip gefunden habe, besitze ich seit kurzem einen IOW 56. Beim experimentieren sind mir einige Kleinigkeiten aufgefallen. Falls ich recht habe, könnten Sie dies in einer späteren Version ja mal korrigieren.
1. In dem Beispiel für VB6 SPI Maxim6675 in der Routine
Private Sub Form_Unload(Cancel As Integer)
....
If Pid = IOWKIT_PID_IOW24 Then
I = IowKitWrite(IOWarrior, IOW_PIPE_SPECIAL_MODE, Report(0), 8)
Else
I = IowKitWrite(IOWarrior, IOW_PIPE_SPECIAL_MODE, Report(0), 8)
....
In der Zeile drüber sollte die 8 durch eine 64 ersetzt werden. Wenn ich Richtig liege.
Ich glaube nicht das es was macht, aber der Form halber.
2. Im Datenblatt für den IOW 56
Unter Punkt 4.2.5. Switch Matrix Mode Pins
In der Tabelle bei Y6 und Y7 steht 3.7. Ich denke das es bei Y6 0.6 und bei Y7 0.7 heißen sollte.
3. im Datenblatt für den IOW 56
Nach dem Punkt 5.10.5 fehlen entweder die Punkte 5.10.6 und 5.10.7 oder der Punkt 5.10.8 (Getting current pin status) sollte Punkt 5.10.6 werden.
Das sind sicher alles nur Kleinigkeiten, aber können den ein oder anderen ungeübten IOW - Nutzer doch etwas verwirren. Danke das Sie bis hier her gelesen haben.
-
Robert Marquardt
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm