EEPROM: EEPE bit auslesen scheint nicht zu funktionieren

[Christian (Gast)]

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

[Johannes M. (johnny-m)]

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.

[Christian (Gast)]

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.

[Εrnst B. (ernst)]

Ersetz doch mal versuchsweise deine While-Schleifen bzw. das _delay_ms 
durch

eeprom_busy_wait()

aus der <avr/eeprom.h>

[Christian (Gast)]

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))
    ;

[Spess53 (Gast)]

Hi

Das High-Byte der Adresse muss zuerst geschrieben werden.

MfG Spess

[Christian (Gast)]

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

[Johannes M. (johnny-m)]

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

[Spess53 (Gast)]

Hi

Im Datenblatt!

MfG Spess

[Johannes M. (johnny-m)]

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

[Spess53 (Gast)]

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

[Johannes M. (johnny-m)]

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?

[Spess53 (Gast)]

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

[Johannes M. (johnny-m)]

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!

[holger (Gast)]

>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.

[Christian (Gast)]

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^^

[holger (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Christian (Gast)]

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?