Forum: Mikrocontroller und Digitale Elektronik Unterschied TWI ATMEGA 8 und 16


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jenny (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich komme bei einem Projekt nicht weiter. Ich nutze einen Raspi (Master) 
als Bedienoberfläche und habe über den I²C Bus mehrere Schaltungen mit 
ATMEGA angeschlossen, die dann die gewünschten Aktionen auslösen und 
Rückmeldungen geben. Bei den Schaltungen mit ATMAGA 8 funktioniert das 
auch wunderbar. Ich habe aber auch eine Schaltung mit einem ATMEGA 16 
und da gibt es Probleme.

Die Software für die Übertragung habe ich 1:1 von den ATMEGA 8 
übernommen. Und teilweise muss sie auch funktionieren, denn wenn ich 
mich die Busteilnehmer am Raspi anzeigen lasse, wird der ATMEGA 16 auch 
angezeigt. Sobald ich aber Daten abrufen will, gibt es Probleme. Ich 
gehe davon aus, dass es daran liegt, dass die Software  ja für ATMEGA 8 
geschrieben wurde.

Gestern habe ich lange damit zugebracht, in den Datenblättern den 
Unterschied zwischen den TWI Schnittstellen den 8er und 16er zu finden. 
Allerdings habe ich keinen gefunden. Vielleicht liegt das auch an meinen 
beschränkten Englischkenntnissen.

Meine Frage ist also. Gibt es einen Unterschied zwischen den 
Schnittstellen, den ich übersehen haben könnte und wenn ja, welchen?

von Patrick J. (ho-bit-hun-ter)


Bewertung
0 lesenswert
nicht lesenswert
Hi

Hast Du in den Datenblättern geschaut, daß sämtliche benutzte Register 
identisch aufgebaut sind?
Also, daß Du die Steuer-Bits auch beim 16er in das dafür vorgesehene 
Register schreibst und nicht 'irgendwo hin'.

Weit hergeholt, aber gestern hatten wir hier eine verknotung bei Timern 
(aber offensichtlich, da Register zum Timer 1 mit Bits vom Timer 0 
geladen wurden - funktionierte aber wegen dem gleichen Stellenwert, der 
Fehler lag noch wo Anders)

MfG

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Im Compiler das richtige Target eingestellt?
Beim M16 ist die Vektortabelle anders.

von Jenny L. (jenny_lo)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Registernamen verglichen und keine Unterschiede gefunden. 
Also wenn ich keine Tomaten auf den Augen habe, sind sie identisch.

Das Traget ist auch richtig eingestellt. Eclipse schimpft auch nicht.

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Such mal nach:

raspberry i2c clock stretching

von Jenny L. (jenny_lo)


Bewertung
0 lesenswert
nicht lesenswert
Müsste der nicht unabhängig vom Controller des Slaves auftreten? Die 
Slaves mit dem M8 bereiten keine Probleme.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
> Ich habe die Registernamen verglichen und keine Unterschiede gefunden.

Tja, dann ist nun der Zeitpunkt gekommen, wo du uns das Programm zeigen 
solltest.

> wenn ich mich die Busteilnehmer am Raspi anzeigen lasse, wird der
> ATMEGA 16 auch angezeigt. Sobald ich aber Daten abrufen will, gibt
> es Probleme.

Welche Probleme? Was hast du ewartet, was passiert stattdessen? Wie 
sehen die Signale und die DC-Pegel denn aus? Welches Mess-Equipment (mit 
dem du umgehen kannst) hast Du zur Verfügung?

: Bearbeitet durch User
von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit welcher Frequenz laufen die ATmega8 bzw. der ATmega16?

("Slave operation does not depend on Bit Rate or Prescaler settings, but 
the CPU clock frequency in the Slave must be at least 16 times higher 
than the SCL frequency.")

von Jenny L. (jenny_lo)


Bewertung
0 lesenswert
nicht lesenswert
Beide laufen auf auf 8MHz.

Die anderen Daten muss ich erst zusammen stellen.

von Jenny L. (jenny_lo)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nach erfolgreichem Urlaub kann ich mich wieder meinem Problem zuwenden.

Ich habe das Programm (hoffentlich erfolgreich) aus eclipse exportiert 
und angehängt. Dabei möchte ich darauf hinweisen, dass der Code für den 
TWI Slave nicht auf meinem Mist gewachsen ist, sondern freundlicher 
Weise von Martin Junghans unter freier Lizenz ins Netz gestellt wurde.

Auf einem Atmega 8 läuft alles wunderbar. Daten (einfache Zahlen 
zwischen 10 und 41), die ich im Feld xtbuffer ablege, kann ich auf dem 
Raspi (Python) mit "bus.read_i2c_block_data(Adresse, Position)" auslesen 
und Daten, die ich mit "bus.write_i2c_block_data(Adresse, Position, 
[Wert])" schreibe, landen an der entsprechenden Position im Feld 
rxbuffer.

Der identische Code funktioniert auf dem Atmega 16 nicht richtig.

Wenn ich mir auf dem Raspi mit "i2cdetect -y 1" die belegten Busadressen 
anzeigen lasse, wird der Atmega 16 zwar ordnungsgemäß angezeigt, aber 
ich kann die Daten vom Feld xtbuffer nicht wie oben beschrieben abrufen. 
Versuche ich es, so stürzt der Bus ab. Schicke ich mit dem Raspi Werte 
an den Atmega 16, so kommen sie ordnungsgemäß im Feld rxbuffer an.

Das ist mir ein Rätsel.

An Messtechnik steht mir leider nur ein Speicheroszi zur Verfügung. 
Allerdings denke ich, dass mir das nicht viel weiter helfen wird.

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]
  • [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.