Feste EEPROM Adressen aus struct

[Olek (Gast)]

Hallo liebe Leser,

ich habe folgedes Problem.

Ich erstelle mir global ein struct und lege dies im EEPROM ab:

//---------------------------------

typedef struct
{
float Gradient_1;
float Gradient_2;
float Gradient_3;
}my_type;

static my_type Einstellungen EEPROM;

//----------------------------------

in weiteren Funktionen erzeuge ich mir die Werte für Gradient_1...3.
Nachdem ich die Werte habe, schreibe ich mir diese ins EEPROM.

der Wert für Gradient_1 wird unter der Adresse &Gradient_1 abgelegt 
(4Byte)
der Wert für Gradient_2 wird unter der Adresse &Gradient_2 abgelegt 
(4Byte)
der Wert für Gradient_3 wird unter der Adresse &Gradient_3 angelegt 
(4Byte)

Beim Auslesen wird immer von der jeweiligen Adresse 4Byte gelesen

Soweit läuft alles wie es soll.

Ich bekomme jedoch Probleme sobalt ich zum Beispiel unter der Adresse 
&Graient_1 einen neuen Wert ablege, als wäre die Adresse welche ja in 
&Graient_1 abgelegt war verändert worden, was ich jedoch nicht mache.

Ich gehe davon aus, dass sich die Adresse ja im laufendenbetrieb nicht 
ändert, jedoch scheint er eine andere Stelle aus dem EEPROM zu 
beschreiben.

Nach einem Reset läuft alles so wie es soll und er findet alles dort wo 
es abgelet wird, jedoch wird anscheinden alles über den Haufen geworfen 
sobalt ich den Wert ein weiteresMal schreibe.

Jemand ne Ahnung wo mein Problem liegen könnte?

Kann es sein das ich mein EEROM komplett adressieren muss, um so dieses 
Problem zu vermeinden?

[Grrrr (Gast)]

Code auf das Minimum reduzieren, so das der Fehler (gerade) noch 
auftritt und hier posten.

[Olek (Gast)]

Glaub mir ich hätts getan :)
Der Code ist jedoch so komplex (schöneres Wort für vermüllt) geworden, 
dass es erst im ganzen diese Fehler verursacht... sowas passiert immer 
wenn die Leute im Projekt mit neuen Ideen kommen die sie gerne 
(unbedingt) haben möchten.

Ich versuche grade selbst alles etwas zu entwirren, kann jedoch schon 
sagen, dass es im EERPOM an der richtigen Stelle landet, nur muss ich 
noch ermitteln obs der korrekte Wert ist.

Der schluckt mir auch die delay Funktion nach einem return aus einer 
Unterfunktion.
Ich hoffe mal die Optimierungen machen mir da keinen Strich durch die 
Rechnung.

Eigentlich brauche ich paar Ideen oder meinungen, um besser einzugrenzen 
wo nach ich suche.

Bin hier schon überall am suchen, wo sich bei anderen die ´Fehler 
versteckt haben und so vielleicht auf mein Problem zu kommen.

Wenn ich mehr eingrenzen kann werde ich hier Code posten, aber im 
augenblick ist es weniger sinnvoll ca. 3k Zeilen zu posten.

[Karl H. (kbuchegg)]

Olek schrieb:
> Der Code ist jedoch so komplex (schöneres Wort für vermüllt) geworden,
> dass es erst im ganzen diese Fehler verursacht...

Dann wirf ihn weg und schreib ihn neu.
Geht auf lange Sicht schneller als dubiose Fehler zu suchen.

> Ich versuche grade selbst alles etwas zu entwirren, kann jedoch schon
> sagen, dass es im EERPOM an der richtigen Stelle landet, nur muss ich
> noch ermitteln obs der korrekte Wert ist.

Jedes Brennprogramm kann auch das EEPROM auslesen

> Der schluckt mir auch die delay Funktion nach einem return aus einer
> Unterfunktion.

Welche delay Funktion?
Lass mich raten: selber geschrieben mit einer Warteschleife, die der 
Optimizer liebend gerne wegoptimiert, weil ihn nichts und niemand daran 
hindert.

> Eigentlich brauche ich paar Ideen oder meinungen, um besser einzugrenzen
> wo nach ich suche.

Ohne Code?
Ohne Code den du selber schon nicht mehr durchschaust?

Du beliebst zu scherzen.

Aber seis drum:
Pointer Zugriff überprüfen, ob die Pointer auf etwas Sinnvolles zeigen.
Array Zugriffe auf 'out of bounds' untersuchen.
Ein Spezialfall davon: Strings, die zu lange für ihre haltenden Arrays
werden.

Das sind so die gängisten Problemkreise, die 'seltsames Verhalten' 
hervorrufen können.

[Olek (Gast)]

Karl heinz Buchegger schrieb:
> Olek schrieb:
>
>> Der Code ist jedoch so komplex (schöneres Wort für vermüllt) geworden,
>
>> dass es erst im ganzen diese Fehler verursacht...
>
>
>
> Dann wirf ihn weg und schreib ihn neu.
>
> Geht auf lange Sicht schneller als dubiose Fehler zu suchen.
>

Stimmt schon, aber ich habs so mit Fehlern... muss immer wissen warum 
und weshalb.

>
>
>> Ich versuche grade selbst alles etwas zu entwirren, kann jedoch schon
>
>> sagen, dass es im EERPOM an der richtigen Stelle landet, nur muss ich
>
>> noch ermitteln obs der korrekte Wert ist.
>
>
>
> Jedes Brennprogramm kann auch das EEPROM auslesen
>
>

jop, so habe ich rausgefunden das es an den richtigen Adressen ankommt.
Nur muss ich noch die Rohdaten selbst umrechnen, um zu wissen ob da 
Murks steht.

>
>> Der schluckt mir auch die delay Funktion nach einem return aus einer
>
>> Unterfunktion.
>
>
>
> Welche delay Funktion?
>
> Lass mich raten: selber geschrieben mit einer Warteschleife, die der
>
> Optimizer liebend gerne wegoptimiert, weil ihn nichts und niemand daran
>
> hindert.
>

ne, nicht ne eigene, ist die aus der avr.lib, die funktioniert ja auch 
soweit, bis ich in die Hauptschleife aus einer Funktion zurück komme.
Bei der Funktion ist glaube ich auch irgendwo der Fehler begraben.

>
>
>> Eigentlich brauche ich paar Ideen oder meinungen, um besser einzugrenzen
>
>> wo nach ich suche.
>
>
>
> Ohne Code?
>
> Ohne Code den du selber schon nicht mehr durchschaust?
>
>
>
> Du beliebst zu scherzen.
>
>
>
> Aber seis drum:
>
> Pointer Zugriff überprüfen, ob die Pointer auf etwas Sinnvolles zeigen.
>
> Array Zugriffe auf 'out of bounds' untersuchen.
>
> Ein Spezialfall davon: Strings, die zu lange für ihre haltenden Arrays
>
> werden.
>

Das passt alles soweit.

>
>
> Das sind so die gängisten Problemkreise, die 'seltsames Verhalten'
>
> hervorrufen können.

Ein Aufruf einer Funktion ist dran schuld. Es ist eine Funktion ohne 
rückgabe und an anderer Stelle funktionniert diese auch ohne 
Probleme....
ne idee wie ich "simpel" ein Stackoverflow nachweisen kann?

ohne Simulator oder Debbuger...