Hallo zusammen, Ich habe eine Frage bezüglich dem EEprom. Und zwar habe ich bereits ein Array angelegt in dem Daten gespeichert sind. uint8_t eeMeinArray1[] EEMEM = { 18, 3, 70 }; Nun möchte ich in meinem Programm ein zweites Array im EEprom speichern dabei wird beim flashen aber immer auch das erste überschrieben. EE fuse ist gesetzt. Was kann ich machen das der Speicherbereich nicht überschrieben wird?
*uff, schlepp* Läßt mich auf meine alten Tage die sperrige Glaskugel vom Speicher holen, sowas... Also, die Glaskugel verrät mir dass Du einen AVR-Controller beschreiben willst. Blöderweise ist das alte Ding so staubig dass es mir nicht sagt welchen, sodass ich Dir jetzt leider nicht sagen kann welches Bit denn nun das für Dich zutreffende EESAVE (das ist nämlich dafür zuständig, dass beim Flashen der EEProm nicht gekübelt wird) ist. Anders gesagt, ein ganz klein wenig mehr Info tät uns irre dabei helfen das Problem zu finden.
Florian Bonetsmüller schrieb: > uint8_t eeMeinArray1[] EEMEM = { 18, 3, 70 }; > > Nun möchte ich in meinem Programm ein zweites Array im EEprom speichern > dabei wird beim flashen aber immer auch das erste überschrieben. > EE fuse ist gesetzt. > > Was kann ich machen das der Speicherbereich nicht überschrieben wird? Gar nicht. Das EEPROM wird entweder als Ganzes beim Brennvorgang beschrieben oder gar nicht.
:
Bearbeitet durch User
Es handelt sich um einen atmega 8. Das ganze funktioniert ja wenn ich das Programm mit einem Array flashe bleibt der Inhalt des EEproms erhalten. Nur wenn ich das 2. Array mit einfüge ist der Inhalt beider Arrays gelöscht
Florian Bonetsmüller schrieb: > Es handelt sich um einen atmega 8. Das ganze funktioniert ja wenn ich > das Programm mit einem Array flashe bleibt der Inhalt des EEproms > erhalten. Nur wenn ich das 2. Array mit einfüge ist der Inhalt beider > Arrays gelöscht Der Compiler/Linker erzeugt ein Hex-File, in dem der Inhalt beschrieben ist, der vom Brennprogramm ins EEPROM zu brennen ist. Dieses Hex-File wird entweder ins EEPROM übertragen oder es wird nicht übertragen. Letzteres kann sein, weil das Beschreiben des EEPROMS in deinem Brennprogramm ausgeschaltet ist, oder aber weil die Sicherungsfuse für das EEPROM gesetzt ist. Aber: Wenn das EEPROM während des Brennens beschrieben wird, dann wird es zur Gänze neu beschrieben. Teilweise beschreiben ist so nicht möglich.
Karl Heinz schrieb: > Aber: Wenn das EEPROM während des Brennens beschrieben wird, dann wird > es zur Gänze neu beschrieben. Teilweise beschreiben ist so nicht > möglich. Aso das heißt wenn ich in mein Programm eine neue EEpromvariable einfüge dann wird beim nächsten flashen automatisch der EEprom überschrieben, auch wenn eesave gesetz ist?
Florian Bonetsmüller schrieb: > Karl Heinz schrieb: >> Aber: Wenn das EEPROM während des Brennens beschrieben wird, dann wird >> es zur Gänze neu beschrieben. Teilweise beschreiben ist so nicht >> möglich. > > Aso das heißt wenn ich in mein Programm eine neue EEpromvariable einfüge > dann wird beim nächsten flashen automatisch der EEprom überschrieben, > auch wenn eesave gesetz ist? Nein. Wenn eesave gesetzt ist, dann wird gar nichts geschrieben. Nicht mal wenn du das wolltest. Du scheinst in der Vorstellung zu leben, irgendwer würde darüber Buch führen welche Teile des EEPROMS du schon benutzt hast und welche nicht. Dem ist nicht so. eesave wirkt auf das komplette EEPROM.
:
Bearbeitet durch User
Karl Heinz schrieb: > Aber: Wenn das EEPROM während des Brennens beschrieben wird, dann wird > es zur Gänze neu beschrieben. Teilweise beschreiben ist so nicht > möglich. Hängt vom Programmer ab. Mein (selbstgestrickter) kann das sehr wohl. Und in Assembler geht das so:
1 | .ESEG |
2 | .org 32 |
3 | .db 1, 2, 3, 4 |
damit ist Eeprom: bis Adresse 31 intakt von 32-35 (üblicherweise ist das 1 Page) neu beschrieben von 36 - EepEnd intakt. Ob das andere Programmer auch können, kann ich allerdings nicht sagen.
Karl Heinz schrieb: > Nein. > Wenn eesave gesetzt ist, dann wird gar nichts geschrieben. Nicht mal > wenn du das wolltest. > > Du scheinst in der Vorstellung zu leben, irgendwer würde darüber Buch > führen welche Teile des EEPROMS du schon benutzt hast und welche nicht. > Dem ist nicht so. > > eesave wirkt auf das komplette EEPROM. Wie lege ich den fest auf welchen speicherbereich meine Variable gelegt wird? Das ganze hat doch mit dem EEMEM zu tun oder?
Vermutlich hat Deine neue EEMEM-Variable den Platz der alten EEMEM-Variablen erhalten und die alte ist dann im EEPROM "dahinter gerutscht". Damit war sie dann vermeintlich wieder "gelöscht", hatte also den Wert 0xFF. Das Problem bei EEMEM ist nämlich, dass der Speicherplatz nicht unbedingt garantiert ist. Ich vermeide dieses Problem, indem ich ein eemem.c anlege und dort alle EEMEM-Variablen definiere. Füge ich später eine EEMEM-Variable hinzu, dann ganz am Ende der Liste, damit diese neue Variable die nächsthöhere Adresse im EEPROM erhält und nicht alles davor durcheinanderwürfelt.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Vermutlich hat Deine neue EEMEM-Variable den Platz der alten > EEMEM-Variablen erhalten und die alte ist dann im EEPROM "dahinter > gerutscht". Damit war sie dann vermeintlich wieder "gelöscht", hatte > also den Wert 0xFF. > > Das Problem bei EEMEM ist nämlich, dass der Speicherplatz nicht > unbedingt garantiert ist. > > Ich vermeide dieses Problem, indem ich ein eemem.c anlege und dort > alle EEMEM-Variablen definiere. Füge ich später eine EEMEM-Variable > hinzu, dann ganz am Ende der Liste, damit diese neue Variable die > nächsthöhere Adresse im EEPROM erhält und nicht alles davor > durcheinanderwürfel Ah dann ist genau das mein Problem dann muss ich das mal testen wenn ich meine neue Variable unter denn alten einfüge ob dann die alten Adressen erhalten bleiben
Man kann alles rund um EEPROM per AVRDUDE "terminal mode" machen. D.H. spezifisch, einzelne Bytes schreiben und lesen, etc. Mit "avrdude -t" anfangen. Wenn es läuft, "read eeprom" oder "read eeprom 0 512", sein aktuell EEPROM zustand zu überprüfen. Dann kann man mit "write eeprom [location] [byte0] [byte1] ..." weitergehen. Fertig. Für ein Paar Bytes in EEPROM ist so was "per hand" einfacher als durch Makefile und co.
Frank M. schrieb: > Füge ich später eine EEMEM-Variable > hinzu, dann ganz am Ende der Liste, damit diese neue Variable die > nächsthöhere Adresse im EEPROM erhält und nicht alles davor > durcheinanderwürfelt. Es ist eigentlich anders rum, neue Variablen müssen oben stehen.
1 | // neue EEPROM Variablen oben dazu schreiben
|
2 | uint8_t EEMEM langEE=1; // Englisch |
3 | uint32_t EEMEM maxDistanceEE=50; // 50m Distanz |
Die Werte werden aber nur geschrieben, wenn man das EEPROM flasht, nicht wenn man nur das Programm flasht.
:
Bearbeitet durch User
Fritz Ganter schrieb: > Frank M. schrieb: >> Füge ich später eine EEMEM-Variable >> hinzu, dann ganz am Ende der Liste, damit diese neue Variable die >> nächsthöhere Adresse im EEPROM erhält und nicht alles davor >> durcheinanderwürfelt. > > Es ist eigentlich anders rum, neue Variablen müssen oben stehen. Wie das ?
Weil der Compiler/Linker das so macht. Kannst du im Listing bzw. Mapfile ansehen.
Fritz Ganter schrieb: > Weil der Compiler/Linker das so macht. Kannst du im Listing bzw. Mapfile > ansehen. Nöö, danke. Hab mit c sowieso nichts am Hut, aber wenn der wirklich das so macht, dann sind die Idioten die diese Version von c geschrieben haben, noch dümmer als die Sprache selbst.
Dann mache es besser, hindert dich keiner daran, die Quellen sind frei. Oh, du bist nicht intelligent genug einen Compiler zu bauen? Egal, Hauptsache andere, die eine grosse Leistung, meist sogar unbezahlt, erbringen als Idioten zu bezeichnen.
Fritz Ganter schrieb: > Oh, du bist nicht intelligent genug einen Compiler zu bauen? Egal, > Hauptsache andere, die eine grosse Leistung, meist sogar unbezahlt, > erbringen als Idioten zu bezeichnen. Und du bist nicht mal intelligent genug, um zu wissen, dass es sich hier um nichts anderes als ein Array handelt und die werden normalerweise nach FIFO-Prinzip ins Flash oder Eeprom geschrieben. Das, was du da oben geschrieben hast, ist eben genau umgekehrt. Will ich gar nicht erst prüfen, aber ich glaube es einfach nicht.
So steht es im C-File:
1 | uint16_t EEMEM StartupCounter=1; |
2 | uint8_t EEMEM needGSMInit=1; |
3 | uint16_t EEMEM pinCode=0xffff; // -1 meine Fonic PIN=4418 |
4 | char EEMEM MobileNumber[18]; // SMS senden an diese Handynummer, bei der App als ID verwendet |
5 | char EEMEM serverKey[9]="08154711"; // 8 Zeichen als zweites im .eep File |
6 | char EEMEM SerialNumber[21]="This is a fakedevice"; // als erstes im .eep File |
Und hier das Map-File:
1 | .eeprom 0x0000000000810000 0x107 Builds/main.o |
2 | 0x0000000000810000 SerialNumber |
3 | 0x0000000000810015 serverKey |
4 | 0x000000000081001e MobileNumber |
5 | 0x0000000000810030 pinCode |
6 | 0x0000000000810032 needGSMInit |
7 | 0x0000000000810033 StartupCounter |
Und warum sollte es ein Array sein? Es sind einfach Variablen, die in einem bestimmten Adressbereich stehen.
Fritz Ganter schrieb: > Und warum sollte es ein Array sein? Es sind einfach Variablen, die in > einem bestimmten Adressbereich stehen. Ja. Aber diese Variablen stehen in diesem Adressbereich genau in der Reihenfolge, wie die auch deklariert worden sind. P.S. Jetzt habe ich es doch geprüft, zumindest AvrStudio sagt, dass du im Unrecht bist. Ich nehme das mit den Idioten zurück, aber du solltest in Zukunft vielleicht nicht so vorlaut sein.
:
Bearbeitet durch User
Bei mir wird es im Makefile erzeugt, da läuft objdump und so Zeugs, kann schon sein, dass da andere Optionen verwendet werden als bei AvrStudio. Soweit ich es aus dem .lst File sehe, macht der Compiler bei mir die Adressen schon in umgekehrter Reihenfolge.
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.