Grundlagen zum IOW40

[methusalem]

Hallo zusammen,

ich hab hier einen IOW40 schon seid einiger Zeit liegen und mit einem Programm eines Freundes in benutzung.

Nun möchte ich gerne ein eigenes Programm in C++ mit den QT Bibliotheken schreiben (Linux und Windows). Das Modul wird schon von meinem Programm erkannt. Leider bin ich die letzten Wochen kaum dazu gekommen weiter zu programmieren. Und nun fällt mir der Einstieg wieder etwas schwer :-)

Wie ist der IOW organisiert. Muss ich in meinem Programm regelmäßig die Ports abfragen? Oder gibt es ein Möglichkeit das die Module sowas wie einen Interrupt auslösen, wenn sich was geändert hat. Muss ich also selber in einem Thread die Ports überwachen, oder macht mich das Modul auf Änderungen aufmerksam. Das zweite wäre schön. Ich denke aber, das ich es nach Variante 1 machen muss.

[Robert Marquardt]

Also ich weiss ja nicht warum wir eigentlich Dokumentation schreiben.
Das IOWKIT 1.4 API fuer windows und Linux hat noch keine Callbacks. Man muss mit einem Thread oder Timer arbeiten.
Das 2.0 API befindet sich gerade im Betatest. Es ist bisher nur fuer Windows implementiert. Es enthaelt eigene Threads und implementiert damit Callbacks.

[methusalem]

Also ich weiss ja nicht warum wir eigentlich Dokumentation schreiben.
Das IOWKIT 1.4 API fuer windows und Linux hat noch keine Callbacks. Man muss mit einem Thread oder Timer arbeiten.
Das 2.0 API befindet sich gerade im Betatest. Es ist bisher nur fuer Windows implementiert. Es enthaelt eigene Threads und implementiert damit Callbacks.

Ich weiß es schon. Leider hat mich das hin und her zwischen der Version 1.4 und 2.0 hier im Forum etwas verwirrt. Man möge mir verzeihen.

Wie sieht denn die "Roadmap" für die Version 2.0 aus? Dauert das noch was, bis die auf Win und Linux verfügbar ist, oder seid Ihr vor der Fertigstellung?

Tritzdem vielen Dank für den kurzen Hinweis.

[Guido Körber]

Zielvorstellung für 2.0 ist etwa März.

[Robert Marquardt]

Fuer Windows roll ich das 2.0 API wohl noch im Februar raus.
Ich muss noch ein paar Kleinigkeiten abfeilen und Dokumentation und Beispiele schreiben.
Der Java-Teil sollte nicht zu schwierig sein. Da muss nur geklaert werden wie man die Callbacks behandelt.

Bei Linux ist die schwierigste Frage wie das mit den APIs und den Daemonen ist.
Es aendert sich immer noch das eine oder andere Subsystem und es ist daher nicht so klar was bei welcher Distribution vorhanden ist oder nicht.
Auf jeden Fall wird nur Linux 2.6 unterstuetzt werden.

[towaibw]

Also ich brauche für Java keine 2.0 mit Threads, die habe ich selber in Sack und Tüten ;-). Ich würde mir eine 1.5 wünschen, mit der man mitbekommen kann, wann ein warrior hinzukommt oder verschwindet (das muß nicht unbedingt einmal per callback sein: wenn ein write fehlschlägt kann ich ja nachsehen, ob es den warrior noch gibt oder nicht). Das wäre nur einen Erweiterung und wir müßten uns auch um Linux keine Sorgen machen.

Wie sieht es denn eigentlich mit der iowkit lib 1.4 (1.5) für MacOs aus? Dann wäre ich mit der "Java-Abdeckung" zufrieden ;-)

[Guido Körber]

MacOS X wird dann die V2.0 bekommen, dann müssen wir nicht zwei mal ran. Eigentlich ist MacOS unser "Heimatbetriebssystem", aber da nicht so viele Leute wissen was gut ist oder es schlicht nicht nutzen dürfen, müssen wir den Aufwand dem Nutzen anpassen. Dazu kommt dann noch, dass wir für die x86 Macs ja ohnehin dann an den Code ran müssen.

[Robert Marquardt]

Das mit An- und Abstecken fuer ein 1.5 API ist nicht so gut. Um das zu dedektieren muss man ein Fenster unterhalten was die DLL abhaengig von der Messageverarbeitung macht. Reine Kosolenprogramme sind nicht mehr moeglich.
Ich werde mich mal mit einem privaten messageverarbeitenden Thread versuchen.

[wayoda]

Also ich brauche für Java keine 2.0 mit Threads, die habe ich selber in Sack und Tüten ;-).

Der Vorteil an der 2.0-lib mit Threads ist, dass man nun die freie Wahl hat ob man einen Callback für Daten implementiert, oder eine Polling-Strategie verwendet. Die neu hinzugekommene Funktion für ein nicht-blockierendes Lesen auch der Special-Mode Reports vereinfacht die Anwendungsprogrammierung doch erheblich.

Ich würde mir eine 1.5 wünschen, mit der man mitbekommen kann, wann ein warrior hinzukommt oder verschwindet (das muß nicht unbedingt einmal per callback sein: wenn ein write fehlschlägt kann ich ja nachsehen, ob es den warrior noch gibt oder nicht).

