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

[peterfido]

Hallo,

nein. Das ist ein alternatives Protokoll. Getestet mit 240 Nutzbytes. Das kannst Du an Deine Zwecke anpassen und testen. Ich hatte es so verstanden, dass 30 Bytes nicht ausreichen.

Evtl. läuft es mit 32 Bytes immer noch fehlerfrei. Wobei Du die Slave-Adresse nicht mitschicken brauchst, da er ja nur auf seine Slave-Adresse reagiert bzw. reagieren sollte. Aufpassen musst Du darauf, dass nach der Prüfsummenbildung die Bytes nicht mehr verändert werden. Das ist bei dem Testcode nicht der Fall, kann später, wenn der MEGA ein paar Bytes mit anderen ICs austauscht, Zeitprobleme mitbringen. Wenn alles bis zur nächsten senddata-Bildung noch zwischengespeichert werden muss. Da lässt sich Zeit sparen, wenn die Prüfsumme gleich beim Array-Zusammenbau mit berechnet wird.

Ich habe mich mal über den DUE informiert. Dieser spielt in einer ganz anderen Liga als der MEGA. Wenn Du für den ARDUINO ein Display vorgesehen hast, werden die 10 ms-Lücken zwischen I2C-Datenaustausch für Display, die Ansteuerung weiterer IC´s über evtl. UART ISP und I2C sowie Speicherkopiererei und evtl. TimerInterrupts bei den 16MHz des MEGA etwas knapp.

Ich mache es immer umgekehrt. Der Raspi ist der Kommunikative und dient dem AVR per UART als Gateway zu allen sonstiges Gerätchen. Vor Allem Ethernet bzw. WLAN fehlen den AVRs. Leider auch dem DUE, obwohl es der Mikrocontroller quasi mitbringt. Dann übernimmt der Raspi neben dem Webinterface oft noch Lautsprecher und die farbige Anzeige auf Bilderrahmen über lcd4linux per USB.

Deine Projekt kenne ich nicht und weiß nicht, was da zeitkritisches vor sich gehen soll, bzw. warum das Timing so brisant ist.

Das schnellste ist ganz klar SPI. Danach kommt UART, wenn man ein Baudratenquartz hat, danach dann I2C. Parallel ist theoretisch 8 mal so schnell wie UART, wird aber von der Hardware nicht unterstützt und läuft ohne Puffer nicht ganz so zuverlässig. Benötigt aber auch die meisten PortPins. Bei SPI geht Dein Protokoll aber nicht, da bei jedem Senden auch gleichzeitig empfangen wird.

[HaWe]

achso - sogar 240 statt 32 Bytes - das ist ntl ein dicker Pluspunkt, und dass das SPI-Display hier ein Zeitproblemwerden könnte, stimmt auch, das habe ich noch gar nicht ausgetestet. Ich wollte die ILI9341_due lib verwenden, die soll angeblich auch mit dem Mega laufen - selber gemacht habe ich es damit aber nicht, nur mit dem Due. Wäre in der Tat ein weiterer Knackpunkt.
Danke nochmal für die Erklärungen und Tipps!

- - - Aktualisiert - - -

es geht im Prinzip darum, Arduinos sowohl als Sensor-Multiplexer als auch für Fernsteuerungen zu nutzen, und darum, gleichzeitig auch noch weitere spezielle I2C und UART-Sensoren an den Raspi anzuschließen (IMU- GPS, RTC - vllt sogar mal nen LIDAR).
UART alleine reicht dazu nicht aus, weil nur ein "slave" angeschlossen werden kann, bei I2C dagegen dutzende am selben Port. Je mehr Geräte am Bus hängen, desto schneller muss aber jedes einzelne Gerät arbeiten und gesteuert werden können.

[peterfido]

Hallo,

das klingt nach ein paar interessante Aufgaben. IMU, GPS und LIDAR nach einem selbstfahrenden Fahrzeug. Wenn GPS vorhanden ist, kann die RTC wegfallen. Wobei der Raspi ja auch eine Uhr hat. So braucht die RTC nur gelegentlich abgeglichen werden. Der Raspi selbst hat mehrere UARTs. Ein USB-Hub dran und daran ein paar FTDI anschließen. Dutzende I2C Slaves teilen sich die Geschwindigkeit von 100k. Soll der Bus schneller laufen, müssen alle mit der höheren Geschwindigkeit klar kommen.

Bei einem selbst gebauten Protokoll, können an einem UART auch mehrere 'Slaves' hängen. Einfach einen Ring aufbauen. Der Nachteil ist, dass alle Slaves die Daten weiterreichen müssen. Also überall Mikrocontroller dran. Diese können über einen zweiten UART andere Geräte bedienen. Das (mein) Protokoll (an welchem ich nicht weiter arbeite) ist etwas trickreich oder es müssen entsprechend große Buffer verwendet werden. Daher nehme ich lieber die Lösung mit mehreren UARTs.

Deine Idee, I2C zu nutzen, gefällt mir. Mich stören eher meine Testergebnisse. Evtl. arbeite ich da nochmal weiter dran. Dafür muss ich aber erstmal investieren. Evtl. habe ich sogar noch einen 'alten' Raspi irgendwo rum(f)liegen, damit einer mal als Slave dienen kann. Einen DUE-Nachbau plus SPI-Display habe ich mir heute geordert. Während meines Bestellvorgangs ging die Anzahl der Verfügbaren nach unten. Evtl. lesen hier welche mit und kaufen nun ein

