ATMega162 mit ATMega8 mit welcher Schnittstelle verbinden

Hallo

ich suche nach einer passender Schnittstelle wo ich den ATMega162 und einen ATMega8 verbinden kann.
Nach meinen Wissen hat der M162 ja leider kein I²C Bus.

Mir ist die RS232 Schnittstelle eingefallen. können sich die Megas komplett unterhalten?? ist ein möglichst kompakter Code möglich??

Das Nächste Problem ist der Code. Der Mega162 ist fast ausgelastet und der Mega8 hat nicht mehr viel Speicherplatz. Also ein kliener Code wird benötigt.

Ich hoffe ihr könnt mir helfen welche Schnittstelle/Bus ich nehmen sollte

MFG Max

Moin,

da beide scheinbar ein USART haben, wäre das sogar empfehlenswert. Der Code kann winzig sein (3 Befehle zum einstellen des Moduls, danach jeweils 2 Befehle als Unterprogramm zum Senden von Daten), die Geschwindigkeit müsste reichen, und vor allem gibt er dir Interrupts aus, bei ner neuen Mitteilung und er hat nen eigenen Hardware-Buffer, zwar nur ein Byte, aber besser als nichts. Einfach RX1 mit TX2 und TX1 mit RX2 verbinden, gut ist.
Ne Implementierung von I2C oder sowas wäre auch möglich, aber du bräuchtest am Besten einen Pin mit Interruptfähigkeit frei, und natürlich ein paar Zeilen mehr Code, um das in Software zu machen.
Wenn du nur 2 Partner hast, spricht nichts gegen RS232.

Hi,

USART hört sich gut an. Wie laüft das dann mit dem Interrupt?. Es nämlich dann von vorteil weil ich dann keine so große while Schleife laufen lassen muss um zu schauen ob eine variable rübergekommen ist.

Ich will das ganze so gestallten das es modular wird.
Also erst stelle den controller fertig und dann wenn mir später noch funktionen/geräte ansteuerungen einfallen, das ich den einfach mit an den Bus hänge.

Gibt es bei USART auch addressen??? könntest du einen Beispielcode geben (am besten in Assembler)???

MFG Max

Äh USART ist ungleich RS232!

USART ist nur die Universelle Hardware im Controller. Der kann halt serielle Daten verschicken. Dabei nimmt er sich aber den Standard RS232, also z.B. 1 Startbit, 8 Datenbits, 1 Stopbit, keine Parität und 9600Baud.
Grundsätzlich hat RS232 kein Adressen und ist auch nicht als Mehr-Teilnehmer-Bus ausgelegt. Dh. du hast auch keinen Bus, wo du später noch 3 andere Geräte dranhängen kannst, dafür muss dann schon I2C oder SPI her (wobei SPI 2 Leitungen +1 für jeden Slave braucht).

Das USART einzurichten ist recht einfach und in den Datenblättern vom Controller bei Atmel sehr gut beschrieben. Dort ist Beispielcode für Assembler und C. Wichtig ist halt: richtige Baudrate wählen, muss bei beiden gleich sein. Nen netten Rechner hab ich hier gefunden http://www.gjlay.de/helferlein/avr-uart-rechner.html
Danach läuft es eigentlich immer so ab, wie im Datenblatt.
z.B. für die Initialisierung

Code:

---

USART_Transmit:
; Wait for empty transmit buffer
sbis UCSRnA,UDREn
rjmp USART_Transmit
; Put data (r16) into buffer, sends the data
out UDRn,r16
ret

---

Und für ein Sendung

Code:

---

USART_Transmit:
; Wait for empty transmit buffer
sbis UCSRnA,UDREn
rjmp USART_Transmit
; Put data (r16) into buffer, sends the data
out UDRn,r16
ret

---

Über die im Datenblatt beschriebenen Flags kannst du dann einen Interrupt auslösen lassen, wenn der SendeBuffer leer ist und wenn die Sendung abgeschickt wurde, beim Empfangen kannst du anzeigen lassen, ob ne neue Nachricht da ist oder ob Fehler aufgetaucht sind.
Wie das genau geht, ist sehr gut im Datenblatt beschrieben.

