UART vs. I2C, Was ist schneller?

Hallo,
ich habe heute mal eine etwas speziellere Frage:
Es geht um das Thema Geschwindigkeit. Da ich nun dank Arexx ein M256 Modul besitze, muss ich mir überlegen, wie genau die Kommunikation zwischen den Modulen ablaufen soll.
Ich habe außerdem ein M128 Modul, welcher leider nicht als I2C Slave benutzbar ist (zumindest nicht ohne Probleme)
Daher muss mein neues M256 als Slave herhalten aber trotzdem als zentrale Kommunikationseinheit mit meinem PC dienen. (Sonst wäre das Wlan ja sinnlos :D )

Nun die eigentliche Frage: Ich muss viele Daten vom I2C Master (M128 ) zum M256 übertragen. Das sind alles Sensordaten, also floats und ints.
Was wäre in diesem Fall günstiger:

1. Alle Daten über I2C vom Master zum Slave schreiben und dann per Wlan weiter zum PC
2. Oder vom Master per UART zum Slave und dort dann einfach alles was per UART kommt aufs Wifi spiegeln?

Primärer Entscheidungspunkt wäre die Geschwindigkeit / Latenz der Übertragung. Die entstehende Prozessorlast wäre eher zweitrangig. Allerdings wäre bei der I2C Variante die Rechenlast besser verteilt, da ich die Analyse der PC Befehle auf der M256 machen könnte. Die M128 würde die Befehle dann nur noch umsetzen.

Der Rückweg wäre analog dazu. Also Befehle die vom PC kommen werden entweder in I2C Register geschrieben oder per UART an den Master übertragen.

Das würde mich auch sehr interessieren, ich vermute, dass UART bei einer passenden Baudrate (etwa >=115.2kBaud) schneller ist als I2C (das läuft auf dem RP6 standardmäßig mit 100kHz), wobei durch das erforderliche neue Protokoll je nach Implementierung einiges an Overhead entstehen wird. Passende Baudraten kannst Du z.B. hiermit: http://www.gjlay.de/helferlein/avr-uart-rechner.html errechnen. Noch dazu musst Du bei UART keine Rücksicht auf den fehlenden I2C-Slave des M128 nehmen.

Zitat:

---

Das sind alles Sensordaten, also floats und ints.

---

Hier wäre es eventuell von Vorteil, die Sensordaten im "Rohformat" zu übertragen und sie erst auf dem PC/Endprozessor umzuwandeln. Das kann die Datenmenge eventuell schon einmal etwas reduzieren.

Die Übertragung von der "Einheit" RP6 zum PC ist kein Problem, über Wifi sind das 40-50 KB/s, das ist deutlich mehr als benötigt.
Nur die Kommunikation "intern", also auf dem RP6 ist interessant.
Ich habe ehrlich gesagt keine Ahnung, wie schnell so ein I2C Bus ist, wenn man allerdings per UART überträgt müsste ich eine weitere Entscheidung treffen:

1. Entweder werden die Daten "formatiert" zwischen M128 und M256 übertragen und die M256 spiegelt einfach alles auf den Wifi Ausgang
2. Oder die M128 sendet alles "raw" und die M256 muss die Daten interpretieren und dann formatieren und per Wifi senden

Die zweite Alternative halte ich für Verschwendung von Rechenleistung.

Eine andere Alternative ist: M128 I2C Bus deaktivieren, M256 als Master...
Verbindung zwischen M256 und M128 nur per UART und ein paar GPIOs für Interrupts...
Reduziert die Menge der Daten die erst per I2C zur M128 und dann per UART zur M256 gehen müssen da diese den Rest vom Bus
einfach selbst abfragt. Die M128 kümmert sich dann nur um die Sensoren die lokal angeschlossen sind. Das ist dann ähnlich
wie wenn man die M32 als I2C Slave benutzt, aber spart Bandbreite auf dem I2C Bus.


Bitte beachten, dass die M128 ein 14.7456 MHz Baudratenquarz verwendet, die M256 allerdings nicht (um die maximale Taktfrequenz zu erreichen).
Daher sind Baudraten bis 115k möglich, darüber wäre die Abweichung zu hoch. Sollte aber reichen.