Ich selbst habe viel mit AVRs gebaut. Eigene Platinen mit Löten und so. Das mach mir immer weniger Spass. (Brille ab, Brille auf, Lupe,... - Das brauchte ich 'früher' alles nicht) Bei den ARDUINOs reicht zusammenstecken und programmieren. Wobei es mir aktuell mehr ums programmieren (wenn es draußen ungemütlich ist) an sich geht. Allerdings habe ich da auch noch ein paar Windows-Tools in der Pipeline...

[HaWe]

stimmt, ein selbstfahrendes Fahrzeug, die Idee mit den USB Hubs hatte ich auch schon, gefällt mir aber nicht so gut.
Mein Setup sieht z.Zt.: vor:
1x UART slave für BT Fernbedienung und Telemetrie (USB/FTDI)
1x UART Slave (Mega) für schnelle IOs
1-2x I2C Slave (Dues) für den ganzen Rest, auch für weitere Huckepack-Sensoren auf den Arduinos mit drauf (wschl auch GPS).

GPS indoors hat oft schlechte Verbindung, daher zusätzlich die RTC, und auch WiFi habe ich nicht immer empfangsbereit.
Insgesamt sind für die meisten Sensoren viel bessere und einfachere Arduino-Libs vorhanden als für den Raspi mit seinen ganzen komplizierten device trees, daher will ich die meisten huckepack nehmen (vlt auch den UART-GPS). Der IMU (CMPS11, i2c) muss aber direkt an Raspi-I2c dran wegen Geschwindigkeit für die Lokalisierung (Navigation, Ortung) fusioniert mit der Odometrie und anderen Distanzsensoren, Baken-Peilungen und was auch immer.

Es soll aber vlt schon bald ein Raspi Jessie-Kernel-Update kommen, das besser clock-stretching-veträglich ist (wird offenbar dran gearbeitet, hatte ich oben schon verlinkt). Dann werden die AVRs sicher genauso einfach und problemlos mit wiringPi laufen wie jetzt schon meine Dues, daher brennt es mir nicht ganz so unter den Nägeln mit meinen Megas. Es gibt eh noch unglaublich viel an Vorbereitungen zu tun und zu entwickeln...

ps,
als Display empfehle ich ILI9341-TFTs, denn dafür gibt es die irre schnelle ILI9341_due lib mit 84MHz DMA auf dem SPI - alle anderen sind ein dutzend Mal langsamer:
http://www.mindstormsforum.de/viewto...&t=8491#p66189
http://marekburiak.github.io/ILI9341_due/
Nachteil: es gibt Inkompatibilitäten mit SD-Libs.


pps
ich habe mir gerade auch einen 2. Raspi 2 Model B bestellt für 40 EUR inkl. Versand - jetzt kann ich besser und einfacher an verschiedenen Baustellen gleichzeitig arbeiten -
einmal für die Fernsteuerung und die Multiplexer, und einmal direkt am Robo für die Motoren und Odometrie-Tests. Was immer noch fehlt, ist sehr viel Zeit dafür....

[peterfido]

Was immer noch fehlt, ist sehr viel Zeit dafür....

Hallo,

ja, das ist DER Knackpunkt. Als Display habe ich mir eines mit dem ILI9341 bestellt. Mal sehen, wie die 2,2 Zoll so wirken. Wirklich schade finde ich, dass die beim DUE nicht die Ethernet-Schnittstelle rausgeführt haben. Gerade, wo doch iot DAS Thema überhaupt ist. Und was mir noch fehlt, sind vernünftige, wohnzimmertaugliche Gehäuse mit Aussparungen für Display und vernünftige Tastaturen sowie Platz für Netzteil- oder andere Platinen. Ich mißbrauche oft Radiogehäuse, DVD-Player-Gehäuse usw.

Durch den / die / das also THE pigpio bist Du flexibel und kannst mehrere I2C-Busse fahren. Von Vorteil wäre da noch ein Pausen-Kommando. Der Pi kann recht einfach Multithreading. Da könnte man die Synchronisation mit den ARDUINOs in einem eigenen Thread laufen lassen und blockiert so keine anderen Routinen. GPS hat etwas den Nachteil, dass es kontinuierlich Daten zum Mikrocontroller sendet. Selbst, wenn Du dann UART pufferst, wird bei jedem empfangenen Zeichen kurz ein Interrupt ausgelöst, um es im Puffer abzulegen. Das könnte dem I2C in die Quere kommen. Oder man deaktiviert solange den GPS-UART. Aber da dann immer ein volles GPS-Telegramm zu erhalten, könnte 'tricky' werden.

Also doch lieber an den Raspi. (Oder den DUE. Da fehlt mir aber (noch) die Erfahrung.)

[Mxt]

Wirklich schade finde ich, dass die beim DUE nicht die Ethernet-Schnittstelle rausgeführt haben. Gerade, wo doch iot DAS Thema überhaupt ist.

Das muss wohl so sein, um Arduino kompatibel zu bleiben. Da macht man Ethernet halt über ein Shield, weil das immer schon so war. Beim Galileo z.B. simuliert das Linux darauf ein Ethernetshield in Software. So eine Lösung würde den Due sicher zu sehr auslasten.

Schade ist das schon, da hast du Recht. Über Ethernet schaffe ich einige Megabyte pro Sekunde zwischen Raspi und Mikrocontroller.