Raspi C/C++, Raspi als I2C-Master: byte arrays zu Arduino slave hin + her schicken?

[HaWe]

@oberallgeier:
dann probier es doch mal bitte aus: Raspi plus AVR-Arduino!
Du hast das Problem mit dem Clockstretching, das der Raspi nicht verträgt, doch verstanden, oder?
Verbinde beide Boards (3 Kabel), lade die Sourcecodes, guck was dein Vorschlag bringt!

Wie schon so oft gesagt:

Für alle Tipps bin ich natürlich offen, aber der, der sie vorschlägt, müsste schon in der Lage sein, die Verbindung ebenfalls herzustellen und bei sich selber vor Ort zu testen (d.h. er müsste auch einen Raspi und einen Arduino besitzen und sie entsprechend verbinden und seinen eigenen - bzw. unseren gemeinsamen, auf einander abgestimmten - Code testen können).

@peterfido:
bin sehr gespannt!

angeblich soll ja pigpio Clock-Stretching unterstützen, im Gegensatz zu wiringPi.... :-/

... nur wie und was muss man da machen?



ps,
Zambetti's i2c-Code war auch die Grundlage für meinen Arduino-Slave-Teil.
Grundfunktionen sind i.P. 100% identisch!
(Nur mein Code stellt sicher, dass keine inkompletten Arrays gesendet, empfangen oder verarbeitet werden, sondern erst, wenn alle Bytes komplett im i2c-Buffer drin sind ...und dann getestet sind auf Transmission Errors !)

[HaWe]

hierin könnte die Lösung des Clock-Stretching-Problems bei den AVRs verborgen liegen:
http://abyz.co.uk/rpi/pigpio/cif.html#bbI2CZip

