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

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