Beim I2C Bus ist die Datenrate bei gleicher Bitrate geringer als beim UART, da ja noch Adressen und ggf. Registeradressen sowie ACK/NACK übertragen werden.
Kommt dann drauf an wieviele Daten man in einer Transaktion schreibt - also einmal die Adresse und Startregister übertragen und dann 255 Bytes übertragen ist deutlich schneller als wenn man jedes Byte in einer einzelnen Transaktion sendet.

Zitat:

---

(das läuft auf dem RP6 standardmäßig mit 100kHz),

---

Spricht aber nix dagegen das auf 400kHz zu erhöhen wenn mans braucht. Dann würde ich schätzen hat man bei typischer Verwendung eine ähnliche effektive Datenrate wie bei 115k - 230k UART.

MfG,
SlyD

Das wäre in der Tat eine Alternative. Danke auch für den I2C Tipp, das wäre bei dieser Variante ja ziemlich wichtig.
Das klingt für mich jetzt so, als ob es keinen riesen Unterschied macht. Mal sehen was sich leichter implementieren lässt / besser wartbar ist :)

Zitat:

---

Zitat von SlyD

... M128 ein 14.7456 MHz Baudratenquarz ... 115k möglich, darüber ... Abweichung zu hoch...

---

Ich habe mir mit nem FTDI einen Eigenbau USB-UART-Wandler (klick und Bild unten) gebaut - da fahre ich problemlos 256K vom Controller zum PC mit dem Terminal von br@y, vermutlich ist noch mehr möglich. Da vermute ich, dass auch eine evtl. Controller-Controller-Verbindung ähnlich schnell arbeiten könnte.

......Bild hier  


Allerdings habe ich meine Sende-define-BAUD gelogen:

Code:

---

//      CPU definiert im AVRStudio
// #define BAUD          57600    //
  #define BAUD          230400  // Diese Einstellung bei USB-Adapter - 256000

---

Die Fehlermöglichkeit des UARTS durch die ganzzahlige UBRR spielt da offensichtich keine Rolle, ich bin aber dem Grund dafür noch nicht nachgegangen. Allerdings hatte ich mir das bei Verwendung des max232 mal zu Gemüte geführt (klick)

Wenn auf die Beschränkung auf eine der üblichen Baudraten entfällt, sollte sich für die beiden Quarztakte vermutlich auch noch eine höhere gemeinsame Baudrate (z.B. 193 kBaud) finden lassen.

Noch schneller wäre ein Verbindung per SPI.

Die Übertragung als raw, und dann erst umrechnen ist nicht so abwegig. Es kommt halt darauf an welcher µC noch Rechenleistung über hat. Sonst ggf. die Daten erst am PC vom RAW Format umrechnen.

@Oberallgeier:

Klar geht das mit dem FTDI mit alle möglichen Baudraten - der RP6 nutzt ja auch 500k Baud für den Bootloader.
(Und zum WLAN Modul auch weil es da vom Takt her genau passt)
Der FTDI hat aber auch einen fraktionalen Baudraten Generator drin und kann so ziemlich alle denkbaren Baudraten passend erzeugen.
Die ATMEGAs haben sowas nicht, daher ist der Quarztakt wichtig.

Alles +-3% Abweichung ist übrigens OK.

MfG,
SlyD

Hallo zusammen
Das schnellste wäre wirklich die SPI Schnittstelle.
Beim I2C Bus könnte es aber sein, dass nicht alle Sensoren mit 400kHz arbeiten können.
Normalerweise hat man pro I2C Bus nur einen Master. Es ist aber auch ein Multi Master Mode möglich. Mit dem RP6 weiss ich zwar nicht, ob das gehen wird, aber du könntest dann die M128 und M256 als Master betreiben.

Grüsse Filou

Jo klar!
die M256 holt sich alle Sensordaten der anderen Module (Base, M32, M128 und seine eigenen) aus den Registern und gibt sie an den PC weiter.
außerdem gibt sie via WLAN empfangene Befehle an die M128 über UART weiter, welche dann die Befehle als Master ausführt und weitergibt...
kann das so laufen???

Klingt jedenfalls spannend ;)