I²C Master m328 kann Slave m328 nicht lesen

[oberallgeier]

Peinlich. Meine Fehlersuche und Sachstudie zum Thema hilft mir seit Tagen (Nächten) nicht weiter. Bisherige Erfahrungen mit I²C auf Atmelcontrollern: schreiben und lesen eines Beschleunigungsaufnehmers, Code von Sternthaler mit leichten Abwandlungen.

Aktuell:
Kurzfassung: Daten von einem Master (mega328/8MHz int. Osz) können auf einen Slave (mega328/20MHz Quarz) übertragen werden. Lesen der Daten vom Master geht nicht - Programm hängt.

AV RStudio4 4.18 Build 700, Master-Slave-Kopplung nach RN/Wissen (siehe hier - klick) mit den dort präsentierten Codes bzw. PFleury-Lib.
Master :
- Der Code für Master wurde geringfügig abgewandelt: Sende-/Leseschleife durch while(1) mit eingebauter Tastenabfage. Wenn Taste gedrückt werden drei andere Bytes definiert wie ohne Tastendruck.
- Die Slaveadresse ist hex70.
- Eigene, bewährte UART-Routine
Slave :
- Der Code wurde bis auf die Slaveadresse übernommen.

Ergebnis:
- Schreiben der beiden Datensätze mit/ohne Taste geht einwandfrei, siehe Ausgabebeispiel - RS232 vom Slave
- Die Schleifendurchläufe des Masters werden durch eine getoggelte LED signalisiert.
- Lesen des Masters der geschriebenen Daten geht nicht, das Programm bleibt nach der Abfrage "Slave bereit zum Lesen" hängen - belegt durch LEDsignal am Master (toggelt nicht), siehe dazu Codeabschnitt.

  i2c_init();                   // init I2C interface
while (1)
{                               // Schleife mit verschiedenen Ausgaben
  if (!(PIND & (1 << PIND2)))   // Taste bringt GND auf PD2?
  {                             //
    byte1 = 42;
    byte2 = 43;
    byte3 = 44;
  }
  else                          //
  {                             //
    byte1 = 56;
    byte2 = 57;
    byte3 = 58;
  }                             // Ende if (!(PIND & (1 << PIND2)))
                                //
  if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE))) //Slave bereit zum schreiben?
  {
    i2c_write(0x00);            // Buffer Startadresse setzen  
    i2c_write(byte1);           // Drei Bytes schreiben...
    i2c_write(byte2); 
    i2c_write(byte3); 
    i2c_stop();                 // Zugriff beenden
  }                             //
  else
  {
  /* Hier könnte eine Fehlermeldung ausgegeben werden... */
  }
/*
  waitms ( 200);                 // Warten vor Lesen ?? 30Nov2011, 2300
  if(!(i2c_start(SLAVE_ADRESSE+I2C_WRITE)))     //Slave bereit zum lesen?
  {                             //
                                //
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   ToggleBit(PORTD, 5);           // LED auf PC2 toggeln
// ###>>> 02 Dez 2011, 0045: Programm kommt bis hieher, dann bleibt es stehen
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                //
    i2c_write(0x00);            //Buffer Startadresse zum Auslesen
    i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen
                                //
    byte1= i2c_readAck();       // Bytes lesen...
    byte2= i2c_readAck();       
    byte3= i2c_readNak();       // letztes Byte lesen, darum kein ACK
    i2c_stop();                 // Zugriff beenden
  }                             
*/
//else                          
//{                             
///* Hier könnte eine Fehlermeldung ausgegeben werden... */
//}                             

Ausgabebeispiel:


Frage:
Wo steckt der Fehler??
Danke im Voraus für eure Hilfe.

[PicNick]

Wirklich steckenbleiben kann er ja eigentlich nur bei

    i2c_write(0x00);            // Da kann man hängen bleiben, wenn der Slave mit "clock-stretch" den master auf das ACK warten lässt
    i2c_rep_start(SLAVE_ADRESSE+I2C_READ); // da bleibt man hängen, wenn der Slave den Bus nicht freigibt.

