Zitat Zitat von oberallgeier Beitrag anzeigen
Hilft mir doch, danke! ... Eigentlich geht ... nur mit 100 kHz ...
Und bei den vielen Tests der letzten Tage war wohl der eine oder andere seltene Fall dabei, dass sich der Master auch bei 100 kHz aufgehängt hat - oder vom Slave aufgehängt wurde.

Codeschnippsel vom Master - Lesen I2C-Buffer
Code:
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//      Lesen vom Slave     ##### mit Änderung/Zusatz
  if(!(i2c_start(SLAVE_MoCo+I2C_WRITE))) //Slave bereit zum schreiben/lesen?
  {                                     //
// - - - - - - - - - - - - - - - - - - - - - - - - - -
//      Musterzeile vom RN Wissen
//  i2c_write(0x00); //Buffer Startadresse zum Auslesen
//  i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen
// - - - - - - - - - - - - - - - - - - - - - - - - - -
    i2cdmy = i2c_write(0x00);           // Buffer Startadresse 0 zum Auslesen
           i2c_stop();                  //
    i2cdmy = i2c_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen
////i2cdmy = i2c_rep_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen
    btst1  = i2c_read (ACK);             // 1. von 5 Bytes lesen...
Kann das an den Interrupt(s) liegen? Der Master (mega1284) hat einen Timer-Interrupt, 50µs von TIMER2 COMPA, der Slave (mega32 hat ebenfalls Timer-Interrupt, 50µs von TIMER2 COMPA, dazu werden kommen zwei extINT0 und ~1 von den Encodern, evtl. noch andere Interrupts. Der TIMER2 COMPA ist mit Vector 8 resp. 10 relativ hoch priorisiert, die extINT mit 2 bzw. 3 sehr hoch - dagegen ist der TWI mit vector 25 resp. 27 weit unten. Nun soll natürlich eine IRS immer warten, bis die laufende fertig ist - ich lasse keine nestet Interrupts zu - aber

es könnte Zeitverschiebungen in der I2C - Kommunikation geben. Macht das etwas? Könnte das der Fehler sein?