mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C vs. UART Vor-/Nachteile


Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte 4 ATmega8 und einen ATmega32 miteinander verbinden. Dabei ist 
der ATmega32 der Master. Die ATmega8 haben untereinander aber nichts 
auszutauschen nur jweils zum ATmega32. Soll ich dafür I2C oder UART 
nehmen. Wenn ich den UART nehmen würde, würde ich den 74HCT126 
dazwischen schalten, damit der die Verbindungen freischaltet, weil ja 
nur einer mit dem ATmega32 kommunizieren darf. Welche Vor- und Nachteile 
gibt es da?


MfG
Mathias

Autor: Sumynona (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die Leitungslängen schön kurz sind, ist das ein klassischer Fall 
für TWI/I²C. Bitte beachte auch die Bitrate die du damit fahren kannst, 
und die Latenzzeiten durch einen belegten Bus.
Andererseits ist deine "Umschalterlogik" sicher nicht effizienter ;-)

Autor: ::: (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus einer Leiterplatte wuerde man SPI nehmen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRs sind ganz passable SPI-Master, aber mangels Puffer miserable 
SPI-Slaves. I2C ist einfach zu verwenden und wenig aufwendig, solange 
man im Bereich von einem Meter bleibt. Darüber muss man sich Gedanken um 
den Bus machen.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Die UARTs deiner AVRs können den 'Multi-processor Communication Mode'.
Damit geht das auch ganz gut.

MfG Spess

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand schon Erfahrung mit dem "Multi-processor Communication Mode", 
wie funktioniert das?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vereinfacht: UART mit 9 Bits statt 8, um Slaves eindeutig adressierbar 
zu machen ohne auf 8-Bit-transparenten Transfer verzeichten zu müssen. 
Ausserdem kann ein nicht adressierter Slave den Traffic in Hardware 
ignorieren bis eine neue Adresse kommt.

Gern verwendet bei RS485-Bussen. Sinnvoll vor allem bei grösseren 
Distanzen und Master/Slave-Betrieb mit exakt einem festgelegten Master.

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also die Entfernung beträgt nur einige Zentimeter, da würde ich dann I2C 
nehmen. Nur mir gehts um die Störfestigkeit und Zuverlässigkeit und 
Schnelligkeit.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Hat jemand schon Erfahrung mit dem "Multi-processor Communication Mode",
>wie funktioniert das?

Die gemeine Variante:  Ja. Steht im Datenblatt.

Etwas ausführlicher:

Jeder Slave hat eine eigene Adresse.  Die UARTs werden mit 9 Datenbits 
initialisiert. Wenn der Master etwas von einem Slave will schickt er die 
Adresse ebenfalls mit 9-Bit los und schaltet dann auf 8 Datenbits um. 
Jeder Slave überprüft die Adresse und der , der die A...karte gezogen 
hat schaltet seine UART in den 8-Bit-Mode und die Kommunikation mit dem 
Master kann losgehen. Die anderen Slaves bekommen davon nichts mit und 
können sich weiter mit sich selbst beschäftigen. Wenn die Kommunikation 
zwischen Master und Slave beendet ist schaltet der Slave wieder in den 
9-Bit-Mode und das Spiel kann von vorn beginnen.

MfG Spess

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Variante von I2C, genanne SMBus, dient bei heutigen Rechnern als 
Management-Bus (Sensoren, Lüftersteuerung, Servermanagement, ...). Nicht 
wirklich eine störarme Umgebung.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

> initialisiert. Wenn der Master etwas von einem Slave will schickt er die
> Adresse ebenfalls mit 9-Bit los und schaltet dann auf 8 Datenbits um.

Habe ich anders in Erinnerung. Er bleibt bei 9 Bits, aber bei den 
Adressen ist das oberste Bit gesetzt, bei den Daten gelöscht.

Mit Umschaltung geht schlecht, da bei asynchronem Transfer nur per 
Konvention zwischen 8- und 9-Bit Modus unterschieden werden kann. Ein 
Adressframe wäre sonst identisch mit einem Datenframe und einem 
überschüssigen Stopbit, folglich nicht unterscheidbar. Aber genau um 
diese Unterscheidung geht es.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn es "einfach" sein soll, dann mach ne "Sammel"-TX Leitung zu 
den Slaves und eine Sammel RX-Leitung zum Master (mit ca. 1k 
Widerständen vom Slave zur Sammelleitung (das Umschalten auf Tristate 
ist halt ein wenig gefrickel). Die Slaves werden einzeln adressiert. 
Dann lesen alle Slaves
die Nachrichten mit. und der angesprochene reagiert darauf. Für den 
Datenaustausch von den Slaves zum Master wird dann ein 
Zeitschlitzverfahren (Polling) genutzt. Einfach eine Pollnachricht an 
einen Slave und dem genügend Zeit zum Antworten lassen und dann den 
nächsten Slave abfragen.


Sowas geht, je nach auszutauschenden Daten, relativ einfach.

Der Multiprozessor Communication Mode ist etwas heikel, was das Löschen 
des MPCM Bits betrifft. Dass muss sehr schnell gehen, bei einer hohen 
Baudrate
(56..115k). Es wäre von Atmel eine feine Sache gewesen,, dem Teil einen 
Vergleicher für eine Adresse zu spendieren, so dass das Bit autom. 
gelöscht wird, wenn die anderen 8-bit (des 9-bit Wortes) übereinstimmen. 
Aber die wollten halt mal wieder sparen :-(

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Hast recht. Ist schon 2 Jahre her. Also bei meine obigen Ausschweifungen 
9-Bit-Moder durch gesetztes Bit8 und 8-Bit-Mode durch gelöschtes Bit8 
ersetzen.

MfG Spess

Autor: Sumynona (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also wenn es "einfach" sein soll, dann mach ne "Sammel"-TX Leitung zu
den Slaves und eine Sammel RX-Leitung zum Master (mit ca. 1k
Widerständen vom Slave zur Sammelleitung (das Umschalten auf Tristate
ist halt ein wenig gefrickel). Die Slaves werden einzeln adressiert.

Ich sehe keinen Grund, so ein Gefrickel einem etablierten Standard wie 
I²C vorzuziehen.
Wenn es "einfach" sein soll, einfach bei allen AVRs die SCL pins 
verbinden, außerdem alle SDA Pins. Zuguterletzt an beide Busleitungen 
einen 10k pullup, Fertig. Im Datenblatt nach TWI Single Master 
nachlesen, das sind dann so 10-15 Zeilen Code pro Controller, fertig.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm I2C, das ist gerade für Anfänger sicher, da es ein automatisches 
Handshake macht (wartet immer auf den langsamsten Teilnehmer).

Bei UART sind dagegen Datenverluste leicht möglich und bei SPI quasi 
unvermeidbar.
Es gibt reichlich Threads, wo Leute am SPI zwischen 2 AVRs verzweifelt 
sind.


Peter

Autor: Flachmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nimm I2C, das ist gerade für Anfänger sicher, da es ein automatisches
>Handshake macht (wartet immer auf den langsamsten Teilnehmer).

Und das kann dazu führen, daß der Bus hängen bleibt.

>Der Multiprozessor Communication Mode ist etwas heikel, was das Löschen
>des MPCM Bits betrifft.

Das kann ich nicht bestätigen. Die AVRs haben spezielle Befehle zum 
Löschen eines Bits :-)

>Die UARTs deiner AVRs können den 'Multi-processor Communication Mode'.
>Damit geht das auch ganz gut.

So isses!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das kann ich nicht bestätigen. Die AVRs haben spezielle Befehle zum
>Löschen eines Bits :-)

Geht aber nur, wenn sich der AVR nicht anderweitig mit gesperrten ISRs
aufhalten muss und einer hohen Baudrate. Ansonsten gebe ich dir recht.
Ich hab meine Implementierung mal mit Assembler gemacht, weil das was 
der C Compiler gemacht hat, nicht in den Controller gepasst hat. 
Allerdings
hatte ich dabei keine andere IRQ Quelle neben dem RXC des UART.

Autor: Flachmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Geht aber nur, wenn sich der AVR nicht anderweitig mit gesperrten ISRs
>aufhalten muss und einer hohen Baudrate.

@Matthias
Selbst bei 115kB hat der µC rund 100µs Zeit, seine Adressierung zu 
handhaben. Bei 16MHz Taktfrequenz sind das rund 1600 Anweisungen und 
somit eine kleine Ewigkeit.
Allgemein ist zu beachten, daß der Master bei einer Adressierung 
abwartet bis das TX-Register auch leer ist, bevor er das MCPM-Bit 
wegnimmt.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI

>Allgemein ist zu beachten, daß der Master bei einer Adressierung
>abwartet bis das TX-Register auch leer ist, bevor er das MCPM-Bit
>wegnimmt.

Beim Master braucht das MCPM-Bit überhaupt nicht gesetzt werden.

MfG Spess

Autor: Flachmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Beim Master braucht das MCPM-Bit überhaupt nicht gesetzt werden.

Ich meinte das 9. Bit, das die Adressierung signalisiert. Hängt auch 
immer etwas vom verwendeten µC ab. (AVR, 8051, ...)

Viel warm heute! Hoffentlich kommt der Regen auch in den Nahen Osten.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.