mikrocontroller.net

Forum: Compiler & IDEs Kann das sein? Variable in 0


Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Es geht um die erste Zeile im deassemblierten Code der angegebenen
C-Anweisung: Das L-Byte der Variable uint16_t gbc_pcnt soll also an
Adresse 0x0000 stehen? Kann das sein?!?

484:        if(gbc_pcnt < gbc.transmission_length){
+000005CD:   91200000    LDS     R18,0x0000       Load direct from data
space
+000005CF:   913007FF    LDS     R19,0x07FF       Load direct from data
space
+000005D1:   91800061    LDS     R24,0x0061       Load direct from data
space
+000005D3:   91900062    LDS     R25,0x0062       Load direct from data
space
+000005D5:   1782        CP      R24,R18          Compare
+000005D6:   0793        CPC     R25,R19          Compare with carry
+000005D7:   F498        BRCC    PC+0x14          Branch if carry
cleared


Gruss

Michael

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LDS     R18,0x0000
Ja, das kann sein: An Adresse 0x0000 liegt bei einem AVR gerade R0.
Auf die nächste Anweisung
LDS     R19,0x07FF
kann ich allerdings ohne Angabe des Controllers nicht interpretieren.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> LDS     R19,0x07FF
> kann ich allerdings ohne Angabe des Controllers nicht
interpretieren.

Jepp, das fiel mir soeben auch auf. Da nämlich die Adresse 0x07FF ganz
zuoberst in meinem Mega32 ist (der hat 2048 Bytes RAM, oberste Adresse
= 0x07FF). Keine Ahnung, wie der Compiler auf die hirnrissige Idee
kommt, die Variable ganz nach oben zu setzen. Das RAM ist zwar gut
gefüllt, aber kaum über 1500 Bytes.

Allerdings: Wenn ich ein grosses Array auskommentiere bzw. nur die
Schreibzugriffe darauf, dann funktioniert mein Programm. Die fragliche
Variable bleibt aber an gleicher Position 0x07FF.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohrfeigen sollte man mich!

Ich habe schlicht und einfach vergessen, ein fast 2kB grosses Array aus
einem früheren Testlauf zu entfernen. Kein Wunder, ist da das RAM
irgendann überfüllt.

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, 0x7FF ist nicht das Ende des RAMs, das liegt bei einem Mega32 erst
bei 0x85F, da er ja erst bei 0x60 anfängt.
0x7FF kann also gut ein Teil des Stacks sein. Das lowbyte holt er sich
dann aus dem tmp-Register, das highbyte aus dem ram.

Die zweite geladene Variable liegt hingegen ganz am Anfang des RAM, ich
würde also schätzen, es handelt sich hierbei um eine am Anfang
initialisierte Variable, die fest im Ram liegt und nicht auf dem Stack.

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.