Ich mache mit PICs rum und kenne mich daher mit AVR nicht so aus. Ich hab mir daher das Datenblatt von Atmel mal angesehen. Dafür hat Atmel weder einen Preis für Didaktik noch für Chipdesign verdient. Jetzt kann ich verstehen, weswegen viele I2C für kompliziert halten.

Aber in deinem geposteten Code findet sich das wieder, was ich oben geschrieben habe. In i2c_start() wird alles nötige gemacht.

also:
Code:
if(i2c_start(Adresse und Write) == 0) {
        Chip ist fertig mit der Messung und bereit zum Lesen
	i2c_write(Registeradresse)
	i2c_stop()
	if(i2c_start(Adresse und Read) != 0) {
		eben war der Chip doch noch bereit, was soll das jetzt? Selbstzerstörung einleiten??
	}
	ErsteByte = i2c_readAck()
	ZweiteByte = i2c_readAck()
        .  .  .  .
	LetzteByte = i2c_readNak()
	i2c_stop()
} else {
	Chip noch nicht bereit, mach erstmal was anderes und versuchs später noch einmal
}
So sollte es gehen.

Und zu deinem Problem mit TW_STATUS: wenn es nicht definiert wäre, würde der Compiler maulen. In dem meisten IDEs kann man sich irgendwie die Macroexpansion anzeigen lassen, da findet man dann auch wo das steht. Aber man kann da natürlich auch TWSR schreiben, das ist kein Experiment sondern aus dem Datenblatt. TW_STATUS hat sich auch nur jemand ausgedacht (weil es sich schöner liest?).

etwas OT:
Das ganze ist halt ein muchtiges Design. Das eigentlich Statuswort steht in den 5 oberen Bits von TWSR, kann man so machen, ist halt die Hardware. Aber in der Status-Codeliste immer die unteren Bits mitzuschleppen ist Krampf.

Eigentlich müßte man schreiben:

TwiStatus = TWSR >> 3

Und dann kann man mit if oder case die Auswertung auf TwiStatus machen.

Aber trotzdem schaffen seine 20 MHz dann schon 26 1-Takt Befehle!
Da Start und Stop in Hardware erzeugt werden und im Code darauf gewartet wird, das sich der Status ändert, spielt das keine Rolle.

MfG Klebwax