Eingehender Report mit RepID=0x00 unter Suse Linux

[_Michael_]

Hallo zusammen!

Ich besitzte einen IOWarrior56 (StarterKit) und bräuchte mal eure Hilfe. Ich bin gerade dabei unter Linux und Java eine Steuerung mit dem IOW56 zu programmieren. Dabei habe ich ein Display (2x16, HD44780 kompatibel), einen Temperaturfühler(DS1631) und einen Analag-Digitalkonverter(PCF8591) am IOW56 angeschlossen.

Zuerst habe ich die Funktionalität für das Display implementiert. Läuft alles wunderbar. Auch das Testprogramm IOBlink funktioniert einwandfrei.

Dann habe ich mich mit der I2C-Funktionalität befasst. Dabei habe ich ein kleines Problem unter Linux, wenn ich versuche den DS1631 oder den PCF8591 anzusprechen:

(Alle Reports sind 64 Bytes lang, Pipe:1)
1) Ich sende einen Report zum Aktivieren der I2C SpecialModeFunction
Report(OUT): 01 01 00 .......
2) Dann folgt ein Report mit Start/Stop und der Anzahl der zu sendenden Bytes, der Adresse und dem Befehl für den DS1631
Report(OUT): 02 c2 94 ac .......
3) Jetzt sollte der Schreibbefehl auf dem I2C-Bus ja eigentlich mit einem Report mit RepID=2 bestätigt werden, also lese ich diesen auch. Was ich aber erhalte ist folgendes:
Report(IN): 00 00 00 00 00 00 00 .......

Deswegen erhalte ich bei späteren Schreib und Lesebefehlen immer einen falschen Report zurück.

Ich habe versucht, das unter Windows zu rekonstruieren, dort läuft jedoch alles wie erwartet: Ich erhalte den Bestätigungsreport für den Schreibbefehl. Auch mit dem SimpleHIDWrite-Programm funtioniert alles wie erwartet.

Um das ganze mal unabhängig von meinem Programm zu machen, habe ich den oben genannten Ablauf mal in ein extra Programm gepackt (Also nur die Write und Read Befehle). Dort tritt das selbe Phänomen auf.

Ich hoffe, ihr könnt mir weiterhelfen, da das System später unter Linux eingesetzt werden soll.

Anbei noch ein paar Daten:
Verwendetes System: Laptop ASUS M3N, OpenSuse 11.0

Viele Grüße und schonmal vielen Dank für eure Hilfe!
Michael Schmidt

[Christoph Jung]

Wurde das ganze auch mal unter einer anderen Distribution getestet, bzw. unter Suse 10.X ?

[_Michael_]

Wurde das ganze auch mal unter einer anderen Distribution getestet, bzw. unter Suse 10.X ?

Nein, das wäre jetzt mein nächster Schritt gewesen. Ich wollte nur mal erst hier im Forum nachfragen, ob das Problem schon mal generell unter Linux aufgetreten ist.

Hat schon jemand hier aus dem Forum Erfahrungen mit (K)Ubuntu/IOW gemacht?

Viele Grüße,
Michael

[Guido Körber]

Welche ReportID hat denn der Report der da ankommt? Ist das ein Report $02 oder was anderes?

[_Michael_]

Welche ReportID hat denn der Report der da ankommt? Ist das ein Report $02 oder was anderes?

Die ReportID ist $00 (das meinte ich mit 0x00), das ist ja das merkwürdige an der Sache. Und nicht der erwartete Report mit ReportID $02. So weit ich aus dem Datenblatt vom IOW56 entnehmen kann, gibt es diese ReportID überhaupt nicht, oder sehe ich das falsch?!

Viele Grüße,
Michael Schmidt

[Guido Körber]

$00 ist noch nicht mal eine gültige ReportID, der USB Treiber dürfte sowas eigentlich garnicht abliefern. Beim Rücklesen von Ergebnissen sollten Sie auf jeden Fall auf die richtige ReportID testen, sonst kommen Sie eh durcheinander.

