ATMega8 i2c auslese-problem

[Stefan S. (zuckeralien)]

Hi,
ich versuche gerade mit hilfe eines ATMega8 einen Trinamic Schrittmotor 
über den I2C-Bus anzusteuern. Momentan läuft das ganze zu 
Entwicklungszwecken auf einem myAVR mySmartUSB MK2. Die ausgelesenen 
Daten werden dann per RS232 an den PC übertragen.
Der Motor benutzt zur Kommunikation einen 8Byte langen Code. Die Antwort 
ebsteht auch aus einem 8 Byte Code.
Die Übertragung des Codes funktioniert auch ohne Probleme, das Auslesen 
des Buffers funktioniert jedoch nur zufällig, also weder zuverlässig 
noch durchgehend.
Auf der Motoroplatine befindet sich ein ATMega32, falls es hilft.
Ich hab meinen Code in C angehängt.
Als I2C header benutze ich die header-Dateien von Peter Fleury per 
MAKEFILE auf den ATMega8 umgeschrieben. Die SCL-Clock beträgt 100kHz.
Ich hoffe irgendjemand findet einen hoffentlich trivialen Fehler. ^^

Danke,
Stefan

[Christopher G. (cbg)]

Du übergibts keine Speicheradresse von wo aus ausgelesen werden soll.

i2c_start(0x03);    //antwortabrufadresse des motors x-1
      for(int k=0;k<8;k++)  
      {
        antwort[k]=i2c_readAck();  // ohne stop & start wird nur die checksum gelesen lösung/adressänderung
      
      }
    i2c_stop();

[Stefan S. (zuckeralien)]

Doch, die Adresse ist 0x03 und wird beim start angegeben.
Das ist zwar eine I2C-Adresse, jedoch stellt die Motorplatine an dieser 
Adresse einen Auslese-Speicher, der extra für die Motorantwort gedacht 
ist, zur Verfügung.
Demnach muss beim lesen, wie beim schreiben übrigens auch, keine eigene 
Speicheradresse im Motorkontroller angegeben werden, bzw keine eigene 
Adresse im read-befehl genannt werden. Es gibt Motorspezifisch nur die 
beiden I2C-Adressen auf die ich zugreifen kann und die zu 
I2C-Programmierung gedacht sind.
Trotzdem schonmal danke für die Mühe :)

[Stefan S. (zuckeralien)]

Hi nochmal, ich wollte nur mitteilen, dass ich das Problem inzwischen 
gelöst habe.
Bei der library von Peter Fleury wird im "i2c_readAck()"-Befehl das TWEA 
auf 1 gesetzt um ein neues zu erwarten.
Im "i2c_stop()"-Befehl wird dieses jedoch nicht mehr gelöscht. Demnach 
gibt es eine wartende i2c-Verbindung während dieselbe Verbindung 
getrennt werden soll und der µc hängt sich auf.
Es gibt nurn 2 Möglichkeiten dem zu entgehen. Entweder man fängt das 
letzte Byte der Übertragung mit dem "i2c-readNak()"-Befehl ab, oder man 
setzt im Headerfile im "i2c_stop()"-Befehl den TWEA auf 0 (noch nicht 
über längeren Zeitraum getestet).
Vielleicht hilft das jemandem mit einem ähnlichen Problem.

Stefan

[Christopher G. (cbg)]

Wenn ich mich nicht täusche, dann soll man ja auch als Master auf das 
letzte Byte mit NACK antworten.