Kommunikation zwischen zwei Atmega88

> Ich hab schon mal geschaut, da würde sich die I2C Schnittstelle
> wahrscheinlich empfählen.
Nimm SPI.

> Laufen USART und I2C parallel oder sequentiell ab?
Der UART und die TWI-Interface (SPI, I2C) sind Hardwarekomponenten, da 
läuft alles unabhängig von der Software. Nur das jeweils nächste Datum 
(= Einzahl von Daten) muß in das entsprechende Senderegister eingetragen 
werden.


BTW: kommt
> empfählen
von Pfahl?

Lothar Miller schrieb:
>> Ich hab schon mal geschaut, da würde sich die I2C Schnittstelle
>> wahrscheinlich empfählen.
> Nimm SPI.

Nimm auf keinen Fall SPI!

Die AVRs haben nur ein arme-Leute SPI ohne Sendepuffer.
D.h. Du wirst Dir die Haare raufen und trotzdem Bytes verlieren.


Das I2C ist ideal, da es ein Handshake über SCL macht, Datenverluste 
sind daher ausgeschlossen. Der Bus wartet immer auf den langsamsten 
Teilnehmer.

Das Multimaster-I2C hat beim AVR leider einen Bug, daher mach den einen 
zum Master und den anderen zum Slave.
Das I2C sollte zumindest beim Slave als Interrupt gemacht werden.


Peter

> Die AVRs haben nur ein arme-Leute SPI ohne Sendepuffer.
Schade, eigentlich  :-(
Aber das wird durch den fehlenden Empfangspuffer mehr als ausgeglichen 
;-)

Peter Dannegger schrieb:

> Das Multimaster-I2C hat beim AVR leider einen Bug, daher mach den einen
> zum Master und den anderen zum Slave.
> Das I2C sollte zumindest beim Slave als Interrupt gemacht werden.

Hast du hähere Informationen darüber? In den ATmega88-Errata findet sich 
nix darüber.

Gerade der Multimaster-Mode ist nämlich sehr interessant für Netzwerke: 
Jeder µC ist Master (Client) und kann was an einen anderen Teilnehmer 
senden, der daruch zum Slave (Server) wird um den Request zu 
beantworten.

Johann

Johann L. schrieb:
> Hast du hähere Informationen darüber? In den ATmega88-Errata findet sich
> nix darüber.

http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html


> Gerade der Multimaster-Mode ist nämlich sehr interessant für Netzwerke:

Stimmt.
Ich hatte sowas mal mit Philips-MCs aufgebaut und es hat einwandfrei 
funktioniert. Aber als Philips zu NXP wurde, hat man viele 8051-er 
abgekündigt und dann hab ich auf AVRs umgestellt.
Hat ziemlich lange gedauert, eh die Software wieder lief.


Peter

Oder nen Mega 164/324/644P nehmen, da kann man die beiden UARTs auch 
wahlweise im SPI Mode betreiben und hat dann Sende- und Empfangsbuffer. 
Sind ja auch nicht wesentlich teurer, machen aber das timing bei vielen 
Int Quellen wesentlich entspannter.

Mikki Merten schrieb:
> Oder nen Mega 164/324/644P nehmen, da kann man die beiden UARTs auch
> wahlweise im SPI Mode betreiben und hat dann Sende- und Empfangsbuffer.

Das nützt bloß nix, die UART kann kein Slave-SPI.

Und der Slave ist es ja, der genau nur einen halben SCK-Takt Zeit hat, 
um das nächste Byte in das Schieberegister zu schreiben.


Peter

Stimmt, leider können die UART nur SPI Master. Da hat man wohl nicht 
ganz bis zu Ende gedacht, selbst beim Xmega mit gibt`s beim UART nur SPI 
Master Mode.

Mikki Merten schrieb:
> selbst beim Xmega mit gibt`s beim UART nur SPI
> Master Mode.

Ich hätte jetzt gedacht, der XMEGA hat DMA?

Da sollte es doch möglich sein, im SPI-Slave z.B. 100 Byte Sendepuffer 
anzulegen und der DMA packt dann das nächste Byte sofort ins 
Senderegister, sobald ein Byte fertig ist.
D.h. der Master kann die 100 Byte ohne Delay abholen, bzw. neue 100 Byte 
zum Slave senden.

Man muß sich dann nur noch ein Protokoll ausdenken, damit der Slave 
vorher weiß, wieviel Byte er für den DMA vorbereiten muß.
Im einfachsten Fall eine konstante Paketlänge, z.B. 16 Byte.


Peter