UART vs. I2C, Was ist schneller?

[Dirk]

Mein Vorschlag zur Einbindung der M128 in ein "RP6-Multimikroprozessorsystem" (klingt das nicht gut?), das zwischen den Plattformen als Single-Master-I2C implementiert wird, wäre:
Wir einigen uns darauf, ...
1. Die M256 WIFI wird Master.
2. RP6Base und M32 sind Slaves.
3. In einem gemeinsamen Projekt entwickeln wir einen universellen M32-Slave (genau wie der Base-Slave).
4. Die M128 wird nicht über I2C eingebunden.
5. Eine µC-µC-Direktverbindung (wie von SlyD vorgeschlagen) wird zwischen M128 und M256 über UART eingerichtet, und zwar von UART1 der M128 zu UART1 der M256 (beide bisher nicht genutzt). Vorteil: Weiterhin kann der RobotLoader oder ein Terminal an beiden Platinen an PROG_UART angeschlossen bleiben.
6. Mit einem Speed-Test ermitteln wir die noch sicher mögliche serielle Übertragungsrate zwischen M128 und M256.
7. Auf der M128 entsteht ein UART-Slave (meine spontane "Erfindung"), über die die M256 ähnlich Daten abfragen kann, wie von den I2C-Slaves.
8. Als "Interrupt-Leitung" zwischen M128 und M256 nutzen wir INT3 des XBUS (M128: INT6, M256: PCINT14). Vorteil 1: Der für I2C benutzte INT1 bleibt frei. Vorteil 2: Auch die M32 KANN diese "Interrupt-Leitung" lesen und schreiben (INT2).

So viel erst einmal ins Unreine gesprochen. Akzeptabel?

[RolfD]

@Dirk
Ich bin nach wie vor der Meinung, das ein Multimaster/Salve-I2C Bus Treiber auf allen Plattformen das Problem "RP6-Multimikroprozessorsystem" besser lösen würde und letztlich flexibler ist.
Einzig die M128 ist wegen dem "C-Betriebssystem" erst mal als Slave aussen vor, und als Master im Pollbetrieb recht begrenzt, ich halte es aber auch da für möglich, sowas zu nutzen. Nen IRQ Vector läst sich ja verbiegen.
UART Verbindungen sind natürlich auch möglich, aber nicht weniger Arbeit bezüglich coden - wobei es im Remotrol Projekt bereits ein I2C-Slave für die M32 gibt. Auch die M256 wäre Slave-tauglich und nichts hindert daran, die M128 weiter als "dummer" Master zu nutzen. Ausserdem braucht die M256 ihren mikerigen Speicher um einen Webserver per WLAN bereit zu stellen...
Das Ganze System von I2C auf UART zu krämpeln löst bestimmte Probleme eben nicht - bis auf die Tatsache das bessere UART Treiber Hardware/Software Ringbuffer haben und daher nicht so viel verloren geht... die mögliche Speed bei ALLEN Boards liegt bei deutlich über 400Kbit/sec - wenn man vernünftige I2C Treiber hätte...
LG Rolf

[Dirk]

@Rolf:

Ich bin nach wie vor der Meinung, das ein Multimaster/Salve-I2C Bus Treiber auf allen Plattformen das Problem "RP6-Multimikroprozessorsystem" besser lösen würde und letztlich flexibler ist.

Sehe ich genau so. Allerdings müßte man das coden. Was machen deine Tests in die Richtung (https://www.roboternetz.de/community...-RP6Lib-Bugfix)?

Das Ganze System von I2C auf UART zu krämpeln löst bestimmte Probleme eben nicht ...

Sehe ich auch so. Aber nur zwischen der M128 und M256 könnte es eine Lösung sein, falls man die M128 überhaupt mitnehmen will ...

[Filou89]

Also mir sagt die Idee von Dirk mehr zu, schon nur wegen der gut klingenden Ausdrücke
Man hätte dann sozusagen einen Roboter mit zwei Gehirnen, die sich über eine UART austauschen.
Es wäre dann noch schön, der M256 I2C Master Lib die Befehle für die M32 beizubringen. Eine M32Slave version gibt es schon, ist aber noch nicht ganz vollständig, sofern ich mich richtig erinnere.
Bei Punkt drei würde ich auf jeden Fall auch mithelfen. Ich habe bloss keine M128!

Grüsse
Filou

[RolfD]

@Filou89
Nun wie ich oben schon sagte... sowas liegt im ermessen des Entwicklers.. und ist keine Frage die man demokratisch lösen könnte. Ich hab auch was gegen "Glaubensfragen" beim programmieren denn es verschließt ggf. einfachere oder bessere Lösungsmöglichkeiten.
@Dirk
Zu deiner Frage bezüglich I2C, ich bin letztlich zu dem Schluß gekommen, das die aktuelle Struktur der RP6 Lib eine performante Lösung mit I2C nicht erlaubt. Das liegt an vielen Faktoren.
Für einen Multimasterbetrieb bzw. Master/Slave Betrieb gibts auch funktionierende Ansätze z.B. bei ArudinoLibs usw. aber da der RP6 in der Originalfasung der RP6Lib rein interrupt gesteuert ist, sind geregelte Abläufe vom guten Willen der Anwendung und weiteren Einflüssen wie Fahrkomandos bzw. Encoder interrupts abhängig. Oft genug wird in der RP6Lib gepollt und cpu-Zeit verbrannt was letztlich kein befriedigendes Ergebnis liefert.
Daher mein Engagement für RTOS und dort demnächst auch da mit einem I2C Treiber der stabiler und schneller laufen sollte. So meine Hoffnung/Planung. Das Thema ist für mich noch nicht vom Tisch.
LG Rolf