IowKit-lib Version1.4 Windows und Linux Unterschiede

[wayoda]

Unterschiede im Verhalten der IowKit-Library für Windows und Linux

1. Öffnen der IOWarrior
Ein fundamentaler Unterschied besteht in der Art wie die Geräte geöffnet werden.
Unter linux erfolgt der Zugriff exclusiv, d.H. nur ein Prozess kann den
IOWarrior zum Lesen und Schreiben öffnen. Ein Versuch den IOWarrior ein zweites
mal zu Öffnen schlägt fehl, bis der IOWarrior wieder geschlossen wurde.

Unter Windows erfolgt der Zugriff shared, d.H. mehrere Prozesse können auf den IOWarrior
gleichzeitig lesend und schreiben zugreifen.

2. Unterschiede in der IowKit-library Version 1.4
Funktion : IowKitOpenDevice
Windows öffnet alle eingesteckten IOWarrior. Zwei Applikationen welche die Lib
benutzen sehen die gleichen Geräte.
Unter Linux kann nur eine Applikation die angeschlossenen IOWarrior öffnen. Für
eine zweite, später gestartete Applikation sind alle IOWarrior schon vergeben, daher
ist der Rückgabewert hier NULL.

Funktion : IowKitGetNumDevs
Wegen IowKitOpenDevice gilt
Windows liefert die Anzahl der Geräte in jeder Applikation
Linux liefert die Anzahl der Geräte nur in der zuerst gestarteten Applikation,
die zweite liefert 0.

Funktion : IowKitRead
Unterschiedliches Verhalten bzgl. eines gesetzen Timeouts.
Die Funktion IowKitSetTimeout setzt den Timeout für diese Funktion.
Unter Windows wird ein Wert >= 1000ms empfohlen.
Unter Linux ist ein timeout von 0 absolut zulässig. In diesem Fall
kehrt die Funktion sofort zurück, und hat falls vorhanden Daten gelesen oder eben nicht.
Dies gilt sowohl für Daten von den IO-Pins als auch von den SpecialModes.

Der Kommentar in der Doku :
"Linux does not have a ReportID byte of 0 for pipe 0 (I/O pins).
To be completely compatible with Windows libiowkit.so
adds that ReportID to the data."
kann ignoriert werden da er nur ein internes Verhalten der Library beschreibt.
Gleiche Parameter beim Aufruf unter Linux und Windows ergeben den gleichen Rückgabewert.

Funktion : IowKitSetWriteTimeout
Linux unterstützt beim Schreiben von Daten zum IOWarrior keinen einstellbaren Timeout.
Der write-timeout ist fest auf 5 Sekunden eingestellt (AFAIK entspreched HID-Spezifikation)

Die Funktion "IowKitSetWriteTimeout" gibt es wegen Plattformunabhängigkeit auch unter Linux,
sie bewirkt aber nichts.

Funktion : IowKitCancelIO
Liefert unter Linux immer FALSE, und hat keine Funktion

Funktion : IowKitWrite
Siehe IowKitSetWriteTimeout.
"To be completely compatible with the Windows version libiowkit.so
expects a ReportID 0 for pipe 0 (I/O pins) even if Linux does not
have a ReportID on pipe 0. The ReportID is stripped from the
data sent to the device."
kann ignoriert werden da er nur ein internes Verhalten der Library beschreibt.
Gleiche Parameter beim Aufruf unter Linux und Windows ergeben den gleichen Rückgabewert.

Mit Version1.5/2.0 der Library werden die Unterschiede wahrscheinlich geringer sein, aber an Punkt 1 wird sich wohl nichts ändern lassen.
Eberhard

[Robert Marquardt]

Unter Windows erfolgt der Zugriff shared, d.H. mehrere Prozesse können auf den IOWarrior
gleichzeitig lesend und schreiben zugreifen.

Windows hat halt ein fundamental unterschiedliches Konzept bei (HID-)Geraeten. Beim Lesen eines HID-Devices erhaelt jedes Programm eine Kopie der Daten. Bei Linux werden die Leseauftraege serialisiert und ein Programm schnappt dem anderen die Daten weg.

