Atxmega32a4 und EEPROM

Hat keiner eine Info für mich??

lg

Servus,

Andy schrieb:
> für die neuen xmegas nicht mehr aktuell?

nein- das funktioniert nicht mehr!

Ich habe meine Erfahrungen hier gemacht:
http://www.atmel.com/dyn/resources/prod_documents/AVR1315.zip

eeprom_driver.c und eeprom_driver.c einbinden

z.b.

#define STD_EEPROM_STORE_PAGE 0x01 // Page
#define STD_EEPROM_STORE   0x010  // Speicheradresse

EEPROM_WriteByte(STD_EEPROM_STORE_PAGE, STD_EEPROM_STORE, XXXX);
XXXX = EEPROM_ReadByte(STD_EEPROM_STORE_PAGE, STD_EEPROM_STORE);

schaut recht kompliziert aus, funktioniert aber super!!

Gruß XMEGA

Hallo,
Danke für deinen Hinweis - werd ich gleich versuchen.
Gibt es eine schnelle Erklärung vom Unterschied zwischen 
STD_EEPROM_STORE_PAGE und STD_EEPROM_STORE?

Besten Dank!

Hallo,

Andy schrieb:
> STD_EEPROM_STORE_PAGE und STD_EEPROM_STORE?

das íst ein Auszug aus meinem Code, einfach zwei #define ... einrichten,

1.Parameter (die Page), 2.Parameter die Adresse in der Page.

Mann nimmt natürlich Namen die die Aktion betrifft.

XMEGA schrieb:

Korrektur zum ersten Beitrag:

eeprom_driver.c und eeprom_driver.h

Gru? XMEGA

Danke, ich meinte aber generell den Unterschied zwischen Page und 
Speicheradresse. Dass die Namen danach ausgelegt sind, weiß ich schon... 
:)

lg

Hallo,

das habe ich noch gefunden:

Beitrag "Xmega EEPROM"

Gruß XMEGA

OK, danke. Ich habe das nun mit Erfolg getestet und verstanden. Nun habe 
ich eine weitere Frage:
Damit ich die Speicherplätze für meine EEPROM-Variablen nicht "händisch" 
eingeben muss (z.B. #define VARIABLE 0x01 usw.), möchte ich die 
EEPROM-Verwaltung generisch gestalten, d.h. ich habe nur eine Funktion 
mit der ich eine Variable übergebe. Diese wird dann im EEPROM abgelegt. 
Wo und wie ist Aufgabe der Funktion. So soll das Ganze dann aussehen:

1

// SCHREIBEN

2

_eeprom_write_byte(&test);

3

4

void _eeprom_write_byte(uint8_t *var)

5

{

6

    refArray[eepromCounter] = var;

7

    EEPROM_WriteByte(0,eepromCounter,*var);

8

    eepromCounter++;

9

}

10

11

12

//LESEN

13

test3 = _eeprom_read_byte(&test);

14

15

uint8_t _eeprom_read_byte(uint8_t *var)

16

{

17

    static uint16_t address;

18

19

    address = var;

20

    //Index herausfinden

21

    for(uint8_t i=0;i<EEPROM_TOTAL_AMOUNT_OF_DATA;i++)

22

    {

23

        if(refArray[i] == var)

24

            return EEPROM_ReadByte(0,i);

25

    }

26

}

Wie ihr seht, möchte ich als eindeutigen Identifier einer Variable 
dessen Adresse verwenden. Diese wird dann in ein Array geschrieben; 
somit kann ich den Index beim Lesen ausfindig machen und die richtige 
Variable zurückgeben.
Was mich jetzt interessiert ist: Kann sich die Adresse einer Variable im 
Programm zur Laufzeit ändern? Würde das nämlich passieren, würde meine 
Funktion falsche bzw. keine Werte zurückgeben. Oder gehe ich generell in 
die falsche Richtung?

Vielen Dank für eure Hilfe!

mfg
Andy

Kann mir keiner helfen?? :)

