IOW40 VB

mchopra · Post by **mchopra** » Fri Jun 03, 2005 8:58 pm

Hey,

Benutze den IOW40 zusammen mit VB, Kommunikation passt, derzeit mache ich es folgendermassen:
- Über eine VB exe wird die Read Funktion ausgelösst und wartet dann auf einen Wert vom IOW40
- In VB ist es so das die READ sofort alles blockiert und immer auf einen Wert wartet und dann weitermacht

Meine Frage ist es möglich das wenn IOW40 etwas melden will er sich bei der Applikation meldet bzw. es reicht auch nur eine Meldung und meine Applikation geht daraufhin in die Read Funktion holt sich den Wert. Ist das möglich?

Danke

Robert Marquardt · Post by **Robert Marquardt** » Sat Jun 04, 2005 6:22 am

Noch nicht. Das ist ein Design fuer eine spaetere Version des API.
Im aktuellen API ist ReadImmediate dafuer zustaendig.

mchopra · Post by **mchopra** » Sat Jun 04, 2005 12:55 pm

Okay, eins noch hat der IOW40 eine internen Buffer, bedeutet dies wenn ich nun für 10Sek nicht den Status abfrage könnte ja in dieser Zeit etwas passiert sein, speichert der IOW alle Einträge oder werden diese imer mit dem letzten Event überschrieben?

mchopra · Post by **mchopra** » Sat Jun 04, 2005 1:38 pm

Mir ist nicht klar wie readimmediate zu verstehen ist:
- Ist es dafür da um abzufragen ob es daten am IOW gibt, sodass man dann die Read FUnktion startet und sich den Wert holt oder sollte man mit dem ReadImmediate sofort den aktuellen Wert erhalten?

mchopra · Post by **mchopra** » Sat Jun 04, 2005 2:33 pm

Anscheinend funktioniert das readimmediate mehr schlecht als recht, habe es nun so gemacht:
- Hab bei der Read FUnktion ein TimeOut gesetzt von 1sek, so simuliere ich ein ReadImmediate

Bei ReadImmediate habe ich foldene Ausgaben bekommen:
- Wenn ich meinen IOW40 angeschlossen habe bekamm ich den Wert ß
- Nach drücken einer Taste hat sich der Wert auf 1307649 (?!?), habe ich dann eine weitere Taste gedrückt hat sich der ReadImmediate wert nicht geändert

In der Doku steht doch ReadImmediate liefert eine true/false zurück, was nun? bitte um Erklärung

wayoda · Post by **wayoda** » Sat Jun 04, 2005 4:32 pm

Leider ist die Beschreibung von IowKitReadImmediate in der Datei "Windows DLL.pdf" leicht fehlerhaft. Ein Blick in die Quelldatei "readwrit.cpp" gibt da mehr Aufschluss.

Für IOWarrior mit einer Revisionsnummer > 1.0.1.0 (also alle IOWarrior mit Serialnumber) verwendet die Iowkit.dll den SpecialMode-Befehl :
"Getting current pin status" wie er im Datasheet zum IOWarrior Kapitel 5.10.4 beschrieben ist.

To get the port status just send a report with ID
$FF to interface 1
This will result in the current pin status to be
returned immediately in an input report with ID
$FF

Der Returnwert true/false zeigt lediglich an ob das Schreiben des Reports zum IOWarrior UND das Lesen des Ergebnisses vom IOWarrior geklappt hat!
Sollte die Funktion IowKitReadImmediate also false liefern ist der Wert im 2. Argument (PDWORD value) nicht zu benutzen. Er enthält nicht den aktuellen Portstatus.
Nur wenn die Funktion true liefert enthält das 2. Argument den aktuellen Portstatus!

Insofern ist die Beschreibung in "Windows DLL.pdf"

Return last value read from IO-Warrior pipe 0.
The function returns TRUE if a new value has arrived otherwise it returns FALSE and places the last
value read into value.

einfach falsch.

The function can only read the I/O pins via pipe 0 so it does not need a numPipe parameter.

und außerdem wird gerade von dieser Funktion pipe 1 benutzt!

Aber an dieser Stelle würde ich gerne selbst mal eine Frage loswerden über die ich mir schon länger Gedanken mache. Im Datasheet steht wie gesagt :

This will result in the current pin status to be
returned immediately in an input report with ID
$FF

trifft diese Aussage auch zu wenn ich z.B. bei einem IOWarrior24 den RC5-Mode aktiviert habe und zufällig gerade eine Kommando empfangen wurde? Werden diese zwei Ereignisse (Abfrage ReportId $FF, RC5-code) also in jedem Fall so serialisiert das auf jeden Fall der IOStatus auf die Abfrage geliefert wird?
Grund für die Frage ist, das die function IowKitReadNow leider nicht überprüft, ob der vom IOWarrior gelesene Report tatsächlich die ReportID $FF im ersten Byte hat. Wenn sich also hier ein Report mit RC5-Kommandos, oder auch vom "SwitchMatrixMode" reinschmuggelt gibts natürlich Probleme.

Bzgl. der Fragen von mchopra:

- Wenn ich meinen IOW40 angeschlossen habe bekamm ich den Wert ß

ein ß kommt mir seltsam vor als Wert für ein unsigned int

- Nach drücken einer Taste hat sich der Wert auf 1307649 (?!?), habe ich dann eine weitere Taste gedrückt hat sich der ReadImmediate wert nicht geändert

Wie gesagt liefert IowKitReadImmediate den aktuellen Portstatus, keine Änderungen. Der Test müsste also folgendermaßen sein.

Code: Select all

