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
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
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 :(
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
> 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.
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)
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
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
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
>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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.