mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik EEPROM: EEPE bit auslesen scheint nicht zu funktionieren


Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich hab ein kleines Problem mit meinem ATmega48 (zumindest im 
Simulator)

und zwar möcht dich ein 16bit Integer in mein EEPROM schreiben.
Zunächst hab ich das mit
eeprom_write_word()
 aus der eeprom.h gemacht. da wurde nur das lowByte geschrieben. dann 
hab ich die zwei byte einzeln schreiben wollen mit
eeprom_write_byte
. da wurde auch nur eines geschrieben, das erste nur je nach dem wierum 
ich das gemacht hab.

dann hab ichs versucht per hand zu machen, analog zum datenblatt, nur 
halt zweimal und nicht einmal:
  while(EECR & (1<<EEPE))
  ;
  EEARL = (uint8_t)ui16address;
  EEARH = (uint8_t)(ui16address>>8);
  EEDR = (uint8_t)ui16data;
  EECR |= (1<<EEMPE);
  EECR |= (1<<EEPE);
  
  while(EECR & (1<<EEPE))
  ;
  EEARL = (uint8_t)(ui16address-1);
  EEARH = (uint8_t)((ui16address-1)>>8);
  EEDR = (uint8_t)(ui16data>>8);
  EECR |= (1<<EEMPE);
  EECR |= (1<<EEPE);

wieder das selbe: nur das erste byte wurde geschrieben, hier das low

nachdem ich die
while(EECR & (1<<EEPE))
 durch
_delay_ms(10)
 aus der delay.h ersetzt habe hat es funktioniert.


Nun meine Frage(n): hab ich was falsch gemacht? wieso gehn dann die
eeprom_write_byte
 und co nicht? liegt es vllt am simulator (avr simulator)?



Schöne grüße und schon mal danke für die hilfe

Christian

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

Bewertung
0 lesenswert
nicht lesenswert
Hast Du das beachtet:
"EEAR8 is an unused bit in ATmega48 and must always be written to zero."
? EEARH muss beim Mega48 immer Null sein.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, ich schreib zwar was in earh rein, aber die addressen die ich 
verwende sind im passenden bereich von 0..255. also, schreibt er immer 
ne 0 in earh.
vor allem mit der änderung das delay zu verwenden gehts ja, da hab ich 
aber nix an den addressen geändert.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ersetz doch mal versuchsweise deine While-Schleifen bzw. das _delay_ms 
durch
eeprom_busy_wait()
aus der <avr/eeprom.h>

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eeprom_busy_wait()
gibt es (bei mir?) nicht.
dafür hab ich
while(!eeprom_is_ready())
    ;
verwendet.
hat aber den selben Effekt wie
while(EECR & (1<<EEPE))
    ;

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Das High-Byte der Adresse muss zuerst geschrieben werden.

MfG Spess

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für den hinweis, bringt aber auch noch keine änderung.

dadurch das es geht wenn ich die whiles durch delays ersetze 
funktioniert, nehme ich an, dass das EEPE byte falsch ausgelesen 
wird/nicht durch die hardwaregesetzt wird. sprich: er dann nicht lange 
genug wartet.

aber trotzdem danke für alle bisherigen kommentare

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

Bewertung
0 lesenswert
nicht lesenswert
Spess53 wrote:
> Das High-Byte der Adresse muss zuerst geschrieben werden.
Steht wo?

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Im Datenblatt!

MfG Spess

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

Bewertung
0 lesenswert
nicht lesenswert
Spess53 wrote:
> Im Datenblatt!
Schon klar, aber wo im Datenblatt? In meinem steht z.B. nix davon!

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Es gilt generell: Beim Schreiben auf ein 16 Bit Register erst High-Byte 
dann Low-Byte. Beim Lesen eines 16-Bit-Registers erst Low-Byte dann 
High-Byte. Beim ATMega48..168 auf Seite 111 nachzulesen.

MfG Spess

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

Bewertung
0 lesenswert
nicht lesenswert
Spess53 wrote:
> Es gilt generell: Beim Schreiben auf ein 16 Bit Register erst High-Byte
> dann Low-Byte. Beim Lesen eines 16-Bit-Registers erst Low-Byte dann
> High-Byte. Beim ATMega48..168 auf Seite 111 nachzulesen.
Nö, das gilt nicht generell! Eine explizite Reihenfolge bei Schreib- 
oder Lesezugriffen gilt nur bei Registern, die gepuffert sind 
(Timer/Counter-Register) oder bei denen eine Blockierung durchgeführt 
wird (ADC-Datenregister), um sicherzustellen, dass ein ausgelesener 
Inhalt konsistent ist. Bei den EEPROM-Adressregistern trifft nichts von 
beidem zu. Es würde sonst bei der Register-Beschreibung erwähnt. Weshalb 
steht die von Dir zitierte Erklärung wohl im Abschnitt über die 
Timer/Counter?

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Okay, Mit dem EEPROM hat Johannes Recht. Es kann aber nicht schaden, 
sich das gleich so anzugewöhnen. Spart u.U. Ärger an anderen Ecken.

MfG Spess

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

Bewertung
0 lesenswert
nicht lesenswert
Spess53 wrote:
> Okay, Mit dem EEPROM hat Johannes Recht. Es kann aber nicht schaden,
> sich das gleich so anzugewöhnen. Spart u.U. Ärger an anderen Ecken.
In diesem Fall stimme ich Dir vorbehaltlos zu!

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hallo, ich hab ein kleines Problem mit meinem ATmega48 (zumindest im
>Simulator)

Wenn es im ATmega48 problemlos funktioniert, kann es nur noch
am Simulator liegen. Also immer auch mal das Programm in den uC
brennen und dort testen. Spart ne Menge Zeit wenn es im uC
dann funktioniert.

Simulatoren sind ein Stück Software.
Und Software hat immer Bugs oder Einschränkungen :(

Mein Tip: Statt simulieren, ausprobieren !
So spart man sich ne Menge Ärger.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das Problem mit dem ausprobieren ist, dass ich noch keinen µC hab. 
Wird erst noch bestellt, und nun wohl doch ne Nummer größer (ATmega88), 
weil mein programm etwas groß wird^^

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Siehe mal diesen Link von vor ein paar Tagen:

Beitrag "Timer1 Compare Mode Probleme,Mega16"

Da hat der Simulator auch nicht funktioniert.
Das Programm im uC lief perfekt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos Simulator: wenn möglich, immer die Version 2 nehmen (also
wenn der jeweilige Prozessor darin gefunden wird).  Diese Version
verhält sich prinzipbedingt im Digitalteil exakt so, wie auch der
Prozessor selbst, da beide auf dem gleichen Quellcode beruhen.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also gut, danke für die Unterstützung, aber es hatte anscheinend einen 
anderen gund:
ich hab die while durch eine for-schleife ersetzt:
 bTemp = (EECR & 1<<EEPE);
  for(;bTemp;bTemp = (EECR & 1<<EEPE))
    ;
was meiner Ansicht nach das selbe ist.
Draufgekommen bin ich, weil senden über SPI und warten bis er fertig ist 
auch net funktioniert hat.

@Jörg: Das mit Simulator Version 2 hab ich auch schon drangedacht, aber 
da gibts keinen ATmega48/88, nur den ATmega48/88P. Macht das einen 
Unterschied?

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.