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
Gast
#1337213
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 ;-)
Gast
#1337214
Aus einer Leiterplatte wuerde man SPI nehmen.
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.
Gast
#1337244
Hi Die UARTs deiner AVRs können den 'Multi-processor Communication Mode'. Damit geht das auch ganz gut. MfG Spess
Hat jemand schon Erfahrung mit dem "Multi-processor Communication Mode", wie funktioniert das?
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.
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.
Gast
#1337261
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
Eine Variante von I2C, genanne SMBus, dient bei heutigen Rechnern als Management-Bus (Sensoren, Lüftersteuerung, Servermanagement, ...). Nicht wirklich eine störarme Umgebung.
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.
Gast
#1337287
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 :-(
Gast
#1337290
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
Gast
#1337794
> 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.
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
Gast
#1337852
>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!
Gast
#1337994
>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.
Gast
#1338033
>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.
Gast
#1338038
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
Gast
#1338042
>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
Bitte melde dich an, um einen Beitrag zu schreiben.