IRAM 80c32x2 indirekte Adressierung Fehler

In Loop2 fehlt inc R1!

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 ...

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.

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?

Sorry, Guido war schneller als ich.

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.

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".

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.

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 ? :-)

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