Hallo,
ich habe folgendes Problem:
mit den Befehlen
ldi XL,low(Zeilenanfang*2)
ldi XH,high(Zeilenanfang*2)
setze ich theoretisch den Pointer auf die entsprechende Speicherzelle im
Programmspeicher. Wenn ich mir aber den Inhalt der Register XH/XL
anschaue stimmt das so nicht.
kann mir jemand sagen was ich falsch mache?
Grüße, Jürgen
> kann mir jemand sagen was ich falsch mache?
ja, du verwendest das falsche bildformat. JPG nimmt man für Fotos und
nicht für Bildschirmfotos.
lass mal das *2 weg, dann stimmt es doch.
stimmt, ich habe angenommen, dass der Programmspeicher wortorieniert ist
und damit immer das *2 vorhanden sein muss. Offensichtlich habe ich es
noch nicht verstanden wie es richtig funktioniert.
Komisch ist aber, dass es bei mir bisher mit *2 funktioniert hat.
Selbst im AVR-Tutorial: Speicher steht es so drin.
Vielleicht kann mich ja mal jemand kurz aufklären.
in der Tabelle stehen Startadressen für verschiedene Strings welche ich
ausgeben möchte. Ich will also mit dem Wert aus der Speicherzelle in
einen 2. Pointer laden.
Ich kann deine Frage leider nicht beantworten, weil ich nicht weiß worin
der Unterschied besteht. Die Frgae muss ich also zurückgeben.
Wann nimmt man die Byteadresse und wann die Wortadresse?
pacer schrieb:
> Wann nimmt man die Byteadresse und wann die Wortadresse?
Es hängt davon ab, welchen Befehl du dann in weiterer Folge benutzt.
Adressen im Flash werden vom Assembler immer als die Wortadresse
berechnet. Das ist für Befehle wie rcall oder rjmp genau richtig. lpm
will aber eine Byteadresse haben, und daher muss man mit 2
multiplizieren.
folgendes will ich programmieren:
ich habe einen Datenbreich mit mehreren aufeianderfolgenden Strings.
weiterhin habe ich eine zweite Tabelle in der die Low-Byte-Adresse vom
Beginn eines jeeden Strings stehen Auf diese Tabelle zeigt ein Pointer,
den ich beliebig incrementieren oder decrementieren kann. Decremtentiere
ich zum Beispiel, soll die Adresse ausgelesen werden und an den zweiten
Pointer übergeben werden. dieser leißt dann den Inhalt des Strings aus.
Mit diesem Konstrukt kann ich schnell einen String über oder unter dem
aktuellen String ausgeben, ohe irgenwie den Anfang oder das Ende des
Strings detektieren zu müssen.
Da ich das so noch nie gemacht habe muss ich mich da langsam rantasten
und kann nicht sofort segen wie der nächste Befehl aussieht. Kann man zB
nicht mit dem X-Pointer den Programmspeicher auslesen wäre der nächste
Befehl ein LPM Befehl mit einem Anschließenden mov zum Laden des 2.
Pointers.
ich hoffe ich habe mich nicht zu kompliziert ausgedrückt
Zunächst einmal - LPM geht nur mit dem Z-pointer, wie
bereits ausgeführt wurde. Ein Lösungsansatz wäre z.B.
erst einmal die Flash-Adresse in den Z-pointer zu laden,
mit zweimaligem LPM den Inhalt auszulesen und in den
Stack zu schieben. Danach aus dem Stack in den Z-pointer
zurück holen.
Ich habe schon mehrfach erlebt, dass der AVR-Assembler
mit der Berechnung von Adressen so seine Probleme hat,
sobald es um einen Mix von Strings und Byte-Werten geht.
Völlig unabhängig davon, ob man auf das korrekte word-
alignment geachtet hat. Es kann schon mal zu seltsamen
Effekten kommen.
Mein Vorschlag - so habe ich das Problem dann meistens
in den Griff bekommen:
vor dem Label "Zeilenanfang" ein
.db 0, 0
oder
.dw 0
einschieben.
Oder - worst case - ein
.org 0x0A1B
Schau mal hier (Anhang), ist zwar nicht ganz so, wie Du es Dir
vorstellst, klappt aber ganz gut zur Ausgabe indizierter Texte.
Und hier ein Anwendungsbeispiel, die Routine schreibt menüpunktabhängige
Texte in die erste und letzte Zeile des LCDs 24x8, wobei "mp" das
Register ist, das den Menüpunkt (der auch als Index auf die Textarrays
dient) enthält:
Gast schrieb u.a.:
> Ich habe schon mehrfach erlebt, dass der AVR-Assembler> mit der Berechnung von Adressen so seine Probleme hat,> sobald es um einen Mix von Strings und Byte-Werten geht.> Völlig unabhängig davon, ob man auf das korrekte word-> alignment geachtet hat. Es kann schon mal zu seltsamen> Effekten kommen.
Das kann ich nicht bestätigen.
>> Mein Vorschlag - so habe ich das Problem dann meistens> in den Griff bekommen:>> vor dem Label "Zeilenanfang" ein> .db 0, 0> oder> .dw 0> einschieben.> Oder - worst case - ein> .org 0x0A1B
Das ist definitiv nicht nötig, auch das NOP nicht.
...
ich glaube da brauche ich erst mal eine Weile bis ich mich da
durchgekämpft habe. Aber ich werde sicher nochmal drauf zurückkommen.
>Mein Vorschlag - so habe ich das Problem dann meistens>in den Griff bekommen:>vor dem Label "Zeilenanfang" ein>.db 0, 0>oder>.dw 0>einschieben.>Oder - worst case - ein>.org 0x0A1B
Ich habe keine Ahnung welches Problem damit beseitigt werden soll?!
@Hannes Lux
> Das kann ich nicht bestätigen.
Das braucht es auch nicht.
Ich beschäftige mich seit 1997 mit AVR und Assembler und kenne die
zahlreichen Bugs der diversen Versionen.
@pacer
> Ich habe keine Ahnung welches Problem damit beseitigt werden soll?!
ok. Dann habe ich hier irgendetwas falsch verstanden.
Ich ging anfangs davon aus, dass es ein Problem gäbe.
Wie z.B. der fehlerhafte Inhalt des X-pointers, 0x1432 statt 0x1436.
Mir ist das geschilderte Problem nicht unbekannt.
Daher habe beschrieben, wie ich es mitunter in den Griff
bekommen habe.
Egal, ob da wer bestätigt oder nicht. :-)
Kein Problem?
Wozu dann der ganze Thread? :-)
Ist immer wieder lustig hier.
vergesst meine Rede vor oben. :-)
passt alles.
es stimmt aber, dass AVR Assembler bisweilen
bei der Berechnung von Flashadressen über
Strings und Bytes ins Schleudern kamen.
Unabhängig von alignment-Problemen.
Lässt sich sogar in update-reports nachlesen.
Schönen Tag noch!
Gast schrieb:
> @Hannes Lux>> Das kann ich nicht bestätigen.> Das braucht es auch nicht.> Ich beschäftige mich seit 1997 mit AVR und Assembler und kenne die> zahlreichen Bugs der diversen Versionen.
Ganz schön vorlaut zu so einem Urgestein wie Hannes ;)
Zwischenablage01.jpg
(390 KB)
