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.
Gast
#3408870
Eventuell eine komische Umwandlung zwischen char und unsigned char oder so?
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.
Ist bei i2c das 8Bit nicht dazu da um dem Slave mitzuteilen ob es ein Schreib oder ein Lesevorgang ist?
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.
Gast
#3408960
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
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
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
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.