Zitat:

---

Zitat von the_Ghost666

Äh USART ist ungleich RS232!

Code:

---

USART_Transmit:
; Wait for empty transmit buffer
sbis UCSRnA,UDREn
rjmp USART_Transmit
; Put data (r16) into buffer, sends the data
out UDRn,r16
ret

---

Und für ein Sendung

Code:

---

USART_Transmit:
; Wait for empty transmit buffer
sbis UCSRnA,UDREn
rjmp USART_Transmit
; Put data (r16) into buffer, sends the data
out UDRn,r16
ret

---

---

Ah danke hat mich sehr weitergeholfen
ich habe ja auch nicht gesagt das RS232=USART

Wie läuft das ganze jetzt dann mit den Addressen oder gibts jetzt beim USART keine???.
(sonst irgendwie nicht durchblcik)

MFG

Neinein, beim USART gibt es keine Adressen. Dafür haben die meisten Megas halt ihr TWI-Interface. Du kannst natürlich was überlegen, indem du dir einen eigenes Protokoll nimmst. Z.B. indem du 3 Byte auf die Leitung legst, Adresse, Kommando, Daten. Dann muss die Interruptroutine feststellen, ob es ihre Adresse ist und dann den Rest verarbeiten.
Unterscheidbar wäre das dann, indem du von Adresse, Kommando und Daten je 1-2 Bit aufsparst, als Markierung. Also Adressen von 0-127, oberstes Bit auf 1 gibt an, dass es ne Adresse ist, oberstes Bit auf Null gibt an, dass es n Befehlscode ist. Daten sind nur gültig, wenn es das dritte Byte ist, was gesendet wird. Sollte nicht schwer sein sich sowas zu überlegen. Ich glaube es gibt noch n Bus in der Messtechnik, wo Geräte damit ferngesteuert werden können (Multimeter, Spannungsquellen, Oszis..). Dabei wird das UART Signal in das Gerät geführt, und genau so wieder an das Nächste weiter geschickt. D.h. das Paket geht durch alle Hände, bis es seinen Empfänger gefunden hat. USART mit mehreren hat halt immer n recht großen Overhead, weil meist Steuerzeichen drin sind. Aber eigentlich könntest du das auch wie n I2C machen, nur ohne Acknoledge, Start und Stop Condition. Die müsste man mit speziellen Zeichenfolgen bauen.

Wenn du nen Bus willst, reicht da echt nichtmehr der Platz um Software-I2C auf dem einen zu Implementieren?

hallo,

Zitat:

---

Zitat von the_Ghost666

Ich glaube es gibt noch n Bus in der Messtechnik, wo Geräte damit ferngesteuert werden können (Multimeter, Spannungsquellen, Oszis..). Dabei wird das UART Signal in das Gerät geführt, und genau so wieder an das Nächste weiter geschickt. D.h. das Paket geht durch alle Hände, bis es seinen Empfänger gefunden hat.

---

das prinzip nennt sich daisy chain
http://de.wikipedia.org/wiki/Daisy_chain

lg

hallo,

ein eigenes Protokoll aus USART Basis?
Wenn wäre das ausdenken nicht schwer, sowas habe ich schon mehrfah in anderen Themenbereichen gemacht, allerdings nur für das Senden.
Für mich wäre dann das größere Problem die Empfangsroutine zu Programmieren.
Man könnte das Protokoll ja eigentlich nur eif einen Pin laufen lassen, also alle 2-4 Bytes auf einen Pin nacheinander anlegen ( oder hast du das soae gemeint??)

Vom Code her ist für meinetwegen Software I2C noch platz. Blos der M162 ist schon reltiv mit Rechenleistung ausgelastet. Aber leider weiss ich noch nicht wie Software I2C in Assembler geht. (hatte vorher nur Bascom)

Ansonsten war dein Beitrag wieder mal sehr hilfreich.

Im Pirinzip ist es dann eine Daisy Chain, wenn ich es so wie oben mache.

MFg