Hallo, ich versuche gerade einen 80c32x2 zu programmieren. Es scheint aber dass der Befehl "MOV iramaddr,iramaddr" mit dem Opcode 85h nicht funktioniert. In meinem Testprogramm stehen sowohl die Zieladresse (24h) als auch die Quelladresse (26h) im Bit-adressierbaren Scratchpad-Bereich. Der Befehl im Maschienenformat wäre dann "85 24 26". Kann es sein dass man auf diesen Bereich nicht mit diesem MOV-Befehl zugreifen kann ?
H-G S. schrieb: > Der Befehl im Maschienenformat wäre dann "85 24 26". Das ist aber: mov 26, 24
Gast
#4827932
kommt darauf an. 24h ist nicht 24h. Im Bitbereich ist alles etwas anders. http://derstudent5.tripod.com/GCT/Myrzik_Kap3.pdf Seite 5
Denkt ihr es wird erst die Quelladresse angegeben im Opcode ? Das könnte einiges erklären, vor allem warum mein Interrupt-Tastenabfrageprogramm immer einen Reset verursachte :-) Es ist übrigens eine Byte-Adresse - die Sache mit den eigenen Adressen der Bits ist mir bekannt.
H-G S. schrieb: > Denkt ihr es wird erst die Quelladresse angegeben im Opcode ? Nicht denken, sondern nachlesen!
Angehängte Dateien:
-
A51_MOV.png
(3,1 KB)
Peter D. schrieb: > H-G S. schrieb: >> Denkt ihr es wird erst die Quelladresse angegeben im Opcode ? > > Nicht denken, sondern nachlesen! Oder bei hü-oder-hott-Problemen nicht nur einen Fall testen.
Es stimmt... es ist scheinbar der einzige MOV-Befehl bei dem der Quelloperand links steht. Danke euch!
Gast
#4828433
In diesem Dokument ist mov direct,direct falsch beschrieben: http://www.atmel.com/images/doc0509.pdf (S. 34)
Im alten Atmel Instruction Set 0509B-B–12/97 wars noch richtig. Bei Keil isses auch richtig: http://www.keil.com/support/man/docs/is51/is51_mov.htm
Ich habe den Code berichtigt und es hat tatsächlich etwas gemacht! Zwar nicht genau das was ich erwartet hatte aber immerhin ein Fortschritt :-)
Es gibt, falls es nicht wie gewünscht funktioniert doch eine sehr endlich Anzahl Alternativen, oder?
Ja, es scheint dass eine Möglichkeit zum Debuggen sehr wichtig ist. Es sah sehr gut aus als ich den Code schrieb und in Maschinencode umwandelte und dann einswitchte. Dass es nicht wie gewünscht lief war doch recht enttäuschend. Bei der Kontrolle fand ich einen Fehler beim Umwandeln in Maschienencode und auch einen Fehler beim Einswitchen. Es lief aber immer noch nicht, daher schrieb ich jetzt ein neues Testprogramm welches genau an der Stelle des MOV iram,iram nicht das tat was es sollte. Doch wie es aussieht hat die Eingabeport-Serielleinschiebe-Routine einen Fehler - doch ich werde alles einzeln testen bzw. debuggen :-)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.