Forum: Mikrocontroller und Digitale Elektronik TWI Slave Receiver


von Steffen (Gast)


Angehängte Dateien:

Lesenswert?

Hallo!

versuche verzweifelt einen Slave Receiver in WINAVR-C zu programmieren.
Wenn der Master eine Startbedingung sendet springt der Slave in die ISR.
Wenn mein Master dann versucht die Slave-Adresse +Write zu senden,
sollte der Slave ja ein ACK zurückgeben. Joch steigt an dieser Stelle
mein Masterprogramm aus bzw. die TWSR enthält nicht den Wert 0x18 wie
gefordert. Leider hab ich kein oszi um mir den Signalverlauf
anzuschauen. Kann mal einer ein Blick in den Code werfen????

Code ist für einen Amtega16 mit 8MHz

Gruß und Danke im Voraus

von Steffen (Gast)


Lesenswert?

Hat da echt keiner ne Ahnung davon????

von Peter D. (peda)


Lesenswert?

Also los I2C-Experten.

Ich weiß, ihr habt kein Privatleben und sitzt 24h am PC.

Jetzt habt ihr schon 58 Minuten Zeit gehabt, setzt euch gefälligst auf
den Hosenboden und macht hinne !


Peter

von steffen (Gast)


Lesenswert?

anscheinend ein hoch komplexes thema.

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

von thkais (Gast)


Lesenswert?

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

von Steffen (Gast)


Angehängte Dateien:

Lesenswert?

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....

von Steffen (Gast)


Lesenswert?

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ß

von Steffen (Gast)


Lesenswert?

Erinnert sich noch einer an mein Problem?

von Wolfgang Horn (Gast)


Lesenswert?

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

von Axel R. (Gast)


Lesenswert?

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.

von Holger (Gast)


Lesenswert?

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.

von Bernhard S. (bernhard)


Lesenswert?

...ist zwar in Assembler geschrieben, aber vielleicht hilft's
weiter...

http://www.mikrocontroller.net/forum/read-4-246060.html


Bernhard

von Marcus (Gast)


Lesenswert?

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...

von thkais (Gast)


Lesenswert?

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 ;)

von Bernhard S. (bernhard)


Lesenswert?

@Steffen

Was mir gerade bei Deinem C-Code aufgefallen ist:

DDRA=0xFF;
PORTA=0x00;

Einen PortA gibt es bei einem ATmega8 nicht.

Aber, das wird nicht die Ursache Deines Problems sein.

Bernhard

von peter dannegger (Gast)


Lesenswert?

@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

von Steffen (Gast)


Lesenswert?

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

von Bernhard S. (bernhard)


Lesenswert?

@Steffen


Wenn Du das TWBR und TWSR - Register auf einen hohen Wert setzt, dann
arbeitest Du mit SCL im Hz-Bereich und die LEDs flimmern nicht so
hecktisch.


Bernhard

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.