@Fabian Ok was du meinst ist also die Sequenz:

I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 29); //Aktuelle LEDs des RP6 wieder auslesen
uint8_t result = I2CTWI_readByte(I2C_RP6_BASE_ADR);

Also Pointer im Registersatz auf das 28'te byte (Arrays beginnen bei 0) setzen und nächtes Byte (29) lesen der LEDs? Das knallt? hm...
Mal abgesehen davon, das man das 1te Byte auf Position 0 so nie adressieren kann sollte das eigentlich gehen. TWI definiert:
#define I2CTWI_SLAVE_WRITE_REGISTERS 16
#define I2CTWI_SLAVE_READ_REGISTERS 48
... also genug Platz um nicht an die Registergrenze zu klatschen... hm hm..

Kannst du mal deine setRP6LEDs funktion noch posten? Dann bau ich mir das mal hier nach.... Danke.

@SlyD
Ich glaube wir Missverstehen uns...
@RolfD: ... der Schreibpointer darf natürlich NICHT vom Master kontrolliert werden sondern muss vom Slave verwaltet werden.
Der Schreibpointer wie auch der Lesepointer MUSS vom Master kontrolliert werden damit der Slave weis welches Register gemeint ist. Da die ISR bereits die Daten direkt in die Register schreibt, nutzt ein extra "RingBuffer" (dessen Pointer wie in einer UART natürlich allein der Slave zu verwalten hätte) nichts. Mir ist der Unterschied zwischen einer Pipe und einem Array schon klar...

Du verwendest als Beispiel selbst in "case TWI_SRX_ADR_DATA_ACK:"

current_register = TWDR;

und damit setzt du den Schreib/Lesezeiger im Registerset beim folgenden Access. Das mit den Buffern habe ich garnicht verändert sondern benutze da zu 100% dein Code Der Code von RP6Base_I2CSlave.c wie auch vom alten TWI benutzt soweit ich das sehen kann auch keine unabhängigen Buffer oder Pointer für Schreiben und Lesen. Das war vielleicht mal geplant aber umgesetzt ist es in der alte TWI steuerung nicht. Vielleicht kommt das mal noch auf meine Todo Liste, mal sehen.

Würde ich (bzw. Du damals) die Daten nicht sofort in die Slaveregister schreiben, wäre ein Ringbuffer natürlich das Mittel der Wahl... keine Frage, und dann stimmt natürlich alles was Du gesagt hast. Wir reden aber beim TWI immer noch über Registeraccess und NICHT über UART/ISO-OSI

Allerdings sehe ich grade, das ich evtl. die Initialiierung von current_register = 0; in case TWI_STX_DATA_NACK: verschlampt habe... wobei als nächstes ein START kommen muss und da wird sie dann initialisiert... *seufz .. ich muss da noch mal durch...

LG Rolf