Das Verschwinden eines IOWarrior ist sicher kein Problem (man hatte mal ein Handle, dass nun nicht mehr funktioniert).
Um einen hinzugekommenen IOWarrior bei der Applikation anzumelden, fällt mir aber außer einem Callback auch nichts ein.
Aber dieser Callback für Geräte-Änderungen ist ja der einzige den man wirklich implementieren muß.

Eberhard

[Robert Marquardt]

Das bedeutet also das Java unter Windows Messages pumpt. Dann kann ich mir den Thread dafuer sparen.
Ich glaube nicht das reine Konsolenprogramme auf Windows-PCs von Bedeutung sind.

Ach ja, ab morgen sitze ich wieder am Arbeitsplatz.

[wayoda]

Das bedeutet also das Java unter Windows Messages pumpt. Dann kann ich mir den Thread dafuer sparen..

Ich weiß zwar nicht worauf sich dieser Satz innerhalb des Topics bezieht, aber damit keine Mißverständnisse aufkommen:

Die Java Virtual Machine implementiert eine eigene Eventqeue für GUI-Events. Da landen natürlich auch irgendwie die Messages des jeweiligen graphischen Toolkits (windows,x-server, was auch immer das unter MacOS bewirkt) drin, aber es ist nicht die selbe Eventqueue.

Ich glaube nicht das reine Konsolenprogramme auf Windows-PCs von Bedeutung sind.

Ich benutze Windows zwar nicht, wundere mich aber trotzdem, dass hier keine Widerspruch erfolgt !??!
Also mir fallen da doch spontan Messwertprotokollierung , CGI's und IOWarriorsÜbersNetzwerk ein...

Eberhard

[Robert Marquardt]

Die Java Virtual Machine implementiert eine eigene Eventqeue für GUI-Events. Da landen natürlich auch irgendwie die Messages des jeweiligen graphischen Toolkits (windows,x-server, was auch immer das unter MacOS bewirkt) drin, aber es ist nicht die selbe Eventqueue.

Die DLL erstellt ein internes Fenster. Damit das Fenster Messages bekommt, muss irgendwo im Hauptprogramm eine Messagequeue bedient werden (aka Messagepumpe). Offensichtlich macht das fuer Java-Programme die VM.
Fuer reine Konsolenprogramme beispielsweise in C ist das ja nicht der Fall.

Ich benutze Windows zwar nicht, wundere mich aber trotzdem, dass hier keine Widerspruch erfolgt !??!
Also mir fallen da doch spontan Messwertprotokollierung , CGI's und IOWarriorsÜbersNetzwerk ein...

Eberhard

Dazu sage ich diese Programme auch mit dem 1.4 API zurechtkommen koennen.
Ich will es eben vermeiden das 2.0 API mit einem Thread fuer die Messagepumpe aufruesten zu muessen.

[towaibw]

Der Diskussion kann ich jetzt nicht mehr so richtig folgen ;-(.
Eine iowkit library soll für mich den Zugriff auf die IO-Warrior Funktionalitäten ermöglichen. Ob Konsolen oder GUI-Appliokation sollte an dieser Stelle egal sein, wie auch die sie nutzende Hochsprache und das Betriebssystem. Konsolenanwendungen, oder besser gesagt , Anwendungen ohne GUI Komponennten, sind durchaus sinnvoll (siehe IowBatch).

Wird das API der dll nur geändert, weil VB mit Threads nicht zurechtkommt?

Was soll diese Messagepumpe sein?

Auch wenn es vielleicht langsam lästig wird: ich habe ein Modell für die IO-Warrior's gefunden, in der ich beliebige (natürlich nur wenn der Warrior das auch zuläßt) Special Mode Functions zu selben Zeit kombinieren kann (und auch zur Laufzeit ändern könnte, wenn das Sinn machen würde (ich kenne nämlich keine Methode, in der man die Warrior-Beschaltung zu Laufzeit ändern kann)). Die I2C Functione habe ich auch soweit, das mehrer I2C-Chips zur selben Zeit in einer Applikation angesprochen werden können. Man muß es nur einfach benutzten und kann sich auf die wesentlichen Dinge konzentrieren, nämlich die eigentliche Applikation (ob mit oder ohne Fenster ist dabei vollkommen egal) zu entwickeln.

Vielleicht sollten wir einen eigenen Thread über die Vorteile eines 2.0 API's eröffnen, falls eine Diskussion seitens Codemercs überhaupt gewünscht ist. Mir fehlt nur eine Funktion im API, über die ich erfragen kann, welche Warriors angeschlossen sind, ohne alle zu schließen (ist für einen laufende Anwendung nicht wirklich akzeptabel ;-) und jedesmal ein openAllDevices() ausführen zu müssen. Ein Callback muß es nicht sein, auf einen Thread mehr oder weniger kommt es mir nicht an.

[Guido Körber]

Vorschläge hören wir gerne. Es ist aber so, dass wir auch Dinge mit berücksichtigen müssen die Produkte betreffen über die wir noch keine näheren Angaben machen können.

[Robert Marquardt]

Ich mache mal einen Thread dazu auf. Schlimmstenfalls muessen wir halt "kein Kommentar" sagen.
Das entlastet auch "methusalem", da dieser Thread nun schon sehr OT ist.