IOWJ Tutorial

Um die angeschlossenen IO-Warriors nutzbar zu machen, müssen diese erkannt und initialisiert (geöffnet) werden. Das geschieht beim Programmstart und wird durch die Klasse IowFactory erledigt.

IowFactory devs = IowFactory.getInstance();

Es ist sinnvoll, diese Anweisung mit einem try/catch Block zu umgeben und die Exceptions UnsatisfiedLinkError und NoClassDefFoundError abzufangen. Erstere deutet darauf hin, dass die zugrunde liegende iowkit Bibliothek nicht gefunden werden konnte und letztere, dass das Archiv codemercs.jar nicht gefunden wurde. Folgendes Codefragment müsste für die meisten Fälle ausreichend sein:

try {
    IowFactory devs = IowFactory.getInstance();
    System.out.println("------- Version of iowkit library is '" + devs.getVersion() + "' --------");
    if (devs.getNumDevices() == 0) {
        System.out.println("Cannot find any plugged IO-Warrior device!");
        devs.exit(-1);
    } 
    System.out.println(devs.toString());
    devs.exit(0);
}
catch(UnsatisfiedLinkError e) {
    System.out.println(e);
    System.exit(-1);	
}
catch(NoClassDefFoundError e) {
    System.out.println("Cannot find java archive 'codemercs.jar'!");
    System.exit(-1);	
}

Nach Programmstart an- oder abgestöpselte IO-Warriors werden nicht mehr berücksichtigt.

Wenn es Sinn macht, kann man natürlich nicht mehr benötigte IO-Warriors jeweils einzeln mit der Methode close() des IO-Warrior Objektes AbstractIowDevice, Iow24, Iow40 oder Iow56 schließen. Besser ist es, die Methode exit(return code) des IowFactory Objektes aufzurufen. Diese schließt alle angeschlossenen IO-Warriors.

Warum ist das schließen der Warriors so wichtig? Zum einen ist es guter Programmierstil, vom Betriebssystem angeforderte Resourcen bei Nichtverwendung wieder frei zu geben. Zum anderen wird für jeden IO-Warrior mindestens ein Thread gestartet, welcher die Verteilung der Antwort-Reports der Special Mode Functions organisisert. Wird der "autonomous" Mode aktiviert, kommt ein weiterer Thread hinzu. Diese Threads müssen vor Programmende beendet werden, damit auch das Programm sich selber sauber beenden kann.

Der erste Fall ist vielleicht für die meisten Anwender der am häufigsten zutreffende Fall.

AbstractIowDevice dev = devs.getIowDevice();

Durch diese Anweisung erhält man das gewünschte IO-Warrior Objekt. Es gibt auch noch die Methode gleichen Names, zusätzlich jedoch mit dem Parameter Seriennumer als String (Achtung, auch führende Nullen sind mit anzugeben).

AbstractIowDevice dev = devs.getIowDevice("00002632");

Mögliche Exception beider Methoden ist eine NoSuchElementException, welche anzeigt, dass bei der ersten Version der Methode gar kein IO-Warrior und bei der zweiten Version kein IO-Warrior mit der gewünschten Seriennummer angeschlossen ist.

Im zweiten Fall kommen die Methoden

Iow24 dev24 = devs.getIow24Device();

Iow40 dev40 = devs.getIow40Device();

Iow56 dev56 = devs.getIow56Device();

und ihre Version mit der Seriennummer (auch für diesen Fall eher ungebräuchlich, solange je Typ nur ein IO-Warrior angeschlossen ist)

Iow24 dev24 = devs.getIow24Device("00000153");

Iow40 dev40 = devs.getIow40Device("00002632");

Iow56 dev56 = devs.getIow56Device("0000011D");

zum Einsatz. Mögliche Exception dieser Methoden ist eine NoSuchElementException, welche anzeigt, dass bei den Versionen der Methode ohne Seriennummernangabe gar kein IO-Warrior und bei den Versionen mit Seriennummernangabe kein IO-Warrior mit der gewünschten Seriennummer angeschlossen ist.

Im dritten und letzten Fall ist das Arbeiten mit der Seriennummer unumgänglich.

Iow24 dev1 = devs.getIow24Device("00000153");

Iow24 dev2 = devs.getIow24Device("00000375");

Diese Methoden werfen die Exception NoSuchElementException, falls kein IO-Warrior des gewünschten Types oder der gewünschten Seriennummer angeschlossen ist.

Die verschiedenen Typen der IO-Warrior Serie haben eine unterschiedliche Anzahl von Ein-/Ausgabe Beinchen (Pins), welche in Gruppen von 8 in sogenannten Ports organisiert sind. Der IO-Warrior 24 hat 2 Ports (P0 und P1) mit insgesamt 16 Pins, der IO-Warrior 40 hat 4 Ports (P0 bis P3) und somit 32 Pins und der IO-Warrior 56 hat 7 Ports (P0 bis P6) mit 50 Pins. Hier hat uns die Arithmetik keinen Streich gespielt. Im siebenten Port (P6) ist nur Pin0 und Pin7 verfügbar.

Diese Ports können nur zusammen, also in einem Rutsch beschrieben oder gelesen werden. Beim Lesen kommt noch erschwerend hinzu, das nur Daten generiert werden, wenn sich der Zustand an den Pins geändert hat. Von Natur aus haben diese Pins keine Richtung. Das heist, sie können gleichzeitig zur Eingabe und Ausgabe benutzt werden. Eine Eingabe ist jedoch nur möglich, wenn vorher an das Pin eine logische 1 ausgegeben wurde (man kann sich das wie ein logischens UND zwischen Ein- und Ausgang vorstellen: ist der Ausgang 0, kann am Pin-Eingangs passieren was will, es wird immer eine 0 ausgelesen).

Das bedeutet auch, das man sich durch fehlerhafte Ausgaben die Eingänge "abklemmen", d.h. nicht mehr die wirklichen Zustände einlesen kann. Um das zu verhindern, hat IOWJ den Begriff der "Richtung" wieder eingeführt und besitzt somit die Möglichkeit, Fehlausgaben von sich aus zu verhindern.

Das setzen von Pins erfolgt mit: * setPort(portnummer,wert) * setBit(portnummer,bitnummer) * clearBit(portnummer,bitnummer) und anschließendem Aufruf von writeIOPorts(), um die Daten "zum Chip zu schicken".