IOWarrior mit Java unter MacOsX

[tybalt]

Hallo,

ich habe seit kurzen ein Mac und möchte gerne den IOWarrior ansprechen.
Ich möchte das gerne mit Java machen und habe gelesen, dass es Java Support gibt.

Jedoch funktioniert es nicht!

Ich bekomme eine Meldung, dass eine iowkit.dll gebraucht wird.

(Habe die Wagner Api.)

Kann mir da jemand helfen.

Gruß

[Guido Körber]

Nein, da kann bisher keiner helfen weil die Java Unterstützung nur mit Windows und Linux läuft.

[towaibw]

Ich habe mir vor ca. 14 Tagen einen Mac zugelegt, um mich auch dieser Herausforderung zu "nähern" (O.K. nicht nur dafür ;-). Auf Basis der Bibliothek aus dem SDK für Mac OS habe ich eine libiowkit.jnilib erstellt, die den entsprechenden JNI-Wrapper plus Library enthält. Gegenüber der Windows/Linux Variante gibt es zwar Einschränkungen, diese dürften aber nicht so in's Gewicht fallen. Beim ersten Hack funktionieren schon mal ListDevices.java (mit gefakter Revision) und das Blinken der LED's der IOW24 und IOW40 Boards (also schreiben auf pipe 0). Diese Woche ist noch das Lesen der pipe 0 an der Reihe.

Wenn es Interessenten für diese Arbeit gibt, dann meldet euch doch mal. Das würde das ganze sicher etwas beschleunigen :-). Auch für Nicht-Java-Freunde könnte das interessant sein, weil hier eine teilweise Umsetzung auf das IowKIT API (1.4) entsteht.

[Guido Körber]

Wow, das hört sich gut an.

Welcher Art sind denn die Probleme mit dem Mac API? Wir müssen sowieso eine Überarbeitung machen, ggf. könnte man da gleich was berücksichtigen.

[towaibw]

Von Problemen mit dem Mac API würde ich da nicht sprechen. Ich benutze erst einmal nur

IOWarriorInit()
IOWarriorCount()
IOWarriorInterfaceListNodeAtIndex()
IOWarriorWriteToInterface()
IOWarriorReadFromInterface()

Vermissen tue ich nur die Revision, da ich die intern auswerte und entsprechend qualifizierte Fehlermeldungen ausgebe, falls einer eine Special Mode Function benutzten möchte, die es in der vorhandene Revision noch nicht gab (diese Feature ist aber nicht weltmeisterschafts entscheidend ;-).

Mein Vorschlag wäre da, IOWarriorListNodeStruct um ein Feld 'revision' zu erweitern. Hab auch schon nach einem entsprechenden Property gesuch und auch eines mit der Konstanten 'kIOHIDVersionNumberKey' gefunden. Vermute aber, dass das eher mit der HID statt der Device Version zu tun hat.

Fortschrittsbericht:
Schreiben auf pipe 1 funktioniert nun auch. Habe schon mal meine LC-Displays gequält. Mir ist nur aufgefallen, dass das alles recht langsam über die Bühne geht. Kein Vergleich mit Windows :-((. Aber als erster Versuch nicht übel.

Für die Statistiker:
Ich verwende MacOS X 10.4.6 auf einem G4 Mac Mini.
Xcode 2.0 (erzeugt erst einmal nur G4 Binaries) für die Lib.
Eclipse 3.2.0 (da ich mit Xcode und Java noch nicht richtig umgehen kann und ich mich doch schon sehr an Eclipse gewöhnt habe) für das Java-Zeugs.

[Guido Körber]

Das mit der Geschwindigkeit ist komisch, die PowerMacs haben alle OHCI Host Controller, sollten also mit bis zu 3kHz Schreiboperationen erlauben.

[towaibw]

Das mit der Geschwindigkeit war ein "Verklemmer" im System, der wahrscheinlich durch meine Experimente ausgelöst wurde. Seit einem Neustart läuft es wieder ordentlich fix..

Nun habe ich die Herausforderung, ein "ordentliches" Read() hinzubekommen, da IOWarriorReadFromInterface() ja mehr wie ReadImmediate() funktioniert und nicht blockiert. Ich brauche ein blockierendes Read()! (Hätte nie gedacht, so etwas mal schreiben zu müssen, da ja ein Callback wesentlich eleganter ist). Aber auch in Hinsicht zu einer Kompatibilität zum IowKit API wäre so eine Funktion nützlich.

Haben da die Mac-Experten von CodeMercs eine Idee und bekommen das "auf die Schnelle" hin? CFRunLoop habe ich mir schon angesehen und IOHIDInterface kann auch irgendwie mit eine Queue umgehen. Aber ich muß zugeben, dass ich das ganze noch nicht so richtig gerafft habe (der Apple Beispielcode war da auch nicht so die große Hilfe für mich).

[towaibw]

Das mit dem CallBack geht bei mir voll in die Hose (wegen dem unerwarteten Verhalten). Er wird zykilsch aufgerufen, egal ob sich an den Pins etwas geändert hat oder nicht. Ich vermute mal, dass ich die Reports untereinander vergleichen muß, um herauszufinden, ob sich an den Pins etwas geändert hat.

Ich habe das jetzt so gelöst: Ich lese mit IOWarriorReadFromInterface() in einer Schleife so lange, bis sich der Report vom vorhergehenden unterscheidet und kehre dann zurück (also das gewünschte blockierende Verhalten). Da brauche ich kein CallBack und auch keine CFRunLoop . Überraschenderweise verursacht das nur (!?) um die 3% CPU Last.

[towaibw]

Ich bin auf das nächste Problem gestoßen: eine Funktion, die jeden beliebigen Report auf pipe 1 entgegen nimmt, schein es im MAC-API nicht zu geben. IOHIDDEVICEInterface->getReport() möchte eine reportID übergeben haben. Ein solcher Parameter ist im iowKit-API nicht vorgesehen und würde eine Änderung des API's und com.codemercs.iow.IowKit.java erfordern. Außerdem würde diese Logik eine Änderung auch meiner Java Klassen nach sich ziehen. Deshalb höre ich hier jetzt erst einmal auf.

Was nach ersten Test funktionieren müßte (IOWJ 0.9.4):
* Pin- Ein- und Ausgabe (auch mit Listener)
* Special Mode Functions: nur solche, die nicht lesen (bleibt nur LCD übrig), das Lesen der pipe 1 nicht funktioniert.