lg
Andy

Moin,

hier:
Beitrag "xMega EEPROM Memory-mapped"
sind auch noch ein paar Anregungen.

Andy schrieb:
> Damit ich die Speicherplätze für meine EEPROM-Variablen nicht "händisch"
> eingeben muss...

dafür gibt es EEMEM;
mit uint8_t Byte EEMEM; verwaltet der Compiler die Adressen im EEPROM. 
Im obigen Link in der main.c stehen Beispiele.

MfG

@Sauger:
Danke für den Tipp, aber irgendwie funktioniert das in dem Thread 
angehängte Beispiel nicht. Ich habs auf meinem xmega32a4 probiert, aber 
das EEPROM wird nie beschrieben. Kann das vielleicht sein, weil ich den 
Code nicht auf dem EvalBoard, sondern auf meiner eigenen Elektronik 
teste?

Zu meiner vorigen Frage: Grundsätzlich, kann sich die Adresse einer 
Variable zu Laufzeit ändern??

lg
Andy

Mahlzeit,

Die eeprom.h sollte auf alle xMegas abzuwenden sein. Die main ist XPLAIN 
spezifisch.

EEpromInit(); aufgerufen und
#include <avr/eeprom.h>         //EEPROM handling
raus gelassen?

Andy schrieb:
> Zu meiner vorigen Frage: Grundsätzlich, kann sich die Adresse einer
> Variable zu Laufzeit ändern??

Jain, Adressen im EEPROM sind mehr ein Index. Wenn Du diesen selber 
verwaltest (also weist wo du hinmöchtest) dann steht dir alles offen. 
Mit dem Schlüsselwort EEPROM übernimmt der Compiler die Indesvergabe, 
dann sind zur Laufzeit keine Änderungen mehr möglich.

MfG

Danke für die Antwort.
Hab jetzt rausgefunden, dass das EEPROM speichern doch funktioniert, nur 
wird beim Debuggen nichts im Memory-Fenster angezeigt. Kannst du das 
bestätigen, oder ist dir das neu?

Wegen den Adressen: Ich meinte eigentlich, ob sich die Adresse einer 
Variable im SRAM während der Laufzeit ändern kann...

lg
Andy

Mahlzeit,

Du debuggst im Simulator? wenn ja, der kann EEPROM Inhalte (noch) nicht 
(so richtig).

Andy schrieb:
> Wegen den Adressen: Ich meinte eigentlich, ob sich die Adresse einer
> Variable im SRAM während der Laufzeit ändern kann...

Nein geht nicht. Compiler/Linker legen diese fest. Hier hilft nur eine 
dynamische Speicherverwaltung via malloc/free, sprich einen Pointer auf 
die Variable.

MfG

OK, hab jetzt ein bisschen herumprobiert und bin auf folgendes Ergebnis 
gekommen:
Schreibe ich:

1

    EEpromWriteByte(&testByte_EE,0xAA);

2

    EEpromWriteWord(&testWord_EE,0xAAAA);

3

    EEpromWriteDWord(&testDWord_EE,0xAAAAAAAA);

4

    testByte = EEpromReadByte(&testByte_EE);

5

    testWord = EEpromReadWord(&testWord_EE);

6

    testDWord = EEpromReadDWord(&testDWord_EE);

wird "testByte_EE" nicht im EEPROM abgelegt.
Schreibe ich jedoch:

1

    EEpromWriteWord(&testWord_EE,0xAAAA);

2

    EEpromWriteByte(&testByte_EE,0xAA);

3

    EEpromWriteDWord(&testDWord_EE,0xAAAAAAAA);

4

    testByte = EEpromReadByte(&testByte_EE);

5

    testWord = EEpromReadWord(&testWord_EE);

6

    testDWord = EEpromReadDWord(&testDWord_EE);

