Hab jetzt den Assembler Code oben auf einem ATtiny26 als Slave impementiert und lasse ihn von einem ATMEGA16 als Master addressieren (mit der Software-Bibliothek von Peter Fleury -> das Assembler File, welches mit jedem AVR-Pin läuft auch ohne TWI support). In der Assembler Routine des Slaves (siehe oben) wird beim Warten auf den USI overflow ja in der Warteschleife immer auch überprüft, ob eine neue Start- oder eine Stop-Condition vorliegt. Im Code oben ist die Abfrage der Stop-Condition auskommentiert.

So, nun das überraschende: Der Assembler Code des Slave (siehe oben) läuft und empfängt die Adresse und das Command-Byte richtig, so lange ich nicht die Stop-Condition abfrage. Sobald ich dies aber tue, wird die I2C Kommunikation sofort abgebrochen, weil offenbar eine Stop-Condition vorliegt. Ich hab die Signale am Oszi angeschaut und da ist aber definitiv keine Stop-Condition vorhanden, erst am Ende der Übertragung.

Also hatte das wohl schon seinen Grund, dass der Autor des Codes oben die Abfrage der Stop-Condition auskommentiert hatte.

Hat jemand eine Erklärung für dieses unerwartete Verhalten? Kann das eine Störung sein, die man am Oszi nicht sieht? Oder ist das ein bekannter Fehler mit dem Stop-Condition Bit (USIPF) im USISR (USI Status Register?

Danke und Gruß, uffi.