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
"Beitrag Löschen" habe ich nur versehentlich mitkopiert.
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.