Forum: Mikrocontroller und Digitale Elektronik ORG Directive im AVR Studio 4 für ATMEGA8


von Rudi L. (lintronics)


Lesenswert?

Hallo zusammen,
ich bin ein Neuling, was das AVR Studio 4 und den ATMEGA8 Prozessor 
angeht. Falls mein Problem schon einmal im Forum behandelt wurde - ich 
habe leider nichts gefunden - sorry.
Von meinem Zilog Assembler bin ich es gewohnt, Programmteile an 
bestimmte Adressen im ROM oder Flash mit der .ORG Anweisung zu 
bestimmen. Wenn ich so eine .ORG Anweisung im AVR Studio 4 mache, kann 
ich im Listing sehen, dass die .ORG Anweisung an der richtigen Adresse 
sitzt. Sehe ich mir dann aber das HEX-File an, liegt der Daten- oder 
Programm-Code immer an Adresse x2 (also anstatt 0x0A00 and 0x1400).
Ich habe leider keine Einstellmöglichkeit im AVR Studio 4 gefunden, um 
dieses Verhalten zu beseitigen. Weiss jemand, warum dies so ist?
Grüsse,
Rudi

von Quehl (Gast)


Lesenswert?

der Programmspeicher ist wortorganisiert. Der Zähler im Listing sind 
daher Wortzähler. Im Hex sind das dann natürlich doppelt so viele Bytes. 
Ich war auch zuerst darüber gestolpert, aber wenn man das weiß, kann man 
sich da auch daran gewöhnen. Im Assembler Programm muß darum auch beim 
Zugriff auf Programmspeicher die Adresse mal 2 genommen werden.

mfg

von Rudi L. (lintronics)


Lesenswert?

Danke für die schnelle Antwort!
Verwirrend ist das schon, da im Listing-File dann die falsche Adresse 
steht, wenn ich Adresse/2 im Assembler-File schreibe - im Hex-File steht 
es dann aber richtig.
Also muss ich im Assembler für z.B. Adresse 0x0A00 den durch zwei 
geteilten Wert schreiben --> 0x0A00/2.
Sehe dann zwar im Listing die Adresse 0x0500, dafür habe ich aber im 
Hex-File die richtige Adresse 0x0A00.
Es funktioniert so, aber logisch ist das für mich nicht :(

von Michael U. (Gast)


Lesenswert?

Hallo,

die Frage, die sich mir hier stellt, ist: wozu?

.org im .cseg benutze ich a) um die IRQ-Vektoren an die richtige Stelle 
zu befördern und b) Tabellen auszurichten, die ich auf Seitengrenzen 
haben will (256 Byte-Grenze, um mit weniger Aufwand Tabellen zu 
bearbeiten).

Im SRAM ebenfalls, um Seitengrenzen zu Nutzen.

Im Assembler ist es immer eine Byte-Adresse, macht also keine 
Verwirrung.
Im Flash wird es immer zu einer Word-Adresse umgerechnet, weil das Flash 
so organisiert ist. Das interessiert mich aber nicht, dafür ist der 
Assembler ja da. Ungerade .desg-Adressen gehen im Flash sowieso nicht, 
da werden Padding-0-Bytes eingefügt, damit sie Word-Länge haben.

Wozu also soll ich wissen müssen oder wollen, wo bestimmte Programmteile 
im Flash tatsächlich landen?

Gruß aus Berlin
Michael

von Rudi L. (lintronics)


Lesenswert?

> Wozu also soll ich wissen müssen oder wollen, wo bestimmte Programmteile
> im Flash tatsächlich landen?
Ich programmiere in Assembler, weil ich wissen will, wo was im Flash/Rom 
steht. Eine .ORG ist bei allen anderen Assemblern, die ich kenne, ohne 
"wenn und aber" an der richtigen Adresse. Vielleicht kann mir ja doch 
noch jemand erklären, warum die Adresse im Listing richtig ist, aber im 
Hex-File falsch.

von Hauke R. (lafkaschar) Benutzerseite


Lesenswert?

Das ist es ja gerade ... sie ist NICHT falsch. Der Flash Speicher beim 
AVR ist in WORDS (2 Bytes) organisiert. Deshalb werden diese Adressen im 
Listing auch so verwendet. Mit AVR befehlen (LPM etc) greifst du aber 
direkt Byteweise zu. Wenn du jetzt schreibst .org 0x01 dann weist du, 
das nachfolgende liegt im 3. und 4. byte im Flash (wenn man von 1 an 
zählt)

