mikrocontroller.net

Forum: Compiler & IDEs Keil µvision C Fehler?


Autor: heda0021 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verwendest du Interrupts ?
(Verriegelung von Datenzugriffen)
Wie groß ist deine Stack Größe ?
(Kann sein das du manchmal einen Stack Overflow hast!)

Autor: Astrid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Astrid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry,
bin kein C8051-Jünger. Plage mich seit Anbeginn der Zeit mit dem C167 
rum.

Grüße
Oliver

Autor: Astrid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade... Trotzdem Danke!!!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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/thcl...



Peter

Autor: Hammoud (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Astrid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.