mikrocontroller.net

Forum: Compiler & IDEs Verwirrung EEPROM ATmega168


Autor: Frank Heluk (avrnooby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das ist jetzt sicher wieder ne ganz dumme Frage, aber ich komm allein
nicht weiter:

Ich will das EEPROM des ATmega168 byteweise schreiben und lesen. Das
geht mit den Befehlen von <avr/eeprom.h> auch soweit ganz gut.

Das Programm hat aber noch andere Interruptroutinen laufen (Timer 0,1,2
; USART und I2C). Das geht auch schon alles zu meiner vollen
Zufriedenheit. Jetzt soll das EEPROM als nichtflüchtiger
Betriebsstundenzähler genutzt werden und über einen Ringpuffer (damit
ich nicht immer dieselbe EEPROM-Stelle beschreibe) alle 10 Minuten mit
einem neuen Wert geschrieben werden. Soweit so gut, geht alles.

Jetzt habe ich im Userguide des ATmega48/88/168 auf Seite 23-25 (Kapitel
7.6.3) mit Erschrecken was von 1,8ms bis zu 3,3ms Schreib-, bzw.
Lesezeit für das EEPROM gelesen. Ich sehe da keinen Hinweis das damit
ein ganzer Block gemeint ist, vermute also ein Byte braucht so lange zum
Schreiben und Lesen. Weil aber während des EEPROM-Schreibens laut
Userguide S. 24 unten die globalen Interrupts disabled werden sollen,
würde mir das doch meine ganzen anderen Interrupts versauen, vor allem
die UART-Kommunikation ?!? Was passiert z.B. wenn ich das EEPROM
schreibe, also mit cli() die interrupts disabled sind und genau in der
Zeit kommt mit 9600Baud ein Zeichen auf dem UART an ? Merkt sich der
Prozessor das und springt den UART_RX -interrupt an, nachdem ich mit
sei() wieder freigegeben habe ?

Noch eine Frage: Weil mir die Zeit die im Userguide steht mit mindestens
1,8ms zum schreiben und lesen auf das EEPROM unwahrscheinlich lang
vorkam, habe ich folgendes gemacht: Ich setze ein Pin auf HIGH, schreibe
dann mein Byte, setze den Pin dann wieder auf LOW. Das ganze hab ich mit
dem Oszi gemessen und komme auf ca. 12,4 µs !! Das Byte wurde korrekt
geschrieben. Daraus folgt wohl, das ich wohl irgendwas im Datenblatt
übersehen habe oder ich einfach zu dämlich bin, vermutlich eine Mischung
aus beidem.

Bin für jeden Tip dankbar, vielleicht gibt es ja Application Notes die
das Interrupt und Timingverhalten des ATmega168 näher beleuchten ?

MfG, avrnooby.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Interrupts müssen nicht während des gesamten Schreibzyklus 
gesperrt sein. Es muss nur gewährleistet sein, dass zwischen dem 
Schreiben des EEMPE-Bits und des EEPE-Bits kein Interrupt auftritt. Die 
beiden Schreibzugriffe müssen innerhalb von 4 Taktzyklen durchgeführt 
werden. Ich weiß jetzt allerdings nicht, wie das in der eeprom.h 
implementiert ist.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls Dir die Werte im Datenblatt seltsam vorkommen oder das Datenblatt 
unpräzise ist und Du definitiv irgendwelche Margen einhalten musst, 
ist's mit einer Messung ja nicht wiederlegt, daß es auch länger dauern 
kann...

Vielleicht ist Nachfragen beim Hersteller ne Option? Mit den AVR 
Support-Tickets von Atmel hab ich sehr gute Erfahrungen gemacht, wenn 
ein Datenblatt unvollständig ist: kompetent und flott.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Johann:
Ich finde das Datenblatt (auch an der betreffenden Stelle) sehr 
eindeutig. Ich vermute mal, dass der OP mit "User Guide" das Datenblatt 
meint, zumal auch die Seitenzahlen übereinstimmen.

Das grundsätzliche Problem mit dem EEPROM ist, dass der eigentliche 
Schreibvorgang tatsächlich sehr lange dauert, während das Schreiben der 
Adresse und das Setzen der Write-Enable-Bits, wodurch der Schreibvorgang 
initialisiert wird, sehr schnell geht. Will man mehrere Bytes 
hintereinander schreiben, muss man mit der Busy-Wait-Funktion warten, 
bis der aktuelle Schreibvorgang abgeschlossen ist (bzw. bis das EEPE 
wieder Null wird). Die Sache mit den Interrupts steht eigentlich 
eindeutig unter der Erläuterung des Ablaufs des Schreibens ("Caution: An 
interrupt between step 5 and step 6 will make the write cycle fail, 
...").

Die beiden Dinge (warten, bis EEPROM bereit und kein Interrupt zwischen 
EEMPE- und EEPE-Write) sind eigentlich das einzige, was beachtet werden 
muss. Wenn man mit den Funktionen aus der eeprom.h mehrere Bytes 
schreiben will, dann werden die Busy-Waits zwischen den einzelnen Bytes 
selbstverständlich automatisch eingebaut, da die Funktionen jeweils vor 
dem Schreibvorgang warten, bis das EEPROM bereit ist (also das EEPE Null 
ist). Wenn Du mal zwei Bytes direkt hintereinander schreibst, wirst Du 
auch merken, dass das Schreiben des zweiten dann die im Datenblatt 
genannte Zeit in Anspruch nimmt.

Übrigens habe ich mal in die eeprom.h geschaut und dort steht bei der 
Definition von eeprom_write_byte u.a. zu lesen:
        "/* START EEPROM WRITE CRITICAL SECTION */\n\t"
        "in  r0, %[__sreg]    \n\t"
        "cli        \n\t"
        "sbi  %[__eecr], %[__eemwe]  \n\t"
        "sbi  %[__eecr], %[__eewe]  \n\t"
        "out  %[__sreg], r0    \n\t"
        "/* END EEPROM WRITE CRITICAL SECTION */"

Hier wird also eindeutig vor den kritischen Anweisungen ein cli 
ausgeführt und danach ein sei

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Krümelkackerklugscheißermodus an

Es wird nach dem kritischen Teil kein sei() eingefügt. Es wird lediglich 
das vor dem cli() gesicherte SREG zurückgeschrieben. Wär ja sonst auch 
ein dicker Hund.

Krümelkackerklugscheißermodus aus

Autor: Frank Heluk (avrnooby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten, das hat mir sehr geholfen.




Lutz wrote:

> Es wird nach dem kritischen Teil kein sei() eingefügt. Es wird lediglich
> das vor dem cli() gesicherte SREG zurückgeschrieben. Wär ja sonst auch
> ein dicker Hund.


Bedeuted dass, dass ich das sei() selber machen muss, nachdem
"eeprom_write_byte" beendet ist ? Im Moment schalte ich es nicht wieder 
an, die Interrupts scheinen aber zu laufen.

MfG

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, brauchst Du nicht.
Der "Witz" liegt darin, dass der Zustand vor dem cli() wieder 
hergestellt wird. War sei() bzw. I in SREG zu diesem Zeitpunkt aktiviert 
(z.B. gleich am Programmanfang), wird es danach automatisch wieder 
gesetzt. Wenn es vorher nicht gesetzt war, dann wird es auch nachher 
nicht gesetzt sein. Wenn automatisch ein sei() implementiert wäre, 
würden ja sonst nach jedem Schreibzugriff auf EEPROM der globale 
Interrupt Enable gesetzt, auch wenn man das gar nicht wollte!

Autor: Christian Erker (DL3CE) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, es wird lediglich der Status der Interrupts (an / aus), welcher 
vor der EEPROM Operation bestand, wiederhergestellt. Würde die Funktion 
einfach ein sei(); machen, währen die Interrupts nach der Funktion IMMER 
an, was nicht gewollt ist.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:

> Das grundsätzliche Problem mit dem EEPROM ist, dass der eigentliche
> Schreibvorgang tatsächlich sehr lange dauert, während das Schreiben der
> Adresse und das Setzen der Write-Enable-Bits, wodurch der Schreibvorgang
> initialisiert wird, sehr schnell geht. Will man mehrere Bytes
> hintereinander schreiben, muss man mit der Busy-Wait-Funktion warten,
> bis der aktuelle Schreibvorgang abgeschlossen ist (bzw. bis das EEPE
> wieder Null wird).

Immerhin gibt's noch den EEREADY-IRQ, falls man nicht warten mag. 
Alternativ kann also eine IRQ-getriebene EEPROM-Routine implementiert 
werden.

> Übrigens habe ich mal in die eeprom.h geschaut und dort steht bei der
> Definition von eeprom_write_byte u.a. zu lesen:
>
>         "/* START EEPROM WRITE CRITICAL SECTION */\n\t"
>         "in  r0, %[__sreg]    \n\t"
>         "cli        \n\t"
>         "sbi  %[__eecr], %[__eemwe]  \n\t"
>         "sbi  %[__eecr], %[__eewe]  \n\t"
>         "out  %[__sreg], r0    \n\t"
>         "/* END EEPROM WRITE CRITICAL SECTION */"
> 
> 

Hier ginge auch folgendes, was die IRQ-Latenz weniger belastet:
        "/* START EEPROM WRITE CRITICAL SECTION */\n\t"
        "in  r0, %[__sreg]    \n\t"
        "cli        \n\t"
        "sbi  %[__eecr], %[__eemwe]  \n\t"
        "out  %[__sreg], r0    \n\t"
        "sbi  %[__eecr], %[__eewe]  \n\t"
        "/* END EEPROM WRITE CRITICAL SECTION */"

Wenn ich mich recht entsinne, war das früher auch mal so implementiert.

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.