I2C-Kommunikation läuft nicht über längere Zeit (Atmega644PA)

[oberallgeier]

... Kommunikation ... läuft über I2C ... nur etwa 0-30sec, danach funktioniert der I2C-Part nicht mehr. Doch nun ein wenig genauer:
...

...
    i2c_start(MOTORA+I2C_WRITE);     //MOTORA: adress of motor A
    i2c_write(motora);
    i2c_stop();
        i2c_start(MOTORB+I2C_WRITE);     //MOTORB: adress of motor B
    i2c_write(motorb);
    i2c_stop();
}

Hallo Adrian,

willkommen im Forum.

Leider hast Du den I²C-Takt in Deiner Lösung nicht genannt. Aber das ist wohl nicht so wichtig. Ich kenne ähnliche Fehler die ich so lange hatte, bis ich mich mal mit dem I²C-Timing beschäftigt hatte. Der Code, den ich oben blau markiert hatte, scheint mir verdächtig.

Nach dem Stop braucht das System ne Weile bis per I²C wieder geschrieben -- oder gelesen -- werden kann. Wenn man das sofort angeht KANN es funktionieren, muss aber nicht. Und wenns nicht sofort klappt ,dann kann die Kommunikation hängen bleiben. Daher hatte ich bei i2c_start nach einem i2c_stop -- neee, genaugenommen jetzt immer -- eine Abfrage eingefügt, ob der Bus überhaupt bereit ist. Beispiel hier (klick).

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//      Lesen (read back) vom Slave   ... mit der Routine aus fleury´s lib
  i2c_start_wait(SLAVE_MoCo+I2C_WRITE); // set device address and write mode
  i2c_write( laddr );           // write address = laddr, das angepeilte Byte
        i2c_stop();             //

  while ((i2c_rep_start(SLAVE_MoCo+I2C_READ))) {}// Slave bereit zum Lesen?
//i2c_rep_start(SLAVE_MoCo+I2C_READ);   // set device address and read mode
  ipwm12  = i2c_readAck();      // Bytes lesen... ab laddr = 0x33/51
  soll12  = i2c_readAck();      //
  ipwm34  = i2c_readAck();      // 
  soll34  = i2c_readNak();      // letztes Byte lesen, NAK
        i2c_stop();             //

Das Zauberwort heißt bei mir "while" - und dann wartet der Befehl ab, bis der Bus frei ist. Und schon liefs (bei mir). Nun könnte ich Dir das viele Zeugs in den Herstellerschriften zum TWI/I²C bzw. dessen Timing schreiben - kannst Du in den entsprechenden Schriften nachlesen. Vorschlag: probiers mit "while" - vielleicht klappts und dann kannst Du Dir vielleicht das Lesen sparen. Übrigens könnte man bei erfolglosem Warten noch ne Fehlermeldung einbauen. Wenn man möchte.

Viel Erfolg.

[addi241]

Ja, die Frequenz habe ich vergessen (würden aber in der datei twimaster.c stehen), sie liegt bei 400kHz. Aber wie gesagt, das Problem tritt frequenzunabhängig auf.

Leider funktioniert dein Lösungsansatz bei mir nicht. Ich glaube auch zu wissen warum: nach i2c_stop() wird ja trotzdem im Endeffekt i2c_start() (über den Umweg while() und i2c_rep_start() ) direkt aufgerufen und kann deswegen dort hängen. Ich habe es auch mit kurzen delays zwischen jeder i2c-Operation versucht, brachte recht wenig.

Um mal zu sehen, wo genau das Programm stehen bleibt, habe ich jeweils vor den einzelnen Funktionen eine Led angeschalten, am Ende wieder ausgeschalten. Abwechselnd blieb es bei i2c_start() und i2c_readAck() an.
D.h. es kann nur in folgender Schleife hängen: while(!(TWCR & (1<<TWINT))); (je nachdem was ihr für eine lib benützt, ich verwende die von fleury)

Um diese zu verlassen muss TWINT == 1 sein. Deswegen habe ich in der ISR, statt wie oben das TWI zu reseten und die Motoren neu ansteuern einfach TWCR |= (1<<TWINT); eingegeben. Sozusagen die brachiale Lösung dass das Programm weiterläuft. Und es scheint zu funktionieren!

Was es allerdings genau bewirkt und welche Auswirkungen es genau hat kann ich leider nicht sagen, dazu fehlt mir das Wissen (und die Zeit mich dazu ordentlich einzulesen^^)

Zwar eigentlich keine schöne Lösung und es packt das Problem nicht an der Wurzel, aber es läuft... Es sei denn ich hatte in der letzten halben Stunde einfach nur Glück und es lief auch so Sobald ich es mal längere Zeit laufen lassen kann melde ich mich wieder!

[addi241]

Ich hatte wohl doch nur Glück.
Das setzten von TWCR |= (1<<TWINT); in der ISR bringt ein paar mal etwas und das Programm läuft weiter (eine LED an der Stelle, wo ich TWCR |= (1<<TWINT) setze, schaltet um) aber nur für weitere 10 Sekunden... danach bleibt das Programm wieder stehen...
SDA und SCL sind beide High! (dauerhaft)

Da ich mir nun beim besten Willen nicht vorstellen kann, wo das Problem nun liegt werde ich für die Ansteuerung auf PPM o.ä. umsteigen.

Es ist etwas komisch, da das ansprechen der Regler ja bereits funktioniert, ich kann nacheinander z.B. immer größere Werte übergeben, sodass der Motor hochfährt. Nur zusammen mit dem MPU6050 nicht. Aber ich kann wiederum von diesem Sensor die Werte auf einem LCD-Display ausgeben lassen.

Es wäre natürlich weiterhin praktisch wenn jemand eine Lösung hätte I2C zu resetten bzw. wenn die ISR ausgeführt wird, die Schleife zu unterbrechen und an anderen bestimmen Stelle weiterzumachen.

mfg

[oberallgeier]

... wenn jemand eine Lösung hätte I2C zu resetten ...

Versuch mal die Methode von Klebwax (klick hier). Habs (noch) nicht getestet - derzeit ne andere Baustelle.

[addi241]

Hat leider auch nicht funktioniert Mittlerweile glaube ich, dass der Sensor die ganzen Probleme macht und den Bus blockiert.
Habe es jetzt so gelöst, dass ich den Sensor mit Hardware-I2C auslese und die 4 Motorregler mit Software-I2C ansteuere (getrennte Leitungen). Funktioniert bestens!

[fulltime]

Kein Plan ob dass hilfreich ist, aber solange ds TWINT-Bit gesetzt ist kann keine Altion auf den TWI gestartet werden. TWINT wird ja nach jeder Aktion am I2C gesetzt und anschließend gelöscht werden. Vielleicht wird es bei deinem Problem irgendwann nicht gelöscht und haltet somit den TWI auf.

Bin selbst leider kein Mikrokontroller-Guru, beschäftige mich erst seit einigen Monaten intensiv damit. Wird wohl zu meinem neuen Hobby ^^

Mfg
fulltime