IOW zu Atmega via i2c mit MacOSX

[ruediheimlicher]

Guten Tag
Ich verwende den I2C-Bus rsp. TWI für das Schreiben und Lesen von Atmega zu Atmega. Das funktioniert alles mit den Routinen von Peter Fleury, die anscheinend so etwas wie ein Standard für diese Aufgaben bei Atmega's sind, und läuft einwandfrei.
Auch das Lesen und Schreiben auf ein EEPROM 28C64 geht.
(http://www.jump.to/fleury)

Ich versuche nun, mit dem IOW über I2C auf den Atmega8 zuzugreifen.
Was funktioniert:
- Lesen und schreiben auf das EEPROM.
- Schreiben auf den Atmega-Slave mit den Reports:
02 81 60 ... Report ID 2, 1 Byte, I2C-Adresse 60
02 01 data0 ... Bytes einzeln, Ack
02 01 data1 ...
...
02 41 data7 ... fertig, Nak, alles da.

Mit dem Lesen komme ich nicht weiter.

Zum Lesen vom EEPROM verwende ich die Reports:
02 83 A0 xx yy ... Report ID, I2C-Adresse, Startadresse L und H
03 20 A1 .. .. Report ID, 32 Bytes(1 page), Chip-Adresse+read
Da purzeln die Bytes brav herein.

Der AVR gibt mit den Routinen von Fleury nur 8 Bytes aufs mal preis, also hat die Startadresse nur ein Byte. Ich schreibe:
02 82 60 00 .. Report ID 2, 2 Byte, Chip-Adresse, Startadresse 0
Der Chip wird adressiert und sagt, er schreibe ein Ack zurück. Der IOW gibt aber einen Fehler aus.

02 81 60 Report ID 2, nur 1 Byte, Chip-Adresse ergibt zwar keinen Fehler, Wenn ich dann aber analog zum EEPROM schreibe
03 08 61 ..
kommt ein Fehler zurück.

Weiterer Versuch nur mit dem Read-Report aus dem Datenblatt (gelesen!):
03 01 61 ... ID 3, 1 Byte, Adresse + READ:
Der Chip wird adressiert, lädt die richtigen Daten von [0] in TWDR, schickt ein Ack. Der IOW gibt einen R-Report mit ID 3 aus, ohne Fehler, aber auch ohne Daten.
03 08 61 ergibt 8 Bytes an Daten (erst 6, dann 2), aber alle leer.
Weitere Aufrufe an den Chip führen zu BusError oder gar nichts.
Bsp: 03 01 61 : -> 0x00, BusError

Kennt da jemand einen Ausweg?

Mit bestem Dank
Ruedi Heimlicher
OSX 10.5.3, Xcode 3.0

[Guido Körber]

Hilfreich wäre es natürlich mit einem Logicanalyzer mal auf die Bits schauen zu können.

Aber eine Vermutung ist, dass vielleicht beim Setzen der Leseadresse auch ein Stop am Ende erzeugt werden sollte. Einige IIC Schnittstellen haben sich da etwas komisch wenn man das nicht tut.

[ruediheimlicher]

Vielen Dank für die sonntägliche Antwort.
Der Versuch mit dem Stopbit bringt nichts. Wenn ich nachher in den Lesemodus wechsle, kommt ein Fehler.
02 C1 60 .. ergibt ein Ack
03 01 61 .. ergibt Err

02 81 60 ..
02 41 60 .. ergibt Ack im R-Modus
03 01 61 .. ergibt Err.

Direkt lesen läuft an sich:
03 01 61 .. lädt das Datenbyte 0 in TWDR
03 01 00 .. Byte 1 in TWDR
..
03 01 00 .. Byte 7 in TWDR, Nack
03 01 01 .. gibt den Bus wieder frei, warum, weiss ich nicht. Es kann auch oF oder FF sein.

Der Haken ist nur, dass die R-Reports zwar ankommen, aber sie sind alle leer, obwohl die Datenbytes nicht leer sind und der TWDR auch anzeigt, dass der Slave die Daten geschluckt hat.
Mit dem EEPROM kommen und gehen die Daten immer, auch das Schreiben auf den Atmega geht.
Ich kann die Lesekommunikation schon über die Ports machen, aber I2C wäre eher die elegante Lösung.
Ruedi

Gibt es da noch etwas auszuprobieren?

[Guido Körber]

Welcher IO-Warrior?

Und benutzt die Gegenstelle vielleicht Clock-Stretching?

[ruediheimlicher]

Es ist ein IOW24. Der Atmega8 macht meines Wissens kein Clock-Stretching. Die ISR tut nichts anderes als TWDR einen Wert zuweisen und ACK senden.
In meinem reinen Atmega8-Bus ist in der ISR beim Transmitter-Mode noch ein Aufruf des ADC enthalten. Das führte aber beim IOW zu einem Abbruch der Auslesereihe.

[Guido Körber]

Microcontroller verwenden häufig Clock-Stretching und meistens ist das in der Hardware eingebaut. Das würde nur mit dem IOW56 zusammen funktionieren.

[towaibw]

Falls I2C nicht funktionieren sollte, wie wäre es dann mit SPI für die µP-Kommunikation?

[ruediheimlicher]

Ich bin jetzt ein Bitzli weiter gekommen. Nachdem ich sämtliche LCD-Ausgaben auf dem Slave auskommentiert habe, funktioniert der Aufruf mit
03 08 61 ...
anscheinend korrekt, der Bus wird nach dem Empfang von 8 Bytes wieder freigegeben. Nur haben die 'empfangenen' Daten nichts mit den Eingaben im Slave zu tun. Das erste und zweite Byte gibt irgend etwas, die andern sind FF.
Anscheinend hat es doch etwas mit der Clock zu tun. Aber warum der Garbage in den Reports?

Ich werde mich jetzt mal mit dem SPI befassen.

[towaibw]

Ich werde mich jetzt mal mit dem SPI befassen.

Da ich der Anstifter bin ;-) noch ein Hinweis: Wenn du möchtest, kannst du mal bei IOWJ (Reklame!) (http://iow.wagner-ibw.de/doc/0_9_5rc1/index.html) nachsehen. Da habe ich mal nach einem Kundenwunsch eine Klasse de.wagner_ibw.iow.spi.GenericSPIDevice genau für diesen Zweck erstellt. Soll auch mit einem Mega8 funktioniert haben (habe das selber nicht ausprobiert und besitze auch keine Kenntnis von der Software auf dem AVR. Vielleicht könnte ich da aber einen Kontakt herstellen). Zum Schluß noch die Bemerkung, das ich I2C und SPI javamäßig wegen der unterliegenden Lib nicht auf dem Mac zum Laufen gebracht habe.