Feste EEPROM Adressen aus struct

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

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