(nur verstehen tu ich's leider nicht, geschweige denn das Coding dann... säääähr schwäääre Kost.... :-/

[peterfido]

Hallo,

ich habe mir zwischenzeitlich den SourceCode von i2cset und i2cget besorgt. Da wird SMBUS genutzt, um auf I2C zuzugreifen. Komme heute aber nicht zum proggen. Es gibt eine Begrenzung von 32 Byte pro Block. Da bist Du mit den 30 schon knapp dran.

Ich stelle mir ein Protokoll vor, wo entweder die Registeradresse mit übergeben wird oder diese auf 0 bleibt. Bei 0 soll der Arduino dann automatisch inkrementieren.

So braucht man auch nicht jedesmal die 30 (32) Bytes rüberschicken, wenn nur ein Byte geändert werden soll. Das spart Zeit, wenn der Arduino z.B. ein Display ansteuert. Darüber braucht man sich aber erst Gedanken zu machen, wenn die Kommunikation steht.

Wenn Du Dein verlinktes BitBang-Beispiel nutzen möchtest, dann kann jeder PIN genutzt werden. Die Pullups berücksichtigen.

Oben im Code

#include <pigpio.h>

und dann die Funktionen aufrufen. Klingt recht einfach. Damit fange ich morgen mal an.

[HaWe]

die Arrays hin- und her schicken hat sowohl remote-control als auch Portexpander- (Telemetrie-) Zwecke. Zum einen sollen vom Raspi aus Encodermotoren gesteuert werden, zum anderen sollen möglichst schnell (auch zum Update der Fernsteuerung) alle möglichen Sensoren auf dem Slave ausgelesen werden.
32 Bytes sind dazu mehr als knapp, besser wären mindestens 64, gerade weil Encoderwerte 32 bit lang sind.
Auch Werte von i2c- oder UART-Sensoren auf dem Arduino sollen an den Raspi übermittelt werden können, die oft floats sind (also ebenfalls 32 bit).
Der Fall, dass nur 1 Byte im Array geändert wird, wird also fast nie vorkommen.

Wenn es keine Möglichkeit gibt, den I2C buffer vom Raspi auf 64 Bytes zu erhöhen, müssen sich 2 Arduino-Boards die Arbeit teilen. Allerdings scheidet dann der Mega komplett aus, da er ja bereits jetzt am Bus über 3mA per Pegelwandler gegen die 5V Pullups ziehen muss, und 3mA ist die Höchstgrenze für SDA/SCL laut I2C-specs. Und weitere i2c-Geräte kommen ja sowieso noch hinzu (zum Glück aber nicht mehr als hundert)

Ich komme daher immer mehr zu der Überzeugung, dass die AVRs zur Zeit eine Sackgasse sind, wegen clock-stretching, und speziell auch der Mega wegen seiner zusätzlichen Pullups.

Das bedeutet allerdings dann: nur DUEs werden zur Zeit Sinn machen, da nichts anderes funktioniert.

Oder, wie Gordon Henderson (Autor der wiringPi libs) schrieb, nur eins macht Sinn für die AVRs: "... a newer version of the kernel driver.. So one day..."

Trotzdem bin ich natürlich auf deine pigpio-Versuche gespannt, insbesondere mit mehreren Geräten am selben Bus.

[peterfido]

Da bleibt dann nur BitBang übrig. Da gibt es keine Einschränkungen, was die Puffergröße betrifft, da alles zu Fuss gemacht wird. DiePullups des Mega sollten sich mit etwas Geschick entfernen lassen. Wo hast Du die 3mA her? Die Pullups des Raspis scheinen 1k8 zu sein. Also knapp unter 2mA. Der MEGA hat bei 5V und 10k Pullups 0,5 mA. Den Strom des Pegelwandlers müsste dieser doch selbst verkraften. Nachgemessen habe ich es nicht.

Wenn der MEGA der einzige problematische Slave am Raspi ist, kann man auch ein eigenes Protokoll per BitBanging auf beiden Seiten verwenden. Bei Verwendung anderer PINs bleibt I2C für die anderen Slaves erhalten. Hätte den Vorteil, dass der MEGA nicht als Slave und Master arbeiten müsste. Oder halt im Multimaster-Betrieb. Oder SPI, da gibt es dann wieder Hardware-Puffer, welche von Vorteil sind, wenn der MEGA eh noch Einiges zu tun hat. Bei der Nutzung von Interrupts geht bei einer Zwei-Draht-Verbindung ohne Hardware-Puffer das ein oder andere Bit verloren.

Ich selbst brauche es nicht und sehe es nur als Herausforderung und kann es evtl. irgendwann doch mal brauchen. Aktuell habe ich zwei Favoriten: Den SMBUS-Treiber und BitBang. Wobei BitBang auf dem ersten Blick wesentlich einfacher scheint.

[HaWe]

Die Info samt Berechnung stammt aus dem Arduino-Forum:

The Arduino Mega 2560 is the only board with those 10k resistors on the board for I2C. Any other board would be no problem.

Connect 5V with 10k to 3.3V with 1k8. That makes 3.55V
I don't like that, often 3.6V is the limit for 3.3V chips, and this is very close.

Using a dirty trick with a resistor to GND to lower it might also cause trouble. The Arduino Mega board needs 3.5V to see a I2C level as high.

With a level shifter, the Arduino has to pull both sides of the level shifter down. A level shifter has often 10k on both sides.
Total current:
5V with 10k and 10k : 1mA
3.3V with 1k8 and 10k : 2.16mA
Together it is above 3mA, which is specified as the maximum current by the official I2C standard. But that 3mA is not very strict, it will work

Bitbang ist ja, was im Prinzip auch pigpio macht bzw. machen kann.

SPI ist keine Option, weil SPI bereits auf dem Arduino voll ausgeschöpft ist (84MBit/s DMA für TFT).
Außerdem ist I2C Pflicht, weil ja zusätzlich MCPs und PCFs und auch der CMPS11 gemeinsam dran sollen.

SMBus ist aber nichts anderes als eine Raspi-I2C-Implementierung, oder irre ich mich?


ps,
leider ist joan nicht sehr hilfsbereit für die Implementierung ihrer pigpio API-libs. Es werden zwar Links zur Verfügung gestellt (s.o.), aber wie es jetzt genau funktioniert anstelle von read() und write().... Schweigen im Walde.

Selbst Gordon Henderson war es bisher nicht klar, dass pigpio überhaupt clock-stretching per bitbang zur Verfügung stellen könnte.

[Peter(TOO)]

Hallo,

SMBus ist aber nichts anderes als eine Raspi-I2C-Implementierung, oder irre ich mich?

I2C wurde von Phlips Anfang der 80er entwickelt um Chips in Fernsehern einfach zu verbinden.

SMBus basiert auf dem I2C und wurde 1995 von Intel veröffentlicht ud war für PCs gedacht um Jumper zu ersetzen, Seriennummern und Parameter zu setzen und abzufragen. z.B. haben die Speichermodule ein Rom, in welchem Grösse, Timing-Parameter usw. abgelegt sind.

SMBus funktioniert zwischen 10kHz und 100kHz, I2C DC bis 400kHz und 2MHz.
SMBus kennt ein Timeout (35ms).
Die Pegel sind etwas unterschiedlich

MfG Peter(TOO)