Hallo! Ich bräuchte einen Rat zu einem merkwürdigen Fehler beim Lesen aus dem internen RAM eines 80c32x2 Prozessors. Ich würde gerne ab Adresse "80h" 80 Byte als LCD-Bildpuffer benutzen. Ein Testlauf schlug fehl, das LCD zeigte 80 mal das gleiche komische Symbol an. Das nachfolgende Testprogramm gab 80 mal den Wert "80h" bzw. "1000000" an einem Ausgangsport an. Hier das ungefähre Programm: Zum Beschreiben der 80 Bytes ab IRAM-Adresse "80h": MOV R0,#50h //Zähler für 80d Zeichen MOV R1,#80h //Zeiger auf Start oberes IRAM MOV A,#30h Loop1 MOV @R1,A INC R1 INC A DJNZ R0,Loop1 Zum Auslesen und Anzeigen der 80 Bytes ab IRAM-Adresse "80h": MOV R0,#50h //Zähler für 80d Zeichen MOV R1,#80h //Zeiger auf Start oberes IRAM Loop2 MOV A,@R1 MOV Ausgabeport,A LCALL Parallel_Ausgeben_Unterprogramm LCALL Warte_1_Sekunde DJNZ R0,Loop2 Ist zu dem "Fehler" etwas bekannt oder mache ich generell etwas falsch ?
Guido B. schrieb: > In Loop2 fehlt inc R1! Tut mir leid, ich habe es falsch abgetippt - INC R1 steht im Programm selber nach dem MOV A,@R1. So einen einfachen Fehler hätte ich auch selber gefunden :-) Edit: Opcode "09h" hat der INC R1 im Programm direkt nach "F7h" also dem MOV A, @R1. Edit2: ist das nicht seltsam? Gerade diesen Vertipper der den Fehler normalerweise verursacht passiert mir ...
:
Bearbeitet durch User
80c32x2 ist ein bisschen arg unspezifisch, bist du dir sicher, dass das obere RAM überhaupt existiert (Datenblatt nachsehen)? Edith: gerade nachgeschaut, ist immer vorhanden, kann aber nicht indirekt adressiert werden.
:
Bearbeitet durch User
Guido B. schrieb: > Edith: gerade nachgeschaut, ist immer vorhanden, kann aber > nicht indirekt adressiert werden. Das klingt nach des Rätsels Lösung ... wenn du erklärst warum es nicht indirekt adressierbar ist bzw. wie man sonst an das obere RAM herankommt!
Das sollte schon so gehen. In einem Datenbuch steht: Remember the upper 128 Bytes of data RAM can be accessed only by indirect adressing and SFR space only by direct adressing.
Sorry, da habe ich mich von einer falschen Grafik bluffen lassen. Es ist nur indirekt zugreifbar, direkt landest du in den SFR.
Das obere RAM, also ab 80h, kann nur indirekt addressiert werden. Nachgeschaut im Datenblatt des 89C51RD2/ED2. http://www.atmel.com/images/doc4235.pdf Seite 23. Ansonsten kann ich keinen Fehler sehen. Vielleicht die beiden aufgerufenen Routinen noch mal genau anschauen?
Mir scheints auch richtig. Mach doch mal so einen Speichertest, ohne die LCD-Routinen. Vielleicht hast du auch C31-Derivat? Denen fehlt der oberere Speicher. Tut nichts zum Problem: H-G S. schrieb: > MOV R0,#50h //Zähler für 80d Zeichen Warum macht man sowas? Hast du die 80d in Hex umgerechnet, um sie im Assemblercode als Hex-Zahl zu schreiben und im Kommentar wieder als Dezimal, damit man weiss, dass 80d gemeint ist? mov R0, #80 // Zeichenzähler wäre hier sinnvoller.
Naugt, ich werde ein Testprogramm schreiben dass nur ein Byte in das obere RAM schreibt und wieder ausliest und anzeigt - irgendwie befürchte ich aber das Schlimmste ... Immer diese Probleme! Erst kurz zuvor musste ich beim ersten LCD-Test feststellen dass ich das ganze LCD-Modul verkehrt herum eingebaut/-gelötet hatte - alle Zeichen standen auf dem Kopf :-) Und diese "80" ist leider zufällig die Startadresse des oberen internen RAM (als Hex-Wert) sowohl als auch die Größe des LCD-Bildpuffers (in Byte) der ja an Adresse 80h im internen oberen RAM beginnt!
Hast du garkeine LEDs am "Ausgabeport"? Mit einem Delay von einer Sekunde sollte man doch erkennen können was passiert.
H-G S. schrieb: > Tut mir leid, ich habe es falsch abgetippt Code tippt man grundsätzlich nicht aus dem Kopf nach, sondern postet ihn immer nur mittels Copy&Paste!
H-G S. schrieb: > LCALL Parallel_Ausgeben_Unterprogramm > LCALL Warte_1_Sekunde Was machen die, vielleicht R0,R1 ändern?
Hinter den Sprungmarken fehlen die Doppelpunkte! :-) Echten Code her, sonst gibt es auch nur ungefähre Vermutungen ... Gruß Jobst
Peter D. schrieb: > Was machen die, vielleicht R0,R1 ändern? Zumindest das erste Zeichen müsste dann aber stimmen. Gruß Jobst
Beim Assemblieren des 1-Byte-Testprogramms habe ich den Fehler gefunden: Ich habe den Opcode "F7" in der Auslese-Schleife benutzt anstatt "E7" ... Das kommt davon dass die zwei Schleifen so verwirrend sind und die Glotze nebenbei noch läuft :-)
Brauchst Du einen Assembler? Ich hätte da einen online ... Gruß Jobst
H-G S. schrieb: > Ich habe den Opcode "F7" in der Auslese-Schleife benutzt anstatt "E7" ???? Jetzt sag nicht, du hast den Quark direkt in Hex reingehackt und hier dann den dementsprechenden vermutlichen Assemblercode?
H.Joachim S. schrieb: > ???? > Jetzt sag nicht, du hast den Quark direkt in Hex reingehackt und hier > dann den dementsprechenden vermutlichen Assemblercode? Großartig - nicht? :-)
Masochismus kann grenzenlos sein.... Ja, auf die Art habe ich meinen allerersten Z80 vor gefühlt 100 Jahren auch erste Lebenszeichen beigebracht.
Ich denke, das mal so gemacht zu haben, ist nicht unbedingt verkehrt. Uns aber nach einem Fehler in einem Programm zu fragen und uns ein anderes vorzulegen, finde ich abgefahren ... Dann hätte es auch Ablaufdiagramm oder eine Beschreibung, was es tut (tun soll) , getan. Gruß Jobst
Aus Mitleid anbei ein kleines von mir mal geschriebenes Monitor Programm für 8051, welches einen eingebauten Diassembler beinhaltet. Ab Zeile 1030 eine Liste der unterstützten Befehle. Die Syntax passt für A51(PseudoSam 51), aber ich kann dir auch gerne mal ein HEX machen.
:
Bearbeitet durch User
So wild ist das händische Assemblieren scheinbar gar nicht! Man formatiert das Blatt und fängt rechts mit dem Assembler-Programm an. Danach macht man links die Opcodes zu den Befehlen, fast alle kann man sich von vorhergehenden fertigen Programmteilen klauen - neue Opcodes guckt man in der ausgedruckten Opcode-Tabelle nach. Wenn das fertig ist füllt man links die Adresszeile aus und ganz am Ende kalkuliert man die Sprungadressen der Verzweigungen. Ich habe über 1000 Byte reingeswitcht mit meinem DIL-Switch-EEPROMmer :-) Einmal war der Chip mit seinen Beinchen nicht mittig im Sockel, da hats mir die Bytes quer durch mehrere Unterprogramme verteilt gebrannt - das war hart! Da weiss man wenigstens was man hat, ganz im Gegensatz zu den PC-gebundenen Sachen über USB ... Edit: Einmal muss ich das einfach machen, ich hatte das schon als ich jünger war vor ... Edit 2: Das linke Häkchen heisst "wurde eingeswitcht" und das rechte Häkchen heisst "wurde überprüft durch /RD".
:
Bearbeitet durch User
H-G S. schrieb: > Ich habe über 1000 Byte reingeswitcht mit meinem DIL-Switch-EEPROMmer > :-) Ja, da lernt man auch gleich richtig zu programmieren und auf Fehler zu achten und sie zu vermeiden. ;-) Auf dem Bild mein Brennwerkzeug. Im Sockel steckt ein RAM auf einer Adapterplatine. Damit haben meine damaligen Lehrlinge so ungefähr verstanden, was RAM ist ... Die Widerstände sind z.T. recht Q&D ... Gruß Jobst
H-G S. schrieb: > So wild ist das händische Assemblieren scheinbar gar nicht! Hast du ja selbst gesehen, wie schnell da ein Fehler passiert! Und irgendwo einen einzigen Befehl einfügen und man kann alle Sprungziele neu berechnen - neben sinnloser Arbeit auch wieder fehlerträchtig. Assembler gibts für jeden Prozessor kostenlos, kann also auch kein Argument sein. Was soll's also?? Zu zeigen, dass es geht? Ja es geht, aber das war auch vorher klar, aber dann such deine Fehler gefälligst auch selber und schreib hier nicht so Scheinproblem hin. Eigentlich ne Frechheit, was du hier veranstaltest hast.
Der Ultramon fuer den 8051 hat auch einen 1 Pass Assembler an Bord. Belegt auch nicht mehr als 8k...
H.Joachim S. schrieb: > Assembler gibts für jeden Prozessor kostenlos, kann also auch kein > Argument sein. Was soll's also?? Zu zeigen, dass es geht? Ja es geht, > aber das war auch vorher klar, aber dann such deine Fehler gefälligst > auch selber und schreib hier nicht so Scheinproblem hin. > Eigentlich ne Frechheit, was du hier veranstaltest hast. Arghl ... das trifft mich hart ;-) Nagut das nächste Mal warte ich 2 Tage bevor ich etwas frage! @Jobst: Ich hätte Lust den perfekten, luxurösesten und effektivsten manuellen EEPROMmer zu entwickeln ... mit dem sollte es sehr einfach sein schnell ganze Programme einzutippen :-) @Ultramon 8051: Da ist aber kein Witzprogramm mit drin dass einen in den Wahnsinn treibt oder ? :-)
:
Bearbeitet durch User
H-G S. schrieb: > Ich hätte Lust den perfekten, luxurösesten und effektivsten manuellen > EEPROMmer zu entwickeln =-O ... ich nicht! Brauche ich auch nicht mehr. Das Ding war damals gut, um ein kleines Boot-EPROM für einen 80535 zu brennen, womit dann über die serielle Schnittstelle größere EPROMs gebrannt werden konnten. Gruß Jobst
Bitte 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.