Raspberry Pi B+ [C] verschluckt erstes Bit I2C Problem

[Natureengeneer]

Hallo Liebe Forengemeinde.
Ich habe an einem Raspi einen Atmega per I2C hängen. Ich versende dabei im Moment immer 2 bytes und lese 2 bytes. Der Atmega ist mit einer Flachbandleitung an den Pi angeschlossen(Leitungslänge: ca. 150mm; Keine zusätzlichen Pullups am Atmega).

-Eine Änderung der Baudrate bewirkt leider keine Besserung.

Ich habe mir nun das Signal mit einem Logicanalyzer angeschaut und verglichen. Bild1: Korrekt "0XFF" gelesen; Bild2 & 3: "0x7F" gelesen.
I2C prob.JPG Hits: 13 Größe: 69,9 KB ID: 31481" class="thumbnail" style="float:CONFIG" />

Es kommt sporadisch vor, dass aus einem 0XFF welches vom Slave(Atmega) gesendet wird mal ein 0X7F am Raspi wird.
Ich bin leider kein Elektronikfachmann aber für mich schaut das ja danach aus als ob das erste BIT nicht korrekt vom Pi erkannt wird.

Hat jemand schonmal das gleiche Problem gehabt und kann mir erklären was ich genau Falsch mache?


Vielen Dank schonmal.

[HaWe]

ich habe (im Effekt )ähnliche Probleme bei meinen AVR-Arduinos beobachtet. Ein Arbeiten per I2C war hier absolut nicht möglich, da der Raspi sehr empfindlich auf clock-stretching reagiert, wodurch die I2C-Verbindung abbricht.

Ich weiß nun ntl nicht, wie sich deine Atmega i2c-lib von der Arduino-AVR-i2c-lib (Wire) unterscheided oder ihr ähnelt, immerhin klappt es mit den AVR-Arduinos aus diesem Grund nicht.

Dieselbern i2c-lib Funktionen laufen aber einwandfrei auf einem ARM-Arduino (Arduino-DUE), hier gibt es keine data transmission oder i2c-bus Probleme:

http://www.mindstormsforum.de/viewto...p=67815#p67908 (siehe Punkt 10 d) !!)


HTH!

[Natureengeneer]

Hi die verwendete c. Lib ist von Manfred Langemann falls es jemanden interessiert.

Da immer nur das erste byte Schrott ist und die darauffolgenden korrekt, sende ich nun immer 3 byte und lese 3bytes. Das erste byte wird dann bei mir im Code nicht verarbeitet.

Nicht schön aber funktioniert wenigstens.

[peterfido]

Hallo,

so wie ich das sehe, wird CLK gleichzeitig mit DAT gesetzt. Sieht für mich bald nach Software TWI am Atmel aus. Das sollte sich anpassen lassen. Besser wäre, wenn CLK bissel später kommt, wie bei dem io-Beispiel. Bei tatsächlich Hardware TWI könnte der Atmel zu viel Zeit benötigen. Da das Programm optimieren oder den Raspi eine Pause vor dem Einlesen machen lassen.

Auch möglich, dass da evtl. ein kleinerer Pullup an DAT als an CLK hilft, damit die Flanke schneller steigt. Denk dabei aber daran, die Ports des Raspi durch einen zu hohen Strom nicht zu stark zu belasten. Z.B. 10k0 an CLK und 4k7 an DAT. Viel Hoffnung würde ich mir da aber nicht machen.

[HaWe]

Raspi eine Pause vor dem Einlesen machen lassen

ob das klappt?
wie bereits erwähnt: der Raspi steigt bei clock-stretching aus, sonst gäbe es wohl auch kein Problem bei den AVR-Arduinos mit der AVR-Wire-Lib.
Der Ausweg wäre höchstens Bitbang-I2C, aber dann auf dem Raspi...

Allerdings soll der Jessie-kernel dafür demnächst verbessert werden!

[peterfido]

In diesem speziellen Fall hier lässt sich leider nur spekulieren. Von Vorteil wären beide Codes. Wenn der Atmel als Testcode nur darauf wartet, seinen Wert zu senden, dann braucht er keine Zeit dehnen.

Ansonsten hatten wir das Thema ja neulich mit ARDUINO schon. Da habe ich mangels Notwendigkeit nicht weiter gemacht.