I2C/TWI zwischen ATmega und Raspberry Pi

[Frank (Gast)]

Liebe Experten,
ich versuche, einen ATmega8 auf Breedboard mit einem Raspberry Pi per 
I2C/TWI zu verbinden. Auf dem ATmega läuft ein kleines 
Assemblerprogramm, das LED anschalten soll. Auf dem Pi läuft ein 
Java-Programm mit Pi4J als Zugriffsbibliothek. Ziwcshne den beiden hockt 
der I2C-fähige 3,3-auf-5V-Pegelwandler für die SDA/SCL-Leitungen von 
Adafruit.

Fernziel ist, den µC als Sensor einzusetzen und die Auswertelogik für 
seine Daten in Java auf dem Pi abzuwickeln. In dieser Teststellung 
dienen die LED erstmal nur zur Anzeige des Innenlebens im ATmega.

Die Listings des Java und des Assembler-Programms habe ich angehängt.

Sobald ich auf die Zeile "device.write(b);" im Java debugge und diese 
ausführe passiert folgendes:
a) Das Startmuster wird gezeigt (korrekt! Verbindung scheint also zu 
funktionieren)
b)Nach dem "wait" kommt das Muster 0x60 für TW_SR_SLA_ACK, auch korrekt
c) Und dann kommt das Muster für 0xFE, was der ausgeschalteten LED D0 
entspricht, auch korrekt...aber das war's dann leider auch. Theoretisch 
müßte ja jetzt das Muster für die Datenübertragung folgen, tut's aber 
nicht.

Parallel kriege ich auf der Java-Seite den Error
java.io.IOException: Error writing to /dev/i2c-1 at address 0x40. Got 
-20001.
at com.pi4j.io.i2c.impl.I2CDeviceImpl.write(I2CDeviceImpl.java:72)
at TwiTest.run(TwiTest.java:32)
at TwiTest.main(TwiTest.java:14)

Ich knalle also direkt nach der erfolgreichen Adressierung vor die Wand, 
wobei die "Elektrik" zu funktionieren scheint. Was mache ich falsch?

Grüße und Danke
Frank

[1wire (Gast)]

Und,
was bedeutet "-20001"?

[Ulf H. (Firma: dg1faz) (ulfh)]

Braucht man in diesem Fall eigentlich einen Pegelwandler für I2C, wenn 
die Pullups für SDA und SCL an 3,3V gehen? Müsste das nicht einfach so 
funktionieren?

[Frank (Gast)]

1wire schrieb:
> Und,
> was bedeutet "-20001"?

Nicht herausfindbar! Habe mir einen Wolf gegoogelt...no way!

[Frank (Gast)]

Gordon von Pi4J sprach von einer empfindlichen I2C-Implementierung auf 
dem Raspberry. Insbesondere by clockstretching. Also habe ich mal alle 
wait_1_second-calls im Assemblerteil abgeschaltet....und schon klappt's 
!

Fast: An sich fluppt jetzt alles stabil und reproduzierbar. Aber das 
Hi-Byte des Datenbytes ist bei Antworten vom ATmega immer gesetzt. Das 
bedeutet 0 wird zu 128, 3 wird 133, 127 wird 255. Ab 128 stimmt's dann 
logischerweise, 128 bleibt 128 und 255 bleibt 255.

Ich zeige das Byte unmittelbar vor der Sendung am atmega als LED-Muster 
an und dort ist der Wert korrekt und das Hi-Byte nur bei Bedarf gesetzt.

Hat jemand eine Idee, wieso das Hi-Byte immer gesetzt ankommt?

Danke und Grüße
Frank

[Sebastian W. (wangnick)]

Hallo Frank,

der RasPi SoC von Broadcom hat einen Fehler in der I2C-Hardware, die 
clock stretching slaves zu simpel und dadurch fehlerhaft behandelt. 
Siehe http://www.raspberrypi.org/forums/viewtopic.php?p=146272, wo ich 
(so glaube ich) Gert van Loo als erster darauf hingewiesen habe, dass 
der Fehler signifikanter ist als zunächst angenommen und nicht ohne 
weiteres durch den Slave umgangen werden kann.

Ich umgehe dieses Problem indem ich auf dem Raspi die i2c-Frequenz 
leicht unter 100kHz konfiguriere, und die verbleibenden Fehler mit 
Prüfsummen etc. erkenne und vermeide.

LG, Sebastian