mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Auslesegeschwindigkeit EEPROM


Autor: Bad Urban (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum,

ich bin mal wieder dabei ein bissl mit meinem AT90USB zu basteln. In 
meinem Programm lege ich mehrere Strings im EEPROM ab, die bei Bedarf 
mit Messwerten ergänzt und über UART ausgegeben werden sollen.

Dabei stellt sich mir die Frage was sinnvoller ist:
a) die Strings bei Programmstart aus dem EEPROM lesen und im RAM ablegen
b) die Strings bei Bedarf Zeichenweise aus dem EEPROM an die UART zu 
schicken.

Ram ist im Moment zumindest noch genug vorhanden. Finde ich aber die, 
sagen wir mal, unelegantere Lösung. Allerdings sollte beim Auslesen aus 
dem EEPROM auch nicht zu viel Zeit vergehen, da im Programm verschiedene 
Funktionen in bestimmten Zeitabschnitten aufgerufen werden sollen.

Mein Problem dabei ist, dass ich nicht herausfinden konnte wie lange ein 
EEPROM-Zugriff dauert und nun nicht genau bewerten kann was für mich 
günstiger ist. Kann das im Moment leider auch nicht messtechnisch 
ermitteln.

Hat hier vielleicht schon mal jemand gemessen wie lange ein Lesezugriff 
dauert? Im Datenblatt und der Forensuche hab ich leider nix gefunden.

Gruß
Bad Urban

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Bad Urban (bad_urban)

>a) die Strings bei Programmstart aus dem EEPROM lesen und im RAM ablegen

Kostet sinnlos RAM

>b) die Strings bei Bedarf Zeichenweise aus dem EEPROM an die UART zu
>schicken.

Ist OK, der EEPROM ist sehr schnell, schneller als der UART allemal.

>Mein Problem dabei ist, dass ich nicht herausfinden konnte wie lange ein
>EEPROM-Zugriff dauert

Datenblatt gelesen?

Adresse in Register EEADRL und EEADRH schreiben.
Bit EERE in Register EECR setzen
Daten aus EEDATA auslesen.

Alles in allem ein halbes dutzend Takte.

>dauert? Im Datenblatt und der Forensuche hab ich leider nix gefunden.

Dann hast du schlecht gesucht.

MFG
Falk

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bad Urban schrieb:
> In meinem Programm lege ich mehrere Strings im EEPROM ab
Warum im EEPROM?

Bad Urban schrieb:
> Mein Problem dabei ist, dass ich nicht herausfinden konnte wie lange ein
> EEPROM-Zugriff dauert
Lies dir im Datenblatt mal den Abschnitt EEPROM Read/Write durch:
When the EEPROM is read, the CPU is halted for four clock cycles before 
the next instruction is executed. 

Und die Codebeispiele belegen, dass keine besondere Wartezeit nötig ist:
unsigned char EEPROM_read(unsigned int uiAddress)
{
/* Wait for completion of previous write */
  while(EECR & (1<<EEWE))
    ;
  /* Set up address register */
  EEAR = uiAddress;
  /* Start eeprom read by writing EERE */
  EECR |= (1<<EERE);
  /* Return data from data register */
  return EEDR;
}
Adresse festlegen, Read-Eanble setzen, Daten abholen.