Es waere zwar durchaus moeglich einen exklusiven Zugriff auch unter Windows zu forcieren, aber dies verhindert dann das man mit einer Applikation nur IO-Pins und mit einer anderen nur einen Special Mode nutzt. Da dies eine recht realistische Anwendungsmoeglichkeit ist, wurde sie nicht beschnitten. Die Gefahr ist allerdings, das sich nun zwei Programme um einen IO-Warrior streiten koennen.
Es ist also Linux das hier in den Anwendungsmoeglichkeiten beschraenkt ist, dafuer aber Gefahren meidet.
Als Hinweis: das Konzept von Linux hinsichtlich der Behandlung von Geraeten ist allerdings wesentlich vernuenftiger als das von Windows.

Funktion : IowKitOpenDevice
Funktion : IowKitGetNumDevs

Das ist eine direkte Konsequenz der obengenannten Unterschiede in der Geraeteverwaltung.

Funktion : IowKitRead
Unterschiedliches Verhalten bzgl. eines gesetzen Timeouts.
Die Funktion IowKitSetTimeout setzt den Timeout für diese Funktion.
Unter Windows wird ein Wert >= 1000ms empfohlen.
Unter Linux ist ein timeout von 0 absolut zulässig. In diesem Fall
kehrt die Funktion sofort zurück, und hat falls vorhanden Daten gelesen oder eben nicht.
Dies gilt sowohl für Daten von den IO-Pins als auch von den SpecialModes.

Wieder ein Problem von Windows. Leider gibt es keine Moeglichkeit vorher zu pruefen ob denn Daten warten, um einen Leseauftrag erfuellen zu koennen. Damit koennte man eine Wartezeit von 0 implementieren und sich den ganzen Aufwand von internen Queues und Lesethread sparen.
Die >= 1000 ms muss man nicht zu ernst nehmen, aber Windows kann einem heftige Wartezeiten um die Ohren werfen bis es einen USB-Leseauftrag erfuellt. Man weiss also nie wie schnell bei einem Special Mode Write/Read-Paar die Antwort eintrifft. Zu kurze Timeouts koennten daher zu Fehlverhalten fuehren. Es hat alles im IO-Warrior funktioniert, aber Windows hat getroedelt beim Abholen der Daten.

Der Kommentar in der Doku :
"Linux does not have a ReportID byte of 0 for pipe 0 (I/O pins).
To be completely compatible with Windows libiowkit.so
adds that ReportID to the data."
kann ignoriert werden da er nur ein internes Verhalten der Library beschreibt.
Gleiche Parameter beim Aufruf unter Linux und Windows ergeben den gleichen Rückgabewert.

Der Kommentar soll ja auch nur fuer Linux-USB-Experten klarstellen das es eine ReportID 0 in den Daten gibt. Die ideologischen Scheuklappen sind bei den Programmierern beider Lager doch sehr ausgepraegt.

Funktion : IowKitSetWriteTimeout
Linux unterstützt beim Schreiben von Daten zum IOWarrior keinen einstellbaren Timeout.
Der write-timeout ist fest auf 5 Sekunden eingestellt (AFAIK entspreched HID-Spezifikation)

Die Funktion "IowKitSetWriteTimeout" gibt es wegen Plattformunabhängigkeit auch unter Linux,
sie bewirkt aber nichts.

Es kann unter Windows vorkommen das die Schreibfunktion stecken bleibt und nicht zurueckkehrt. Die gewaehlte Implementation mit Timeout kann sich davon erholen. Hier schlaegt zu das die Windows-Implementation alle USB-faehigen Windows-Versionen unterstuetzt. Die Interna in der Handhabung von IO sind aber gewaltig. das macht sich manchmal bemerkbar.

Schreibfehler sind ansonsten fast sicher von der Hardware verursacht.

Funktion : IowKitCancelIO
Liefert unter Linux immer FALSE, und hat keine Funktion

Das liegt daran das die Funktion unter Linux nicht gebraucht wird (Irrtum meinerseits vorbehalten).