klappt alles wunderbar. D.h. wenn der erste EEPROM-Zugriff mit der 
Funktion "EEpromWriteByte()" erfolgt, wird dieses Byte nicht ins EEPROM 
geschrieben.
Kann das stimmen?

lg
Andy

Malzeit,

Sollte nicht so sein,
pack dein Testprojekt mal zusammen und poste es. Die main für das XPLAIN 
läuft hier fehlerfrei (schreiben und sofort zurücklesen von Byte/Word 
usw.)

MfG

Hallo,
So, neue Erkenntnisse... :)

Es funktioniert jetzt. Nur was komisch ist, ist folgendes:
Wenn ich bei diesem Code:

1

    portInit();

2

3

    EEpromWriteByte(&testByte_EE,0xAA);

4

    EEpromWriteWord(&testWord_EE,0xAAAA);

5

    EEpromWriteDWord(&testDWord_EE,0xAAAAAAAA);

6

    testByte = EEpromReadByte(&testByte_EE);

7

    testWord = EEpromReadWord(&testWord_EE);

8

    testDWord = EEpromReadDWord(&testDWord_EE);

bei "portInit()" einen Breakpoint setze, wird "testByte_EE" nicht 
geschrieben. Setze ich keinen, klappts wunderbar! Komisch, oder?

lg

Nabend,

nochmal die Frage, womit debuggst Du?
Optimierungen die der Compiler durchführt sind menschlich (und für den 
Debugger) oft schwer zu verstehen, da landet ein Breakpoint schon mal 
ganz woanders wie erwartet.

MfG

Ich arbeite mit dem AVRStudio in der neuesten Version mit dem 
WinAVR-Compiler.

lg

Hallo nochmal,
So, ich habe die Funktionen jetzt vollständig zum Laufen gebracht - 
genau wie ich sie brauche (auch im Debugger passt jetzt alles). Nur 
eines ist mir aufgefallen: Kann es sein, dass die Funktionen - wie 
EEpromWriteByte() - auf dem xMega32A4 langsamer sind, wie die Funktionen 
- wie eeprom_write_byte() - auf dem Mega328p?
Ich muss nämlich ein DALI-Device realisieren, das ich auf dem Mega328p 
schon einwandfrei zum Laufen gebracht habe. Nur beim xMega habe ich bei 
der Adressierung Probleme. Es werden bei der Adressierung Parameter im 
EEPROM abgelegt, schnell direkt hintereinander. Mache ich das beim 
xMega, wird mein Device vom DALI-Controller nicht erkannt. Lasse ich die 
EEPROM-Schreiberei jedoch weg, klappts einwandfrei. Daher dachte ich 
mir, dass vielleicht eine niedrige Geschwindigkeit des 
EEPROM-Schreib-Vorganges Schuld sein könnte... Klingt das plausibel??

Vielen Dank für eure Hilfe!!

mfg

Moin,

wenn du beide Programme hast, einfach im Simulator die Taktzeiten/Zyklen 
ansehen.

MfG

Danke für deinen Hinweis. Bin heute leider nicht in der Firma - könnte 
es erst am Montag versuchen! Aber was sagt deine Erfahrung? Ist es 
generell möglich, dass neuere Controller bei solchen Aufgaben langsamer 
sind als ältere? Oder habe ich irgendwas falsch gemacht??
Könnte es vielleicht daher kommen, dass ich beim 328p mit 20MHz und beim 
32A4 mit 16MHz takte??

Fragen über Fragen.... :)

lg

Moin,

Andy schrieb:
> Könnte es vielleicht daher kommen, dass ich beim 328p mit 20MHz und beim
> 32A4 mit 16MHz takte??

da die Befehlsbearbeitung in den Prozessoren taktabhängig sind, Ja

MfG

Nachtrag,

Andy schrieb:
> Es werden bei der Adressierung Parameter im
> EEPROM abgelegt...

Adressierung, Initialisierung oder Werteänderung?
Dir ist bekannt das EEPROMs eine begrenze Anzahl Schreibzyklen haben.