Ich weiss nicht, ob bei der Lib ein "Timeout" für diese zustände eingebaut ist. (offenbar nicht)
Baue zwischen den Befehlen erstmal irgendeine LED-Flunzlerei ein, damit du siehst, ob er bei "write" oder "rep_start" hängen bleibt.

EDIT: bei HW-TWI sollte so ein ewiger CLock-stretch eigentlich nicht möglich sein. d.h. der Verdacht richtete sich auf den Rep_Start.

[oberallgeier]

Erstmal danke, ich geh in ner Weile drüber (aktuell total lahme Hände/Arme, zuviel Kletterhalle).

[PicNick]

Du weisst ja, wenn's hinten weh' tut, soll man vorn' aufhören

[oberallgeier]

... ob ... ein "Timeout" ... eingebaut ist. (offenbar nicht) ...

Offenbar nicht. Ist nicht zu sehen. Und ich habe meine LED/Leuchtfeuer-Kommunikation weiter ausgebaut:

... Baue ... irgendeine LED-Flunzlerei ein ... Verdacht ... auf den Rep_Start.

Damit ist der "i2c_rep_start" als Missetäter überführt. Also drei i2c_readAck/Nak();// Bytes lesen haben das Koma verhindert. Jetzt schaue ich mal mit nem zusätzlichen USART nach was da gelesen wird (der gibt im Moment nur Schrott aus - seltsam.

Danke jedenfalls für den guten Tip, den rep_start zu verdächigen - das war ein Treffer.


[OT]"... wenn's hinten weh' tut, soll man ..." Ich klettere eigentlich immer Gesicht zur Wand . . . . [/OT]

[oberallgeier]

So. Es stimmt. Drei "i2c_readAck/Nak();// Bytes lesen" statt des "i2c_rep_start" haben das Koma verhindert.

Zum Glück habe ich mir über UART vom Master die nun gelesenen Bytes ausgeben lassen. Baaahhhh - die waren (nur) die übermittelten Adressen(offsets) des zu lesenden Bytes. Also noch schnell ein "i2c_start(SLAVE_ADRESSE+I2C_READ)"-Commando, aber nicht das "i2c_rep_start(SLAVE_ADRESSE+I2C_READ)"! eingefügt - und schon steht wieder alles.

Aktuell gilt u.A. dies:

Modul "master", defines + includes vor "main" enthält u.a.
 #define SLAVE_ADRESSE 0x70
Modul "i2cmasterl.h" (l=lokal) enthält u.a.
/** defines the data direction (reading from I2C device) in i2c_start(),i2c_rep_start() */
#define I2C_READ    1
/** defines the data direction (writing to I2C device) in i2c_start(),i2c_rep_start() */
#define I2C_WRITE   0
 

Fazit: I2C-Slave-Schreiben geht, I2C-Slave-lesen geht nicht ... und bin so klug als wie zuvor.

[oberallgeier]

Sooo, nun gehts.

Danke Robert für den Hinweis auf den möglichen Fehler. Mittlerweile habe ich den Code für den Test des Master geringfügig ergänzt und das Auslesen, auch mit "i2c_rep_start" funktioniert jetzt klaglos und sicher. Ich dagegen bin nicht sicher, dass der Code "... Testprogramm für den Master..." aus dem RNWiki bei anderen Anwendungen funktioniert (steht ja extra dort "... getestet ..." - allerdings heißt es nicht, dass der auch läuft *ggg*) - wie geschildert gings bei mir nicht. Ich meine trotz meiner bescheidenen Kenntnisse, dass der Codeschnippsel gerade für Testzwecke verbesserungswürdig ist.

Trotzdem danke Robert.

[Chypsylon]

Ich hatte heute das gleiche Problem (schreiben geht -lesen nicht), und auch in anderen Threads wird berichtet das lesen nicht funktioniert. Ich verwende jetzt die Library von http://www.jtronics.de/avr-projekte/.../twi-slave-avr , die auch auf Anhieb funktioniert hat und vom Aufbau relativ gleich ist...