[friend-of-rq]

$00 ist noch nicht mal eine gültige ReportID, der USB Treiber dürfte sowas eigentlich garnicht abliefern.

doch ... wenn man mit (IowKitReadNonBlocking) arbeitet !

ich bin mir aber nicht sicher ob es die function (ReadNonBlocking) unter linux gibt.

und wenn nicht so oft einlesen ($00 ignorieren) bis der erwartete Wert $02 kommt.

[Guido Körber]

Nein, das ist falsch. ReportID = 0 ist laut USB Spec unzulässig.

ReadNonBlocking ist eine API Funktion und benutzt das erste Interface, auf dem es keine ReportID gibt.

[_Michael_]

Hallo zusammen,

vielen Dank schon Mal für die ganzen Anregungen :-).

doch ... wenn man mit (IowKitReadNonBlocking) arbeitet !

Ich entwickle die Software unter Linux mit der Entwicklungsumgebung Eclipse und Java. Ich verwende für die Lesebefehle jeweils nur IowKit.read() und nicht IowKit.readNonBlocking().

ReadNonBlocking ist eine API Funktion und benutzt das erste Interface, auf dem es keine ReportID gibt.

Ich verwende diese Funktion zwar nicht, aber in der Java-API für den IOWarrior ist die Funktion IowKit.readNonBlocking() doch folgendermaßen definiert (dort steht außerdem noch folgendes: The Special Mode pipe has a report size of 8 bytes for all IO-Warriors. Was mich am Anfang doch etwas verwirrte, da ja doch laut Datenblatt der Report 64 Bytes lang sein sollte. ;-). Bei Gelegenheit könnten Sie das noch in der Dokumentation der Java-API korrigieren.)

static int[] readNonBlocking(long devHandle, long numPipe, long length).

Bedeutet ihre Aussage nun, dass wenn ich diese Funktion für die SpecialModePipe verwende ich einen Report ohne ReportID bekomme?

Also ich gehe auch davon aus, dass irgendetwas nicht mit dem USB-Treiber stimmt. Unter Windows läuft ja alles wie erwartet. Daher werde ich am Wochenende mal (K)ubuntu auf meinem Laptop installieren und das Ganze dann noch mal testen. Als Übergangslösung verwerfe ich momentan bereits alle Reports, die mit einer ungültigen ReportID eingehen, so wie es friend-of-rq und Herr Körber auch vorgeschlagen haben.

Viele Grüße,
Michael Schmidt

[Guido Körber]

Nein, bei Zugriffen auf das zweite Interface ist immer eine ReportID dabei. Die Lösung Ihres Problems würde darin liegen die ReportID auszuwerten statt einfach zu nehmen was kommt.

[_Michael_]

Hallo zusammen,

also ich habe gerade mal auf einem aktuellen Kubuntu installiert und dort tritt das selbe Phänomen auf. Daher werde ich die ReportID jetzt immer auswerten, was ja auf jeden Fall sinnvoll ist. Ich finde es nur sonderlich, dass sich der IOWarrior unter Windows anders verhält als unter Linux und Reporte mit ReportID $00 eingehen können, obwohl dies so nicht im Datenblatt (und auch in den USB-Spezifikationen) spezifiziert ist. Es scheint ja auch kein Problem des IOWarriors selber zu sein, sondern des USB-Treibers oder der Java-API!? Oder auch nur im Zusammenhang mit meinem Laptop und Linux, wer weiß!?

Trotz allem vielen Dank für eure schnelle und freundliche Unterstützung!! :-)

Viele Grüße,
Michael Schmidt

[Guido Körber]

Die USB Implementierung auf Linux ist leider nicht die beste...

Windows hat mehr Stabilitätsprobleme mit USB als Linux, dafür ist Linux teilweise sehr unsauber im Umgang mit Devices und Klassen.