EEPROM: EEPE bit auslesen scheint nicht zu funktionieren

Christian Gast 03.04.2008 13:50 #832072

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

1	`eeprom_write_word()`

 aus der eeprom.h gemacht. da wurde nur das lowByte geschrieben. dann 
hab ich die zwei byte einzeln schreiben wollen mit

1	`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

1	`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

Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat

Johannes M. (johnny-m) 03.04.2008 15:13 #832202

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Christian Gast 03.04.2008 15:36 #832248

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Εrnst B. (ernst) 03.04.2008 16:58 #832349

Lesenswert?

•

▲
▼

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

1	`eeprom_busy_wait()`

aus der <avr/eeprom.h>

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Christian Gast 03.04.2008 17:16 #832382

Lesenswert?

•

▲
▼

1	`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))

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Spess53 Gast 03.04.2008 17:23 #832390

Lesenswert?

•

▲
▼

Hi

Das High-Byte der Adresse muss zuerst geschrieben werden.

MfG Spess

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Christian Gast 03.04.2008 17:37 #832403

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Johannes M. (johnny-m) 03.04.2008 17:50 #832421

Lesenswert?

•

▲
▼

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Spess53 Gast 03.04.2008 17:51 #832425

Lesenswert?

•

▲
▼

Hi

Im Datenblatt!

MfG Spess

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Johannes M. (johnny-m) 03.04.2008 17:53 #832428

Lesenswert?

•

▲
▼

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Spess53 Gast 03.04.2008 18:00 #832435

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Johannes M. (johnny-m) 03.04.2008 18:05 #832444

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?

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Spess53 Gast 03.04.2008 18:18 #832456

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Johannes M. (johnny-m) 03.04.2008 18:20 #832462

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!

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

holger Gast 03.04.2008 18:23 #832464

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Christian Gast 03.04.2008 18:26 #832468

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

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

holger Gast 03.04.2008 18:38 #832477

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Jörg W. (dl8dtl) Moderator 03.04.2008 20:27 #832566

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.

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

Christian Gast 04.04.2008 10:03 #832928

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?

Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat

EEPROM: EEPE bit auslesen scheint nicht zu funktionieren

Antwort schreiben