TWI Slave Receiver

Hat da echt keiner ne Ahnung davon????

anscheinend ein hoch komplexes thema.

Dann muss ich halt probieren und probieren und probieren ........

Nö. Kein hochkomplexes Thema. Aber momentan etwas anderes zu tun. Heute
abend schau ich nochmal rein.

Falls das noch hilft. Das ist meine Master-Datei. Aber ich glaub die ist
korrekt programmiert. Er steigt mir immer an dieser Stelle

if (twst != TW_MT_SLA_ACK)

aus.

Besser gesagt ist die IF-Bedingung erfüllt und er beendet die Routine
und gibt ne 2 zurück, die ich mir an Port A anzeigen lass. Ich häng
dort total.

Für Hilfe bin ich dankbar....

Eins hab ich gerade gemerkt.!

Die Adressen im Slave TWAR  und die, die der Master sendet sind
unterschiedlich. Dies ist aber unabsichtlich passiert, da ich heute den
Tag über verschiedene Adressen probiert habe und die Master.c Datei erst
gerade eben gepostet habe.. An dem liegts nicht


Gruß

Erinnert sich noch einer an mein Problem?

Ja, Steffen,

ich habe von Deinem Problem gelesen.
Und mich erinnert, wie lange ich brauchte, um das Datenblatt zum
Atmega128 in Sachen I2C verstehen, und dann noch mal, wie viele
Debugging-Läufen (Flash sei dank!) ich brauchte, bis ich es wirklich
verstanden hatte.

Ich sehe keine Chance, Probleme bei der Programmierung der
I2C-Protokolls fernschriftlich zu erörtern, zu diagnostizieren und zu
lösen.

Nehmen Sie eines der Programme, die dafür schon geschrieben
wurden,probieren Sie es aus, und falls notwendig, ändere es dann ab.

Ciao
Wolfgang Horn

Das hier hast Du schon gesehen? (sicherlich, dort hast Du dein Prob ja
schon dargestellt)
http://www.mikrocontroller.net/forum/read-1-232770.html#234328
Ich hatte auch was in C gepostet, mal sehen, ob ich das finde.

Das hatte ich auch mit TWI. Da ging nur eine Byte transmit,und danch
nix mehr. Das mit dem Flag hat den Vorteil das es wie eine Art
Handshake arbeitet.
Soweit ich mich erinnere muss eines der Flage im TWI Control Register
per code explizit loeschen sonst haeng das Protokoll immer und
ewig.

ohne oszi is das sch****

bei mir war ein problem, dass die stop bedingung zu schnell erzeugt
wurde (die flanken) und so nicht vom slave erkannt wurde... das
ergebnis war dann das gleiche wie bei dir...

Tipp: Den Controller mit einem externen Oszillator bremsen (kann
theoret. bis auf 0 heruntergefahren werden), dann kann man mit zwei
LEDs den Datenverkehr auf dem TWI sehen. So gehts auch ohne Oszi ;)

@Wolfgang

"Und mich erinnert, wie lange ich brauchte, um das Datenblatt zum
Atmega128 in Sachen I2C verstehen, und dann noch mal, wie viele
Debugging-Läufen (Flash sei dank!) ich brauchte, bis ich es wirklich
verstanden hatte."


Da kann ich Dir nur voll zustimmen.

Oft wird ja behauptet, das HW-I2C macht alles einfacher.
Aber das genaue Gegenteil ist der Fall !


Wenn sich das HW-I2C irgendwie intern verhackt, kriegt man das nicht
mit.
Man kriegt nur mit, wenn es der Meinung ist, einen Interrupt
auszulösen.
Deshalb muß man immer einen Timer nebenbei aufsetzen, um bei einem
Hänger das HW-I2C zurücksetzen zu können.
Auch muß man immer sämtliche Statuszustände auswerten, da es möglich
ist, durch eine Störung auf dem I2C in einen unerwarteten Zustand zu
kommen.

Deshalb benutze ich das HW-I2C ausschließßlich für Slave-Anwendungen.

Für Single-Master benutze ich ausschließlich meine SW-I2C-Routine, die
ist einfach, codesparend und portabel und ich weiß genau, wo sie gerade
steht, d.h. nichts kann sich verhaken.


Peter

Danke für die Tip's


ich denk ich werd den externen Oszillator runter schrauben, dass ich es
mit LED's anschauen kann


Gruß. Anders kann man's fast nicht machen


Gruß

Ps.: @Berhard Ich habe einen Atmega16. Der hat nen Port A an dem
liegt's nicht. Aber trotzdem Danke