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


von Mathias O. (m-obi)


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

von Sumynona (Gast)


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 ;-)

von ::: (Gast)


Lesenswert?

Aus einer Leiterplatte wuerde man SPI nehmen.

von (prx) A. K. (prx)


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.

von spess53 (Gast)


Lesenswert?

Hi

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

MfG Spess

von Mathias O. (m-obi)


Lesenswert?

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

von (prx) A. K. (prx)


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.

von Mathias O. (m-obi)


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.

von spess53 (Gast)


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

von (prx) A. K. (prx)


Lesenswert?

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

von (prx) A. K. (prx)


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.

von Matthias (Gast)


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 :-(

von spess53 (Gast)


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

von Sumynona (Gast)


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.

von Peter D. (peda)


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

von Flachmann (Gast)


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!

von Matthias (Gast)


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.

von Flachmann (Gast)


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.

von spess53 (Gast)


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

von Flachmann (Gast)


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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.