2 Mikrocontroller Kommunikation über I2C

Hi!

Warum, warum nur, werden Hilfegesucher hier immer so geheimnisvoll 
formuliert? Nicht einmal die verwendeten Prozessoren werden genannt. Wie 
soll man da denn helfen?

Das Protokoll beinhaltet grundsätzlich nur die Slave-Adresse, allerdings 
ist I2C Multimaster fähig, d.h. ein Master kann auch zum Slave werden.

Wenn Dein Prozessor ein Addressregister hat, dann wird er 
sinnvollerweise auch einen Interrupt generieren, wenn er seine Adresse 
empfängt. Ein Master hat erst einmal keine eigene Adresse, da er von 
Slaves nicht addressiert werden kann. Ein Slave kann normalerweise nur 
über eine zusätzliche Leitung auf sich aufmerksam machen. ( CRQ oder IRQ 
Leitung).

Daraus ergeben sich bei manchen Prozessoren aber auch 
Kombimöglichkeiten. D.h. Jeder Prozessor am Bus ist erst einmal Slave 
und hat eine eindeutige Slave-Adresse. Will einer eine Kommunikation 
starten, so schaltet er in dem Master-Modus um und addressiert einen 
Slave.
Das Protokoll ist, wenn korrekt implementiert, gegen Buskollisionen 
geschützt. D.h. es gibt im Prozessor eine Statusantwort, die den Erfolg 
oder den Grund des Misserfolges signalisiert, mind. als ein paar 
Register-Bits.

Wenn es erforderlich ist, den Master zu identifizieren, von dem ein 
Slave eine Information bekommen hat, so steht es dem geneigten 
Entwickler frei, die Daten nach seinem belieben zu gestalten.
Also z.B. [ST][ADR/W][MADR][LEN[CMD][...DATA...][SP]
ST/SP sind Start/Stop Kondition, ADR/W sind die I2C Adresse des Slave 
und das Write-Bit, MADR ist die Adresse des Masters, wenn er als Slave 
am Bus lauscht, der Rest sind dann die Daten.
Es gibt, wenn ich mich recht erinnere sogar eine Broadcast-Adresse, auf 
die alle Slaves hören sollten. Ich weiß aber nicht, ob alle Prozessoren 
diese Funktion können.

Eigentlich ist I2C super simpel aber auch super flexibel. Leider habe 
ich bei noch keinem Bus so viel Mist in Sachen Software- oder 
Hardware-Implementierung gesehen. Aber die Codeschnipsel hier sehen gut 
aus.

Gruß, Ulrich

Beispiele:
Warum schaust Du nicht mal bei den verschiedenen, oder Deinem speziellen 
CPU-Hersteller auf die Homepage? Da sollten I2C COdes in den 
ApplicationNotes herum liegen. Gerade bei Hardware-I2C Interfaces 
unterscheiden sich die Chips doch sehr. Der eine Hersteller unterstützt 
nur simple Register für Data, Address und Error-Flags, der andere 
Hersteller hat eine komplette State-Machine implementiert. Zilog und 
ATMEL haben z.B. komplette State-Machines, die bei Status-Änderung einen 
Interrupt generieren. So kann man seine Software schick in einen völlig 
passiven Treiber implementieren, der nur auf Interrupt und aktuellen 
State reagiert. Leider unterscheiden sich die einzelnen States recht 
stark voneinander. Ist also essig mit einem universellen Treiber.
Trotzdem, da Du von TWI und nicht von I2C gesprochen hast, vermute ich 
mal eine ATMEL-Lastigkeit:
http://www.atmel.com/dyn/resources/prod_documents/doc1981.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc8013.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2561.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2565.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2560.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2564.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2583.pdf

Pull-Ups:
Die Pullups eines AVR haben irgendwas um die 20k. I2C sollte aber 
zwischen 2k2 und 4k7 haben. Kommt auf die Anzahl der Devices und die 
Länge des Busses an. Nachzulesen in der I2C Specification bei NXP 
(ehemals Philips).
Warum Du das nicht selber findest weiß ich nicht, aber bitte schön:
Im Gegensatz zu Philips, hat NXP den I2C Bus sehr schön auf einer Seite 
zusammen gefasst. hier findest Du alles, was Du zum aufbau eines 
funktionierenden I2C Bus brauchst:
http://www.standardics.nxp.com/support/i2c/

Es ist wirklich schwer Dir zu helfen, wenn Du aus dem zu verwendeten 
Prozessor und dem Ziel Deiner Entwicklung solch ein Geheimnis machst. 
Daher darfst Du Dich nicht wundern, wenn hier alle mit RTFM antworten, 
oder garnicht antworten. Du beschreibst den Weg, aber weder Start noch 
Ziel.

Gruß, Ulrich