Hallo liebe mikrocontroller.net Leute,
ich möchte ein avr Assembler projekt etwas verändern und neu übersetzen.
Der Code stammt aus:
http://searle.x10host.com/MonitorKeyboard/index.html
Dazu habe ich gestern den "AvrAssembler2" von Atmel, aus dem Atmeld
Studio 5 extrahiert. "Meinen Code" kann ich nun fast übersetzen, aber
bei folgenden Befehlen gibt Errors, ...
1
adiw Y, 0x2
2
sbiw Y, 0x03
3
4
z.B.
5
adiw Y,0x01
6
error: syntax error, unexpected MINUSMINUS
Die obigen Befehle sind wohl 16Bit Addierbefehle für ein Registerpaar.
Da ich ein verwöhnter arduino Benutzer bin hab ich halt von avr
Assembler keine Ahnung.
Ich Übersetze mit Windows, BatchFile:
; adiw Y, 0x2 ; diese Syntax kennt der Assembler nicht
3
adiw YH:YL,0x02 ; so geht es
Sehr erfreulich ist, der assembler erzeugt tatsächlich ein identisches
Hex-File, so wie es damals vor 10 Jahren vom Entwickler des Projektes
erzeugt wurde. D.h. auf der Basis kann ich weiter arbeiten.
mfG. Klaus Loy
Achja, jetzt wo du es schreibst: das war eine der Eigenarten, die Atmel
diesem Assembler beigebracht hat. Obwohl zwar sonst überall Y als
Pseudonym für das Registerpaar r28/r29 benutzt wird, musste man es im
Assembler als YH:YL notieren.
Nicht erst l dann h?
ist das egal?
Bei mir steht da zum Beispiel:
adiprint:
lpm ; erstes Byte des Strings nach R0 lesen
tst R0 ; R0 auf 0 testen
breq print_end ; wenn 0, dann zu print_end
mov temp, r0 ; Inhalt von R0 nach temp kopieren
rcall ausgabe
adiw ZL:ZH, 1 ; Adresse des Z-Pointers um 1 erhoehen
rjmp print ; zum Anfang springen, um naechstes
; ; Byte aus dem cseg-Label text1;zu holen
ist das falsch?
ciao
gustav
In Asselbler aus AVR Studio 4.19 reicht es, untere geradzahlige Register
anzugeben.
So sind Varianten wie diese gleich:
adiw r27:r26,1 oder adiw r26,1
genauso auch movw r31:r30,r1:r0 und movw r30,r0
Danke für Euere Reaktion.
Wie gesagt, es wird identischer Code erzeugt, wie vom Entwickler damals,
2013, mit einem mir nicht bekannten Assembler. Das hätte ich nicht
gedacht.
Ich wollte einfach mal naiv das alte Hex-File mit dem neu generierten
vergleichen, vollständig binär kompatibel.
mfG. Klaus Loy
Jörg W. schrieb:> Achja, jetzt wo du es schreibst: das war eine der Eigenarten, die Atmel> diesem Assembler beigebracht hat. Obwohl zwar sonst überall Y als> Pseudonym für das Registerpaar r28/r29 benutzt wird, musste man es im> Assembler als YH:YL notieren.
Unsinn. Ganz sicher nicht der AvrAssembler2. Der schluckt adiw Y,<const>
völlig problemlos. Es sei denn, man war so wahnsinnig, irgendwelche
exotischen Optionen zu aktivieren, wie z.B. das von S.Landolt erwähnte
-c.
Und die Ursache dafür ist nicht etwa der Assembler selber, sondern die
Include-Files. Die deklarieren nämlich erst die Aliase für die
Indexregister und sie tun das nur in einer "caseness". Und nicht einmal
alle in derselben, so weit ich mich erinnere...
c-hater schrieb:> Es sei denn, man war so wahnsinnig, irgendwelche exotischen Optionen zu> aktivieren, wie z.B. das von S.Landolt erwähnte -c.
Stellt sich die Frage, wofür es so eine Option dann überhaupt gibt.
Jörg W. schrieb:>> -c.>> Stellt sich die Frage, wofür es so eine Option dann überhaupt gibt.
Ja, das habe ich mich auch schon oft gefragt. Irgendeinen Sinn würde die
nur ergeben, wenn es dann zur Assemble-Zeit auch ein auswertbares Symbol
geben würde, über welches der Preprozessor-Code ermitteln kann, dass
halt caseness jetzt wichtig ist oder nicht. Gibt es aber entweder nicht
oder der Include-Generator kann damit nicht umgehen. Die includes
jedenfalls scheissen einen großen Berg darauf und deklarieren halt die
Aliase einfach nur in irgendeinem case und, wie schon gesagt: nach
meiner Erinnerung nicht mal alle im gleichen.
S. Landolt schrieb:>> ... includes ... nach meiner Erinnerung nicht mal alle im gleichen>> 'Memory is treacherous'!
Ja, mag sein, dass ich mich da täusche.
Naja, die älteste Include-Sammlung in meinem Backup-Bestand ist das
Studio 4.18. Wenn ich am WE Langeweile habe, werde ich das mal
diesbezüglich durchforsten. Ich bin mir nämlich fast sicher, dass ich
mich eben nicht täusche. Mag aber sein, dass der Ursprung dieser
Erinnerung noch länger her ist als Studio4.18. Das ist ja praktisch noch
aktuell. ;o)
Nun ja, ich bin so ein Wahnsinniger, arbeite seit jeher mit '-c' mit
einer Vielzahl von AVR8-Typen und hatte nie Probleme mit den
include-Dateien.
Nur bei der Atmel-Dokumentation geht es regelmäßig durcheinander,
siehe u.a. das 'Instruction Set Manual'.
Was nun aber den "Wahnsinn" betrifft: den schreiben nicht wenige
C-Anhänger den Assemblerprogrammierern zu - insofern wären wir schon zu
zweit.
c-hater schrieb:> die älteste Include-Sammlung in meinem Backup-Bestand ist das> Studio 4.18.
Studio 4.18 hat Problem: Abbruch, wenn genug Files im Projekt. Ich kann
jetzt nicht erinnern, ab wieviel Files das passiert, aber bestimmt bei
30 oder 40 schon. Nur Studio 4.19 ist frei davon. Letzte aus 4-Reihe und
beste überhaupt Variante aus alles "Studio"
c-hater schrieb:> Naja, die älteste Include-Sammlung in meinem Backup-Bestand ist das> Studio 4.18. Wenn ich am WE Langeweile habe, werde ich das mal> diesbezüglich durchforsten.
Also zumindest bei Studio4.18 sind tatsächlich alle Indexregister
einheitlich uppercase deklariert.
Falls ich also mit meiner Erinnerung richtig lag, muss sie aus noch
älteren Versionen der Includes stammen. Kann ich mangels Datenmaterial
leider nicht mehr überprüfen.