http://www.mikrocontroller.net/articles/AVR-Tutorial:_Speicher

>...schnell direkt hintereinander.

DALI arbeitet mit einer Baudrate von 9600bd bis 38400bd. Wenn das für 
einen 16MHz Prozzi zu schnell ist, sollte das Softwaredesign überdacht 
werden.

MfG

P.S.:
Sauger schrieb:
> taktabhängig sind
sind durch ist ersetzen

Hallo,
Danke für den Hinweis.
Ich weiß, dass EEPROM-Schreibzugriffe begrenzt sind. Es werden ja nur 
Daten bei der Adressierung gespeichert, und adressiert wird die Leuchte 
ja nicht jeden Tag - also für diesen Zweck sollte es reichen.

DALI arbeitet mit 1200Baud - die Adressierung und restliche 
Kommunikation funktioniert auch wunderbar - nur der 
EEPROM-Schreibzugriff zwischen den einzelnen Datenpaketen ist das 
Problem --> was mir noch eingefallen ist: mit 16MHz (extern) gehts 
nicht, mit 32MHz (intern) schon. D.h. es muss eigentlich mit dem Takt 
zusammenhängen.

lg

Andy schrieb:
> DALI arbeitet mit 1200Baud
stimmt, mit 9600bd bis 38400bd unterhalten sich hier in einem größeren 
Projekt die "Etagenkoppler".

Andy schrieb:
> D.h. es muss eigentlich mit dem Takt zusammenhängen.

... oder mit handkodierten Warteschleifen :-)

MfG

:) Keine handcodierten Warteschleifen.
Es kommt der Befehl - ich schreibe unmittelbar drauf in eine Variable 
und sichere diese ins EEPROM.

In ms ausgedrückt: Wie lange dauert so ca. ein Schreibzugriff aufs 
EEPROM (für ein Byte). Hab dabei leider keine Erfahrung...

lg

Andy schrieb:
> Hab dabei leider keine Erfahrung

mit EEPROMs meinte ich natürlich... :D :D

lg

Frühstück,

Andy schrieb:
> :) Keine handcodierten Warteschleifen.
auch das Warten auf irgendein Ereignis könnte eine Schleife sein :-)

Andy schrieb:
> In ms ausgedrückt: Wie lange dauert so ca. ein Schreibzugriff aufs
> EEPROM (für ein Byte)...
ca. 3ms, Rest steht im Datenblatt.

> ... Hab dabei leider keine Erfahrung...
Beitrag "Probleme mit EEPROM"
Andy schrieb:
> ins EEPROM (ca. 25 Byte) --> Zeit dafür ca. 500ms.

MfG

Hallo,
Ich habe noch eine Frage zu dem ganzen Thema:
Und zwar hab noch eine prinzipielle Frage zu dem Thema! Ich arbeite mit 
der xeeprom.h für den xMega32A4 - da gibt es u.A. die Befehle 
"EEpromWriteDWord", "EEpromWriteBlock" und "EEpromWritePage". Wenn man 
nun Werte ins EEPROM schreiben muss; welcher dieser Befehle macht das am 
schnellsten??

lg Andy

Servus,

Andy schrieb:

> welcher dieser Befehle macht das am schnellsten

Ein einzelner Befehl bringt dich nicht weiter.
Das Lesen und Schreiben ins EEPROM ist ein ungemein komplizierter 
Vorgang geworden.

Diese Befehle sind Bestandteil untenstehender Lib

Verwende die Atmel EEPROM-LIB
siehe: Beitrag "Re: Atxmega32a4 und EEPROM"

Gruß XMEGA

Danke für den Tipp,
D.h. ich sollte die von dir genannten Funktionen verwenden. Sind die 
besser als "EEpromWriteByte" und Co.?
Könnte ich, um Zeit zu sparen, auch den DMA-Controller verwenden? Würde 
das die Geschwindigkeit erhöhen?

lg
Andy