Hallo,
ich kapiere nicht so ganz, wie man mehr als 6 Bytes via I2C-Bus lesen soll. Bzw. warum es nicht klappt.
Ich versuche es mit
data[0]=0x03; // report id
data[1]=16; // count
data[2]=0x23; // read address
data[3]=0x00;
data[4]=0x00;
data[5]=0x00;
data[6]=0x00;
data[7]=0x00;
err=IOWarriorWriteToInterface(myIOW1, 8, data);
um z.B. 16 Bytes zu lesen. Bewirkt dieses initiierende Write bereits das komplette Lesen vom angeschlossenen Baustein (übrigens ein SAA5246), oder erst die folgenden Reads?
Anschließend versuche ich die Werte mit wiederholten
err=IOWarriorReadFromInterface(myIOW1, 0x03, 8, data);
zu bekommen. Ich erhalte aber jedesmal dasselbe array, und vorne steht 0x03, 0x04 ... drin. Also erst die ID und dann count=4, anschließend vier gültige Werte. Die Zahl vier ergibt sich offenbar (sieht man durch Variieren der Anzahl) aus 16 mod 6, es sieht also fast so aus, als ob ich nur die übrigbleibenden vier Werte bekomme und zwei "volle" Reports zu je sechs Bytes irgendwie verpasse.
Wie geht es richtig?
Guido
Mehr als 6 Bytes via I2C-Bus lesen
Moderator: Guido Körber
-
- Site Admin
- Posts: 2857
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Das ist jetzt MacOS X wenn ich den Funktionsnamen richtig zuordne?
Der Antwortreport ist der letzte der zurückkommt, die anderen sind vorbeigerauscht.
Das Problem ist, dass der Write-Befehl erst zurückkehrt, wenn der IO-Warrior ein ACK geschickt hat. Das tut er aber erst wenn alle Antwortreports gesendet sind, bzw. der letzte in den Buffer des USB Interface geladen ist.
Wenn es also schneller gehen soll ist es notwendig einen zweiten Thread zu erzeugen, der die Lesefunktion macht. Mit einem Thread können nur Befehle erfolgreich abgeschickt werden, die nur einen einzelnen Antwortreport bekommen.
Der Antwortreport ist der letzte der zurückkommt, die anderen sind vorbeigerauscht.
Das Problem ist, dass der Write-Befehl erst zurückkehrt, wenn der IO-Warrior ein ACK geschickt hat. Das tut er aber erst wenn alle Antwortreports gesendet sind, bzw. der letzte in den Buffer des USB Interface geladen ist.
Wenn es also schneller gehen soll ist es notwendig einen zweiten Thread zu erzeugen, der die Lesefunktion macht. Mit einem Thread können nur Befehle erfolgreich abgeschickt werden, die nur einen einzelnen Antwortreport bekommen.
-
- Posts: 13
- Joined: Sun Sep 26, 2004 7:57 pm
Ja, sorry, ich vergaß...Guido Körber wrote:Das ist jetzt MacOS X wenn ich den Funktionsnamen richtig zuordne?
Was meinst Du hier mit Thread - sowas via IOWarriorSetInterruptCallback?Wenn es also schneller gehen soll ist es notwendig einen zweiten Thread zu erzeugen, der die Lesefunktion macht. Mit einem Thread können nur Befehle erfolgreich abgeschickt werden, die nur einen einzelnen Antwortreport bekommen.
Guido