Sorry, dass das gleich so viel war... wenn das so gehen würde wie gedacht hätt ich niemanden "genervt"

zu deinen Fragen:

1) Ja, ich sende via Serieller Com Port -> I²C Umetzer über die SCL/SDA Leitungen Daten an den Atmel Prozessor (hier mega 16.
Allerdings derzeit nur mit dem PC, weil ich da "spielen" kann und sich auch mal schnell was ändern lässt

2) Das I²C-Adressierungsformat lautet folgendermassen (8Bit):

- die ersten 7 Bit sind die Adresse des Chips, also von 0-127
- das letzte Bit (8tes) ist die Schreib(0)/Lese(1) Info

Damit wird 's127w'="Sklave mit ID 127, BEschreiben" zu: 1111.1110

- das ganze wirde gefolgt von einem SCL-Impuls des Masters, bei dem der Sklave die SDA-Leitung auf Masse ziehen muss -> ACKnowledged.

An den Oszi-Aufnahmen sieht man sehr schön, wie der Sklave gleich nach dem 8. SCL-Impuls die SDA-Leitung runterzieht und so lange GÜLTIG hält, wie der Master den 9. SCL-Impuls anliegen hat, damit der das ACK auch sicher empfangen kann (das Read Data Feld im Terminal-Prog zeigt dann ja auch das ACK jeweils an ).
Dann lässt der Sklave die SDA-Leitung wieder los und der Master macht entweder mit Daten weiter oder aber zum Schluss das STOP.

Ich hab mir die Zeitverläufe auch genauer angesehen (hatte Verdacht, dass der Sklave es nicht richtig macht und ungültige SDA-Werte verursacht ), aber dem ist nicht so.. ist halt nur recht fix der Kerl.
Daran sollte es jedenfalls nicht liegen, dass bei der Datenübertragung in TWDR nur die letzten 7Bit vom gewünschten vollen Byte stehen.

Irgendwie sieht das so aus, als ob mit dem 9. SCL-Impuls die Bits in TWDR noch eins weiter geschoben werden...

Muss morgen mal nen Test mit Nicht-ACK machen, vielleicht steht dann zufällig eine 1 an der letzten Stelle in TWDR.. hm..

Grüße
0tes_Gesetz