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
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 ;-)
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.
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.
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.
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 :-(
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
> 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
>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!
>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.
>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.
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
>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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.