Autor: Bad Urban (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner:
> Kostet sinnlos RAM

Das find ich ja auch.

> Ist OK, der EEPROM ist sehr schnell, schneller als der UART allemal.

Ok. So genau hatt ichs nicht geschrieben. Ich nutze einen Buffer für 
UART es ging mir nur ums Auslesen und in den Puffer schreiben. Senden 
per UART wird dann über Interrupt gemacht.

> Datenblatt gelesen?
Ja, auch ne App-Note auf der Atmel Seite. Da wars aber ein Assembler 
Beispiel mit der Anzahl Zyklen. Ich nutze eeprom_read_byte() zum 
Auslesen.
Hätt mich halt interessiert ob das schon jemand mal gemessen hat.

Gruß
Bad Urban

Autor: Bad Urban (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> In meinem Programm lege ich mehrere Strings im EEPROM ab
> Warum im EEPROM?

Ich lege da, neben den Strings, auch noch andere Einstellungen ab. Und 
das EEPROM, weil ich dort manche Einstellungen im Betrieb auch wieder 
ändern und abspeichern will. Deshalb hab ich jetzt mal alles ins EEPROM 
gelegt.

Das bringt mich zu dem Gedanken: Wäre das Auslesen aus dem Flash 
schneller? Zumidest bei den konstanten Strings?

> Lies dir im Datenblatt mal den Abschnitt EEPROM Read/Write durch:When the EEPROM 
is read, the CPU is halted for four clock cycles before
> the next instruction is executed.

Werd ich wirklich nachholen. Hatte in den Tabellen mit den Eigenschaften 
geschaut und dort nix gefunden.

Gruß
Bad Urban

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Bad Urban (bad_urban)

>Beispiel mit der Anzahl Zyklen. Ich nutze eeprom_read_byte() zum
>Auslesen.

Da die Jungs vom AVR-GCC nicht doof sind, werden diese Routinen ziemlich 
nah an die ASM-Version rankommen.

MfG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Bad Urban (bad_urban)

>Das bringt mich zu dem Gedanken: Wäre das Auslesen aus dem Flash
>schneller? Zumidest bei den konstanten Strings?

Ein wenig.

MFG
Falk

Autor: Bad Urban (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Da die Jungs vom AVR-GCC nicht doof sind, werden diese Routinen ziemlich
> nah an die ASM-Version rankommen.

Ok, wie das da umgesetzt ist hab ich nicht geschaut. Eben nur mal von 
"Warten bis Auslesen fertig ist" gelesen. Und bei der Gurgel-Suche bin 
ich als Zahlenwert auch irgendwas um die 4ms gestoßen. Das ist dann 
schon lang wenn man ca. 100-150 Zeichen auslesen will...

Gruß
Bad Urban

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und bei der Gurgel-Suche bin
>ich als Zahlenwert auch irgendwas um die 4ms gestoßen.

Beim SCHREIBEN, nicht lesen.

Autor: Bad Urban (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie gings bei den Sachen die ich gefunden habe immer allgemein um 
Zugriffe.
Aber jetzt weiss ich ja, dass meine Sorge unbegründet war.
Euch allen vielen Dank für Eure Hilfe.

Gruß
Bad Urban

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Konstante Daten sollten im Flash liegen, wenn es Variablen oder Strings 
sind.

Structs im Flash abzulegen ist mir unter AVR-GCC noch nicht gelungen. 
Das ist ein ziemlicher Krampf und völlig unleserlicher Code.
Mein Kommandointerpreter hat daher seine Kommando-Struct (Pointer auf 
String, Pointer auf Funktion) im SRAM angelegt.

Konfigurationsdaten kopiere ich zu Anfang in den SRAM und benutze sie 
dort.
Dann kann man auch Änderungen vornehmen, ohne gleich ständig den EEPROM 
zu stressen (Wearout).
Und nur bei Bedarf schreibt man sie zurück oder verwirft sie.
Ich hab mir dafür ne kleine schnuckelige Routine geschrieben:

http://www.avrfreaks.net/index.php?name=PNphpBB2&f...


Peter

Autor: Bad Urban (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich muss zugeben, dass ich auf den Flash nicht gleich gekommen bin. 
Liegt daran, dass ich eben auch veränderliche Strings zu anfang im 
EEPROM abgelegt habe und dann sozusagen aus Gewohnheit den Rest 
hintendrangehängt hab :-)

Mit den Konfigurationsdaten mach ichs eh so, dass ich sie beim Start ins 
RAM lese. Das sind auch nur ein paar Bytes.

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.