Variable in EEprom anlegen

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

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.

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.

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

Was schreibe ich am besten noch nach dem EEMEM hin?
EEMEM =??

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.

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.

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.