von Rudi L. (lintronics)


Lesenswert?

Hallo Hauke,
danke für deine Antwort. Ich denke mal, dass ich so langsam begreife, 
wie der Mega8 funktioniert. Ist nicht einfach, wenn du jahrzehntelang 
mit Zilog Prozessoren zu tun hattest.
Mit dem LPM Befehl komme ich nun auch zurecht.
Danke nochmals für eure Hilfe :o)
Grüsse,
Rudi

von Michael U. (Gast)


Lesenswert?

Hallo,

>Ich programmiere in Assembler, weil ich wissen will, wo was im Flash/Rom
steht.

Na gut, auch ein Argument. ;)

Ich programmiere auch in Assembler seit 6800/Z80/6510-Zeiten. Weil es 
damals üblich war und ich damit gut klarkomme und weil ich genau weiß, 
was die CPU macht.
Es hat mich eigentlich nie interessiert, wo der Kram im Ram oder Eprom 
gelandet ist, wenn es nciht einen systembedingten Grund dazu gab.

Auch beim AVR ist es mir egal, wo eine Routine landet, das ist das 
Problem des Assemblers, daß zu sortieren. Damals wie heute. ;)

Ich würde mir auch ziemliche Probleme einhandeln, wenn ich ohne Grund 
irgendwelchen Projektteilen feste Adressen zuweisen würde. Das sind bei 
mir meist einzelne Files, die per .include eingebunden werden. Wenn da 
immer ein .org drin wäre, würde ich aus dem Ändern und Umsortieren wohl 
nicht mehr rauskommen, wenn ich z.B. die LCD-Routinen um irgendeine 
Funktion erweitere...

Zur Rechnerei des AVR-Assembler wurde eigentlich schon alles gesagt, der 
Flash ist 16Bit breit organisiert, der PC zählt somit auch so, weil ein 
AVR-Befehl eben 16 Bit parallel aus dem Flash lädt.

Nur Daten-Zugriffe aus dem Programm auf das Flash sind Byte-organisiert 
und damit muß umgerechnet werden. Nur LPM kann Byte-weise auf das Flash 
zugreifen, deshalb dort die Rechnerei mit dem *2 
(Wordadresse->Byteadresse).

Gruß aus Berlin
Michael

von Rudi L. (lintronics)


Lesenswert?

Hallo Michael,
> Auch beim AVR ist es mir egal, wo eine Routine landet, das ist das
> Problem des Assemblers, daß zu sortieren. Damals wie heute. ;)
Stimmt, bei diesem Prozessor werde ich wahrscheinlich auch so denken 
müssen. Bei meinen Z180 Programmen habe ich bestimmte Teile des 
Programms ins RAM ausgelagert und konnte in den Routinen Befehle und 
Daten ändern. Mit solchen Tricks kann ein Programm teuflisch schnell 
werden. Bei dieser Art der Programmierung ist es wichtig, dass du genau 
weisst, wo was im Speicher steht. Der Mega8 ist aber so schnell, dass 
ich solche Tricks gar nicht mehr brauche.
Danke für eure Hilfe, meine Sinus-Tabelle wird jetzt geladen und 
ausgegeben und ich bin echt froh, dass man so schnelle Hilfe im Forum 
bekommt.
Grüsse,
Rudi

von Hauke R. (lafkaschar) Benutzerseite


Lesenswert?

>bestimmte Teile des Programms ins RAM ausgelagert und konnte in den Routinen 
>Befehle und Daten ändern

Der AVR kann aber nur Befehle aus dem Flash auslagern und den kann man 
während der laufzeit nicht so einfach neu beschreiben und auch nciht 
schnell genug, dass es sich lohnen würde.

von Michael U. (Gast)


Lesenswert?

Hallo,

der AVR ist eine Haward-Architektur, also Programm- und Datenspeicher 
getrennt. Die anderen sind von Neumann-Architekturen.

Ansonsten: selbstmodifizierende Programme lassen zwar nette Tricks zu, 
wenn man aber mehr als Demos auf dem C64 programmieren will, sollte man 
sowas lieber lassen.
Sowas ist nicht lesbar, nicht wartbar, nicht änderbar, außer durch den 
Programmierer selbst, wenn er nicht nach einem Jahr auch vergessen hat, 
was er da "verbrochen" hat...

Gruß aus Berlin
Michael

Bitte 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
Noch kein Account? Hier anmelden.