Hallo,
vielleicht kann mir jemand weiterhelfen, der schon mal das selbe Problem
mit dem C-Comiler von Keil µ-vision2 gehabt hat. Ein einfaches Programm
zur Servoansteuerung funktionierte beim ersten mal. Als ich nochmal
starten wollte (und zuvor neu compellierte) ging es nicht mehr. Nach
einigen Malen ausprobieren ging es dann wieder. Um was für ein
mystisches Phänomen handelt es sich dabei?? Habe beim Step-Modus
gemerkt, das er von der Hauptschleife in die Unterfunktionen reinspringt
und einen Befehl der dies Veranlasst.
Hoffe es kann mir jemand weiterhelfen -DANKE
Da muß man aber wirklich hellsehen können (Deine Gedanken, den Inhalt
Deiner Festplatte).
Überlege Dir Deine Frage besser nochmal, d.h. bringe auch relevante
Informationen mit hinein.
Allgemein gilt:
- Einstellungen überprüfen (Speichermodell, Compiler, Linker)
- auf Warnungen und Errors achten und beheben
- Speicherauslastung prüfen (*.m51-File)
Peter
Hallo!
Die Beiträge sind zwar schon ein paar monate her, aber trotzdem würde
ich gerne wissen, ob es irgendeine Lösung gab.
Ich hatte das gleiche Problem, dass aber auf einen Stack-Overflow
zurückzuführen war. Jetzt habe ich ein anderes - evtl. ähnliches Problem
(Stack ist aber ok). Variablen, die sich im XDATA befinden, werden bei
einem Funktionsaufruf geändert. Hört sich schon an wie ein
Stack-Problem, aber eigentlich befindet sich der doch in IDATA? Und die
Variablen liegen mitten in XDATA (ca. 100H bei FFFH XDATA-Größe)
Ich benutze das LARGE Memory Model.
Kann mir jemand helfen??
Astrid
Hallo Astrid,
der Keil verwendet zudem noch einen Userstack. Lokal definierte
Variablen in Funktionen werden dort abgelegt und beim Verlassen wieder
freigegeben. Siehe den Startup-Code Start167.a66?
Grüße
Oliver
Hallo Oliver!
Danke für die Antwort - soweit war ich jetzt auch schon ;-)
Ich benutze einen C8051. Inzwischen bin ich einen Schritt weiter und
habe bemerkt, dass der Befehl "MOVX @DPTR,A" den Wert aus A an zwei
Stellen in meinen XDATA-Memory schreibt, nämlich an die Adresse, die der
DPTR beinhaltet (also die richtige Stelle) und die gleiche
Adresse-1000H. Wenn also der DTPR auf 12B9H steht, wird der Wert
ebenfalls an die Stelle 2B9H geschrieben... im worst case also an eine
Adresse, an der sich irgendwelche Variablen befinden.
Irgendeine Idee??
LG,
Astrid
@Astrid,
der MOVX schreibt bestimmt nicht an 2 Adressen gleichzeitig, Du liest
nur von 2 Adressen das Gleiche.
Entweder Du hast eine Adressleitung nicht angeschlossen oder Dein
externer Speicher ist so klein und wird deshalb an der höheren Adresse
gespiegelt. Im Klartext, diese Adreßleitung wird gar nicht ausgewertet.
Das Large-Model sollte man möglichst nicht verwenden, es erzeugt nur
unnötig großen und langsamen Code. Deshalb ist als default auch das
Small-Model eingestellt.
Da ich nur selten externen Speicher angeschlossen habe, geht sowieso nur
Small.
Aber auch mit externem Speicher ist Small immer zu empfehlen und
sauschnell. Man kann ja größere Variablenfelder trotzdem als XDATA
deklarieren. Also ist man in der Speicherverwendung in keinster Weise
eingeschränkt.
Und wenn man möglichst wenige globale bzw. static Variablen hat, reicht
der interne RAM (128 Byte) verdammt weit. Der Keil kann ihn nämlich
überlagern, d.h. für mehrere Funktionen den selben Speicher verwenden.
Hier mal ein Beispiel:
http://www.specs.de/users/danni/appl/soft/c51/thclock/index.htm
Peter
Hi,
Es hört sich vielleicht ein wenig eigenartig an, aber ich habe das
selbe Problem wie Astrid. Das eigenartige bei mir ist, dass dieses
Problem (Die Manipulation von Variablen) nur dann auftaucht, wenn ich
eine Funktion aufrufe, die eine "printf"- Anweisung enthält. Wird
diese entfernt, läuft alles eiwandfrei. Auf der Keil-Website stand
irgend etwas davon, dass im Large-Modell 40 Byte für die "printf"
Anweisung im XDATA-Bereich reserviert werden. Parameter für printf
werden in diesen 40 Bytes abgelegt. Ich vermute, das dies das Problem
ist.
Hammoud
Ein Paar Vermutungen...
A) Hardware-Ursache:
Der Abstand zwischen der Originaladresse un der Schmieradresse von
1000h hört sich schon stark nach einem Problem der Adressedcodierung
an. Deshalb stellen sich drei Fragen:
1. An welcher Adresse landen die Werte eines movx @dptr,a, wenn
dptr=12bah?
2. Gibt es eine weitere Schmieradresse im Abstand eines ganzzahligem
vielfachen von 1000h?
3. Wei groß (byte) ist der angeschlossene XRAM und an welchen Adressen
ist ein eingeblendet?
B) prinf schreibt auf XRAM:
Ich gehe davon aus Problem(Hammoud)=Problem(Astrid). Da der Effekt mit
der Schmieradresse mit dem entfernen von printf verschwindet:
Schreibt printf auf diese Adresse? Vieleicht als push acc?
Dann wäre der ABstand von 1000h nur Zufall.
cu
Hallo!
Kann es sein, dass diese Probleme immer nur im Mai auftreten? g
Ne, mal ernsthaft... 2 Jahre sind eine lange Zeit, aber ich meine mich
erinnern zu können, dass dieses "Doppelschreiben" daran lag, dass
mein realer Speicher kleiner war als der adressierbare und somit der
Bereich 0-FFFh identisch war mit 1000h-1FFFh. (Oder so ähnlich...) Ein
Faux-pas meinerseits... Man sollte wirklich vorsichtig mit dem
Large-Modell umgehen!
Vielleicht hilft dies jemandem hier...
Happy programming,
Astrid
