mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik TWI Slave Receiver


Autor: Steffen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat da echt keiner ne Ahnung davon????

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
anscheinend ein hoch komplexes thema.

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

Autor: thkais (Gast)
Datum:

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

Autor: Steffen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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....

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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ß

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erinnert sich noch einer an mein Problem?

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Axel R. (axelr) Flattr this
Datum:

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

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ist zwar in Assembler geschrieben, aber vielleicht hilft's
weiter...

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


Bernhard

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ;)

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.