Hallo, Ich verwende seit kurzem den Atxmega32a4 und benötige auch das interne EEPROM. Nun meine Frage: Kann ich wie bisher die Funktionen eeprom_read_byte() und eeprom_write_byte(,) benutzten, oder sind diese für die neuen xmegas nicht mehr aktuell? Vielen Dank für eure Infos! mfg Andy
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
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
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
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.