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
Verwendest du Interrupts ? (Verriegelung von Datenzugriffen) Wie groß ist deine Stack Größe ? (Kann sein das du manchmal einen Stack Overflow hast!)
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
Sorry, bin kein C8051-Jünger. Plage mich seit Anbeginn der Zeit mit dem C167 rum. Grüße Oliver
@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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.