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

[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.