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

[peterfido]

Hallo,

wenn das Beispiel zu langsam ist, würde ich die Pausen verkürzen. Aus sleep(1) usleep(100), aus delay(2) delay(1), oder beim Senden vom ARDUINO ganz auf das delay verzichten.

[HaWe]

wie 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).

Augenblicklich überträgt der Raspi-Master zum Arduino und zurück gerade mal 2 arrays pro Sekunde (!!), per Arduino-Master ist das gleiche Programm > 30x so schnell. Da wird eine Verkürzung um ein paar millis oder micros nichts ausmachen.
Es liegt vielmehr am Zusammenspiel der beiden i2c-Implementierungen, dem langsamen Arduino und dem prinzipiell schnelleren Raspi, der aber clock-stretching nicht verträgt - damit bricht die Kommunikation ein. Außerdem braucht der Arduino ZWINGEND delays, um überhaupt auf requests reagieren zu können. Die Sache ist also recht kniffelig.

Nicht umsonst habe ich daher oben geschrieben:

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

vermutlich hast du deinen Vorschlag also nicht getestet...?

[peterfido]

Nein,
aber ich bin in der Lage dazu, da ich die Voraussetzungen alle erfülle Für ein Nachstellen der Situation fehlt mir an diesem WE die Zeit. Ich komm leider nicht mal dazu, an meinem eigenen aktuellen Projekt zu programmieren

Eine 1a Kommunikation zwischen Raspi und AVR klappt per UART. Hier laufen 5 solcher Paare schon eine Zeit lang.

I2C zwischen Raspi und Display sowie ARDUINO und Display läuft bei mir gefühlt verzögerungsfrei. I2C zwischen Raspi und ARDUINO habe ich wegen UART noch nicht gebraucht. Muss es unbedingt I2C sein, wo Clock Stretching, welches dem Raspi zu schaffen macht, wahrscheinlich ist? Und wenn ja, hängen da noch weitere Geräte auf dem Bus? Clock Stretching ist beim Raspi problematisch. Entweder gleich vermeiden, z.B. durch einen langsameren I2C Takt oder I2C zu Fuß per Bit Banging nachbauen. Erfolge soll es auch geben, wenn dem AVR Rechenzeit durch Verzögerung der Read-Ack verschafft wird.

Was, wenn der Raspi erst einen Befehl sendet, dass der ARDUINO weiß, dass er Daten zum Senden parat haben muss, das Lesen der Daten in einer bestimmten Zeit x passiert?

Auf einer Raspi-Zusatzplatine, deren Name mir gerade nicht einfällt, wird das Problem durch einen zusätzlichen Mikrocontroller als I2C -Proxy umgangen.

[HaWe]

UART funktioniert perfekt, sogar drahtlos - aber der Raspi hat nur 1 UART, USB ist besetzt, aber viel wichtiger: UART kann nur 1 "slave", I2C aber über 100...
Und UART wird für eine Drahtlos-Fernsteuerung benutzt... (2x HC-05: was war das für eine Höllenqual, bis ich die endlich zum Laufen hatte!)

Ich hab zwar nun keine 100 slaves, aber 2 Arduinos (1x Due, 1x Mega) plus GPS plus IMU plus RTC .... (auch über eine Pixy cam bin ich jetzt wieder gestolpert).
Wenn es also schnell genug ginge, könnten alle an 1 i2c-1, notfalls ein Teil davon an i2c-0.

Wenn du also testen kannst - ich bin gespannt! (y) +1 8-)