Hallo Leute, seit Stunden versuche ich I2C am ATMega328 mit dem Si7021 zum Laufen zu bringen. Es will einfach nicht richtig klappen. Der Si7021 hat 2 Modi, in einem wird während der Messung SCL auf Low gehalten und dann kann erst der Wert gelesen werden. Ich bekomme ihn aber immer nur mit NACK. Vielleicht ist das normal? Im anderen Modus, muss ich die Adresse zum Lesen der Werte immer wieder schicken, bis ein ACK diese bestätigt. Dann kann ich den Wert lesen, erhalte aber wieder nur ein NACK am Ende des ersten Bytes und das zweite fehlt ja noch. Warum kann ich mir nicht so richtig erklären. Leider ist nur Beispielcode zum Senden, aber nicht zum Lesen angegeben. Ich habe auch versucht, einfach ein paar ms zu warten, bis die Messung fertig ist und jetzt kommt das Verrückte: Ich warte unendlich, da der Timer 0-Interrupt nicht aufgerufen wird und somit die delay-Routine nicht funktioniert. Mein Code stammt aus einem ähnlichen Messprojekt von mir mit ATMega88. Dort lagen die I2C-Routinen brach, weil ich letztlich den DHT22 genommen habe. Jetzt wollte ich nochmal ran und habe auf Steckbrett ein Arduino Pro Mini gesteckt, weil dies am einfachsten war. Prinzipiell sollte der ATMega88-Code hier ja auch laufen. Im DB stehen beide drin. Hab' die unbenutzten Routinen des alten Projekts deaktiviert. Ich versteh' nicht, warum der Timer nicht geht. Aber unabhängig davon verstehe ich nicht, warum es mit dem I2C nicht richtig läuft, was da Faul ist. Ich habe I2C auch mit dem Logic Analyzer verfolgt. Sieht ok aus. Kommt halt nur das NACK am Ende des ersten Datenbytes. Ich habe den kompletten Code mit angehängt, obwohl da viel (momentan noch) unnötiges aus dem anderen Projekt mit drinsteht. Jemand eine Idee?
Christian S. schrieb: > Jemand eine Idee? Ja. Deine Interrupt Tabelle stimmt nicht. Mega328 hat JMP und nicht RJMP, deswegen stimmen die Adressen für Interrupt-Vektoren nicht mehr.
Ok, Danke. Dummer Fehler. Hab's gleich geändert und mir auch eine Notiz gemacht, falls ich später doch wieder einen Mega88 einsetze, der ausreichen würde. Immerhin hat das noch andere Merkwürdigkeiten beseitigt. Die Probleme mit dem I2C leider nicht. Empfangene Bytes werden immer mit NAK bestätigt. Solder
Christian S. schrieb: > beseitigt. Die Probleme mit dem I2C leider nicht. Empfangene Bytes > werden immer mit NAK bestätigt. Und wie sieht es aus mit Control Registern und ID ? Kannst du das lesen ?
>Empfangene Bytes werden immer mit NAK bestätigt.
DU selber musst empfangene Bytes mit ACK bestätigen.
Tust du das?
Ich habe es jetzt mit der ID probiert. Das sind mehrere Bytes und nach jedem soll ein ACK kommen und erst nach dem letzten ein NAK. Leider ist es wie zuvor. Gleich nach dem ersten Byte kommt ein NAK. Das wird ja vom Mega erzeugt. Kann ich das einstellen, ob NAK oder ACK? Hier fehlt möglicherweise noch was. - Ok, ich denke ich habs: Zum Lesen muss ich auch TWEA berücksichtigen und passend setzen. Ich werde das gleich mal einbauen.
Genau das wars. Geht jetzt. Ich muss ja selbst entscheiden, ob ich ACK oder NACK brauche. Das macht der Mega nicht selbst. Nun funktioniert es wie es soll. Danke für die Tipps. Solder
Christian S. schrieb: > Ich habe es jetzt mit der ID probiert. Das sind mehrere Bytes und nach > jedem soll ein ACK kommen und erst nach dem letzten ein NAK. Leider ist Nein. Slaveadress und Command wird mit ACK bestätigt, danach bestätigst DU jedes gelesene Byte mit ACK oder NACK.
:
Bearbeitet durch User
Ja, mein' ich doch. Ich bezog mich nur auf das Lesen / Empfang von Daten. Da muss ich das selbst entscheiden.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.