I2C, Daten gehen verloren

[Georg G. (Firma: ADV-Service) (mcgeorge)]

Hallo,
ich hoffe hier kennt sich jemand mit dem i2c-Bus aus und kann mir sagen 
warum das so ist:

Folgendes Problem habe ich:

Ich habe einen PIC so programmiert, dass er als I2C-Slave arbeitet. In 
dem PIC habe ich einen Zähler, der bei jedem abruf um 1 hochzählt.
Nun lese ich Byte für Byte vom PIC und hatte eigentlich erwartet, dass 
bei meinem Master die Zahlen 0x00 bis 0xFF ankommen. Aber das ist nicht 
geschehen!

Nach 0x7F sollte eigentlich 0x80 kommen aber gekommen ist 0x00.

Also habe ich mir einen LogicAnalyser gekauft und den Bus 
mitgeschrieben. Auf dem I2C-Bus wird tatsächlich eine 0x80 vom Slave zum 
Maser geschickt. Aber es wird beim Master immer das 8 Bit verschluckt.
(Achso, der Master ist ein RaspberryPi mit Pytonskript)

Nun zu meiner Frage: Gibt es einen Grund oder irgendeine Spezifikation, 
die erklärt, warum bei der Übertragung von Daten vom Slave zum Master 
immer das 8 Bit verschluckt wird.

Vielen Dank für jeden Tipp.

[CC (Gast)]

Eventuell eine komische Umwandlung zwischen char und unsigned char oder 
so?

[Georg G. (Firma: ADV-Service) (mcgeorge)]

CC schrieb:
> Eventuell eine komische Umwandlung zwischen char und unsigned char oder
> so?

Da ich auch schon an der Pyton-Lib gezweifelt hatte, habe ich die 
i2c-Tools genutzt. Wenn ich meinen PIC-Slave mit "i2cget -y 1 0x18" 
auslese, wird das ausgelesene Byte hexadezimal angezeigt. Und auch dort 
tritt das gleiche Verhalten auf, dass bei dem auslesen, das 8te Bit 
fehlt.

[Dominic A. (neo123)]

Ist bei i2c das 8Bit nicht dazu da um dem Slave mitzuteilen ob es ein 
Schreib oder ein Lesevorgang ist?

[Georg G. (Firma: ADV-Service) (mcgeorge)]

Dominic A. schrieb:
> Ist bei i2c das 8Bit nicht dazu da um dem Slave mitzuteilen ob es ein
> Schreib oder ein Lesevorgang ist?

Jetzt bin ich verunsichert, ob Bit 7 oder 0 links oder rechts ist. Für 
mein Verständnis ist ganz links 7 und rechts 0. Dann ist das Bit 0 im 
Bus für lesen oder schreiben zuständig und 1 bis 7 für die Adresse. 
Zumindest beim Mitschnitt mit meinem LA. Und das Bit 7 (also das 8te) 
geht immer verloren beim lesen.
Aber daran gedacht hatte ich auch schon, da ich festgestellt habe, dass 
die angegebene Slaveadresse um ein Bit nach links verschben wird und das 
R/W Bit angehangen wird.
Das erklärt vielleicht den Verlust des Bits bei der Slave-Adresse. Aber 
was ich lese sind Daten, keine Adressen. Die sollten, so dachte ich, 
unverändert über den Bus kommen.

[Klaus (Gast)]

Georg G. schrieb:
> Nun zu meiner Frage: Gibt es einen Grund oder irgendeine Spezifikation,
> die erklärt, warum bei der Übertragung von Daten vom Slave zum Master
> immer das 8 Bit verschluckt wird.

Nein, jedenfalls nicht bei I2C.

Dominic A. schrieb:
> Ist bei i2c das 8Bit nicht dazu da um dem Slave mitzuteilen ob es ein
> Schreib oder ein Lesevorgang ist?

Das gilt für das Adressbyte und ist nicht das 8. Bit sondern das 1. Bit.
Hier
> Wenn ich meinen PIC-Slave mit "i2cget -y 1 0x18"
würde es sich auf die 0x18 beziehen.

MfG Klaus

[Cyblord -. (cyblord)]

Hört doch auf vom 1. und vom 8. Bit zu sprechen, was soll denn sowas 
aussagen? Es gibt ein MSB und ein LSB. Und das LSB vom Adressbyte gibt 
die Datenrichtung für die nachfolgende Übertragung an. Aber nur vom 
Adressbyte.

Warum haben eigentlich grade RasPi Benutzer derart heftige Probleme mit 
I2C? Es gibt jetzt schon zig Posts mit diesem Thema. Woran liegts?

gruß cyblord

[Sebastian W. (wangnick)]

Hallo Georg,

eventuell trifft dich das: "There is a bug in the [Raspi] I2C master 
[hardware] that it does not support clock stretching ..."?

Für weitere Informationen, und Möglichkeiten der Umgehung, siehe
http://elinux.org/BCM2835_datasheet_errata#p35_I2C_clock_stretching,
https://github.com/raspberrypi/linux/issues/254,
http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html und
https://dl.dropboxusercontent.com/u/3669512/2835_I2C%20interface.pdf. Du
solltest also Mechanismen einbauen, um korrupte I2C-Kommunikation
aufzufangen (Checksums, Retransmissions, ...).

LG, Sebastian

[Peter D. (peda)]

Sebastian Wangnick schrieb:
> Du
> solltest also Mechanismen einbauen, um korrupte I2C-Kommunikation
> aufzufangen (Checksums, Retransmissions, ...).


Was ist bloß so schwer daran, die original Philips Stezifikationen und 
Datasheets zu lesen und einfach nach zu implementieren. Die laufen schon 
seit den 80-er Jahren stabil.
Und an zu wenig Transistoren dürfte es bei neuen MCs ja nicht scheitern.

Ich hab jahrelang die uralten Philips MCs (P87C751, P80C652) mit I2C 
benutzt, die laufen wie dumm ohne jede Störung als Single-Master, 
Multi-Master und Slave.

Wenn das HW-I2C buggy ist, kann man Single-Master ganz bequem mit 2 
IO-Pins in SW implementieren. Kostet zwar mehr CPU-Last, läuft dafür 
aber 100% zuverlässig.