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