Funktion : IowKitWrite
Siehe IowKitSetWriteTimeout.
"To be completely compatible with the Windows version libiowkit.so
expects a ReportID 0 for pipe 0 (I/O pins) even if Linux does not
have a ReportID on pipe 0. The ReportID is stripped from the
data sent to the device."
kann ignoriert werden da er nur ein internes Verhalten der Library beschreibt.
Gleiche Parameter beim Aufruf unter Linux und Windows ergeben den gleichen Rückgabewert.

Wie oben muss der Linux-Experte gewarnt werden das Windows-Konventionen gelten.

Mit Version1.5/2.0 der Library werden die Unterschiede wahrscheinlich geringer sein, aber an Punkt 1 wird sich wohl nichts ändern lassen.
Eberhard

Das Verhalten unter Windows laesst sich nun aus Kompatibilitaetsgruenden nicht mehr auf exklusiven Zugriff umaendern.
Die Unterschiede werden wohl bleiben.

[Mike D]

ich finde es gut, dass unter Win verschiedene Programme auf einen IOW zugreifen können. Und die Einschränkung unter Linux, dass überhaupt nur ein Prog z.Zt. IOWs nutzen kann, also bei 2 iows nicht mal die von verschiedenen genutzt werden kann finde ich herbe.

Mike

[Robert Marquardt]

Wir schreiben die Programme so gut wie wir es vermoegen.
Eine Verwaltungsschicht dafuer einzuschieben ist wohl moeglich, aber nicht leicht.

Ungluecklicherweise ist Linux gerade im Bereich der USB-Geraete noch nicht durchentwickelt und stabil in den APIs. Man muss also groessere Aenderungen erwarten.

[wayoda]

Und die Einschränkung unter Linux, dass überhaupt nur ein Prog z.Zt. IOWs nutzen kann, also bei 2 iows nicht mal die von verschiedenen genutzt werden kann finde ich herbe.
Mike

Tja, Ansichtssache.
Die Einschränkung das unter Windows ein anderes Programm Daten zu meinem IOwarrior schickt find ich herbe ;-)

Eberhard

[Robert Marquardt]

Ich finde er hat da schon recht. Der IO-Warrior sollte erst nach der Inbesitznahme durch das aufrufende Programm gesperrt sein.
Das Konzept kann aber erst mit dem 2.0 API greifen, da erst dort Inbesitznahme vorhanden ist. Nicht zu vergessen ist das das erst abgesegnet werden kann wenn ich es implementiert habe.
Das ist ein bischen trickreich, da ja das Freigeben eines Devices von einer Applikation ein (Pseudo-)Plug bei den anderen ausloest.
Ich sehe schon die Probleme wachsen, da dann die Applikationen in einer Daisy-Chain abgearbeitet werden. Der letzte kriegt die wenigsten Geraete zu sehen. Das kann eine ungerechte Strategie sein.
Damit sind die beiden natuerlich entstandenen Behandlungen des Problems vorlaeufig noch die besten.

[HappyAura]

ich muß sagen, ich finde es angenehm, dass verschiedene programme auf einen IOW zugreifen können. so kann man gut teillösungen basteln, die autonom laufen und muß sich nicht immer durch ein "riesenprogramm" kloppen. sprich für jeden special mode kann ich eine anwendung laufen lassen.

Gegen die möglichkeit, den IOW über einen befehl an ein programm zu binden, hab ich nix, aber bin dafür, dass es als zusätzliche option bleibt, wenn dafür jemand bedarf haben sollte.

[Robert Marquardt]

Mehrere Programme die mehrere Special Modes auf einem IO-Warrior nutzen wollen geht leicht schief.
Nur wenige Special Modes koennen gleichzeitig genutzt werden.

[HappyAura]

bis jetzt hatte ich keine probleme, aber vielen Dank für den Hinweis. sollte es zu unerklärlichen problemen kommen, weiß ich, in welche Richtung ich weiterforschen kann.

bei mir laufen zur Zeit gleichzeitig eine Abwandlung des IR Demoprogs, Winamp Plugin, StilCD und teilweise I2C Prog oder andere selbstgeschriebene. Probleme hab ich mit dieser Kombination noch nicht feststellen können.