ReadImmediate aufrufen;
Taste drücken und festhalten;
ReadImmediate nochmal aufrufen;
Taste loslassen;

Beim 2. Aufruf von ReadImmediate sollte sich das entsprechende Bit geändert haben.

Eberhard

mchopra · Post by **mchopra** » Sat Jun 04, 2005 5:02 pm

D.h. die readimmediate kann man nicht für foldendes Ereignis einsetzen:
- Ich habe eine VB exe die andauerend im loop läuft und readimmediate aufruft und das Ziel hat zu schaun ob neue Daten vorliegen, d.h. jemand hat eine Taste gedrückt geht das nun mit readimmediate?

so wie ich dich verstanden habe gibt readimmediate den JETZT Wert zurück, oder?

Robert Marquardt · Post by **Robert Marquardt** » Sun Jun 05, 2005 6:51 am

Das mit der internen Benutzung von "$FF to interface 1" fuer IowKitReadImmediate ist ein Designfehler.
Ich werde daher auf die Methode fuer alte IO-Warrior umstellen.
Das mit dem Test auf den korrekten Report $FF in der Antwort funktioniert auch nicht zuverlaessig.
Erstens wird dadurch ein anderer Report gestohlen und zweitens kann der Report verlorengehen. Dann aber verkeilt sich die Lesefunktion, da sie dann permanent auf einen $FF Report wartet, der nicht mehr kommen kann.

So jetzt nochmal die Erklaerung wie IowKitReadImmediate funktioniert (bzw funktionieren sollte).
Es wird ein intern ein Thread getartet, der permanent die Pipe 0 liest. Genaugenommen ist dies ein eigenes Geraet. Auf jeden Fall hat es einen separaten File-Handle und daher keinen Einfluss auf Pipe 1.
IowKitReadImmediate kommt immer sofort zurueck und sagt mit seinem Rueckgabewert an, ob sich der Wert gegenueber dem letzten Aufruf geaendert hat oder nicht.

wayoda · Post by **wayoda** » Sun Jun 05, 2005 12:37 pm

mchopra wrote:D.h. die readimmediate kann man nicht für foldendes Ereignis einsetzen:
- Ich habe eine VB exe die andauerend im loop läuft und readimmediate aufruft und das Ziel hat zu schaun ob neue Daten vorliegen, d.h. jemand hat eine Taste gedrückt geht das nun mit readimmediate?

Falls dein Programm nichts anderes tut als per ReadImmediate die Eingänge abzufragen (also kein RC5-Mode, keine Leseoperationen am IIC-Bus etc.) sollte das schon funktionieren, da in diesem Fall die "Getting current pin status"-Reports einzige Art von Daten sind, die der IOWarrior auf interface 1 schickt.
Den Test ob sich zwischen zwei per ReadImmediate-Aufrufen der Zustand der Eingänge verändert hat (Taste gedrückt oder losgelassen), mußt Du allerdings selbst implementieren.
Der return-wert TRUE bei ReadImmediate zeigt (unter der obigen Einschränkung) an, dass der SpecialModeBefehl "Getting current pin status" erfolgreich zum IOWarrior geschrieben und mit einem Report beantwortet wurde.
Der return-wert FALSE zeigt an, das entweder:
- das Schreiben des Reports "Getting current pin status" fehlgeschlagen ist
- das Lesen der Antwort vom IOWarrior fehlgeschlagen ist
- oder, das in einem der beiden zuvor genannten Fälle der interne timeout von jeweils 1000ms überschritten wurde.
Auf jeden Fall gilt: ein Rückgabewert von FALSE zeigt an das die Daten die nun im Parameter value stehen nicht benutzt werden können.

mchopra wrote:
so wie ich dich verstanden habe gibt readimmediate den JETZT Wert zurück, oder?

Ist natürlich ein Allgemeinplatz, aber bei Computern ist der Wert JETZT immer sehr relativ und der USB-Bus relativiert da sogar noch ein wenig mehr.
Lässt man mal die Faktoren allg. Systemlast, Anzahl der Geräte am USB-Bus usw. außer Acht, sollte die Funktion ReadImmediate nach wenigen (geschätzt >16) Millisekunden ein Ergebnis liefern.
Die gute Nachricht ist jedoch hierbei, dass ReadImmediate nach etwa 1 Sekunde mit FALSE zurückkehrt wenn das Schreiben des Reports zum IOWarrior nicht geklappt hat und nach spätestens nach insgesamt 2 Sekunden mit FALSE zurückkehrt, falls der IOWarrior nicht antwortet.
Das erscheint natürlich ganz schön lang, aber soweit mir bekannt ist, hat ein USB-Gerät eigentlich sogar 5 Sekunden Zeit auf Befehle vom Usb-Host zum Gerät zu reagieren, bevor das Betriebssystem einen Timeout-Fehler am USB-Bus annimmt.

Eberhard

Robert Marquardt · Post by **Robert Marquardt** » Mon Jun 06, 2005 10:04 am

Ich habe einen Versuch unternommen die DLL umzuschreiben, aber das ist noch nicht gelungen. Da muss ich noch dran gruebeln.

mchopra · Post by **mchopra** » Mon Jun 06, 2005 1:45 pm

Gut dann verlasse ich mich auf die Read Funktion, kann es sein das es bei dieser Funktion Speicherprobleme gibt, bei meiner Applikation muss ich die ReadFunktion über einen Zeitraum von 14 Stunden machen, bedeutet wenn ich einen Wert bekomme macht meine Applikation was und wenn der Befehl abgearbeitet ist geht sie zurück in den Read Modus, gibt es hier Erfahrungswerte,