Hi Leute
Wenn ich mein Programm in AVRStudio simuliere dann wird (schon ab dem
ersten rjmp zu einer Sprungmarke) nicht zur ersten Programmzeile nach
der Marke gesprungen, sondern direkt eine Zeile weiter.
Woran kann es liegen? Ich habe echt keinen Plan.
Aufbau des Anfangs meines Programms:
.NOLIST
.INCLUDE...
.LIST
**********************************************
(Definition der Konstanten)
.EQU
...
...
(Definition der Variablen)
.DEF
...
...
***********************************************
.CSEG
.ORG 0x000
rjmp main
(restliche Interurpvektoren)
***********************************************
(Includedateien)
.INCLUDE" "
...
...
***********************************************
main:
ldi temp,LOW(RAMEND)
out SPL,temp <- mein Problem: es wird direkt hierhin
gesprungen!!!!!!!!!!!!!!!!!!!!
ldi temp,HIGH(RAMEND)
out SPH,temp
Habt ihr vieleicht einen Tipp, was das Problem sein könnte?
DT
Du hast in Deinen Includedateien auch .DB-Anweisungen und benutzt einen
älteren Assembler.
Durch einen Bug wird bei bestimmten .DB-Anweisungen der PC nicht richtig
hochgezählt.
Trotz jahrelanger E-Mails hat es Atmel erst im allerneuesten Assembler
geschafft, diesen Bug zu beheben.
Dafür erzeugt dieser neue Assembler eine unnötige Warnung, wenn eine
ungerade Bytezahl in der .DB-Anweisung steht.
Peter
Danke Peter
Habe das .DB "Zeugs" mit ins entry file genommen und nun funktioniert
es.
Aber normalerweise hätte es auch zuvor funktionieren müssen, denn
eigentlich bekomme ich die Warnungen (im build fenster) wegen ungeraden
Bytezahlen und es wird auch ein Null-Byte eingefügt.
[AVRStudio4.05 |AVRAssembler v1.56 |AT90S8535]
Egal, hauptsache es funktioniert jetzt.
Danke nochmal!!!!!!
Auweia,
das klingt ja richtig schlimm !!!
Du hast also schon einen neuen Assembler benutzt.
Mit dem Verschieben der .DBs hast Du dann nicht den Fehler behoben,
sondern ihn nur besser versteckt. Er ist also immer noch da !
Was ist denn ein "entry file" ?
Bei meinen Tests mit AVRASM32.EXE V1.54 schien der Bug behoben.
Die haben ihn doch nicht etwa in V1.56 wieder eingebaut ???
Zum Test empfehle ich Dir folgendes:
Schreibe alle .DBs hinter den Code, dann sind zumindest alle
Sprungmarken korrekt.
Die .DBs werden ja über Namen angesprochen, z.B.:
text1: .DB ...
text2: .DB ...
tabelle1: .DB ...
usw.
Dann schreibst Du dahinter allen Namen als .DWs
.DW text1
.DW text2
.DW tabelle1
Und dann vergleichst Du die .DWs mit den Adressen der Namen.
Wenn sie nicht gleich sind, dann ist der Bug wieder da !!!
Dann must Du versuchen die V1.54 zu kriegen.
Anbei der Bug mit einem alten Assembler.
"text3" fängt an Adresse 0005 an, aber bei ".dw text3" steht 0004, ist
also falsch !
Das siehst Du auch an dem Sprung ganz am Ende:
falsch: rjmp falsch
Ein relativer Sprung zu sich selber hat immer den Code "cfff", dort
steht aber "cffe"
Peter
Im Flash Bereich ist die Version 1.56 fehlerfrei. Allerdings sind jetzt
.db Direktiven im ESEG etwas problematisch, da sie auch immer an
Wortgrenze enden möchten. Aber mittlerweile gibt's ja schon die Version
1.57 die diesen Mangel hoffentlich auch noch beseitigt. Eine mehrfaches
.def eines Registers ohne die lästigen und unnötigen (bzw. nicht
ausschaltbaren) Warnings ist jetzt immerhin möglich.
Oh, oh, oh,
da werden also immer neue Bugs eingebaut, statt alte zu korrigieren. Das
Mehrfachverwenden von Registern war doch mit dem alten Assembler ohne
Probleme, sowie die Nutzung des EEPROM.
Naja zum Glück nehme ich für die professionellen Projekte meinen
bewährten 8051 und den Keil C. Könnte sonst ein teurer Spaß werden, wenn
wegen sowas Geräte zurückgerufen werden müßten.
Wollte grad mal bei einem Redesign den Tiny26 einsetzen, aber da laß ich
dann doch lieber den alten P87C751 drin.
Peter
Hi Peter
ist ja ziemlich interessant.
-Das .db zeugs habe ich hinterm Programmcode.
-zum test:
Ich habe das mit den Namen als .dws ausprobiert und tatsächlich
scheint mir etwas falsch zu sein. (siehe Anhang)
[Bei dem zweiten .dw steht statt 0625 0626]
oder nicht?
DT
@Peter:
> Naja zum Glück nehme ich für die professionellen Projekte meinen bewährten 8051
und den Keil C. <
Richtig. Ich habe einmal professionell einen AVR benutzt, nie wieder.
Nicht bevor Keil den Prozessor unterstützt.
Jens
Hi Dirk,
irgendwie seh ich da überhaupt nicht durch in Deinem "schau mal rein".
Sieht irgendwie aus, wie von hinten durch die Brust ins Auge.
Hast Du da einen Deassembler übers Hex-file gejagt ?
Warum siehst Du nicht direkt in das *.LST-File des Assemblers ?
Aber wenn, wie Du sagst, im .DW was falsches steht, dann scheint das
Atmel wohl nie zu begreifen.
Vielleicht sollte man besser andere Assembler verwenden oder rafft das
kein einziger AVR-Assembler ?
Was ist denn bloß so schwer daran, Bytes korrekt in Words zu packen ?
Peter
Beitrag Löschen
Hallo,
das schau mal rein ist ein Disassembler print, finde ich auch sch...e,
ich habe das Problem z.Z. auch, ich bekommen ne Warnung, dw. hat
ungerade Anzahl, aber die Zeile der Fehlermeldung hat überhaupt keinen
.dw Befehl???
Mike
Dies ist deine Fehlerzeile. Sie erzeugt zwar nur ein Warning, aber
entferne mal das Komma am Ende.
.DB "Year:*","Month:*","Day:*",
Dann sollte alles Einwandfrei übersetzt werden. Wenn ich mich auch recht
entsinne, kann AVR Studio auch keine Zeichenketten als dokumentierte
Eigenschaft. Also nicht immer gleich schimpfen, wenn als nicht ganz ohne
Probleme läuft, zumal ja AVR Studio auch kostenlos ist und dafür eine
ganze Menge leistet.
Tach,
Das mit dem Komma habe ich inzwischen auch entdeckt.
Will ja gar nicht meckern, bei alten assembler wurde mir so etwas aber
auch als schon mal als fehler angezeigt.
Wollte halt nur wissen warum es funktioniert.
DT
