Forum: Mikrocontroller und Digitale Elektronik 8051 DPTR seltsames Verhalten ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Hallo !

Der aktuelle Bug in meinem 8051-Programm ist der seltsamste bisher :-)

Ich habe ein (EEPROM-) Speicher-Kopierprogramm geschrieben welches den 
DPTR sowohl zum Auslesen des Bytes aus der Quelladresse als auch zum 
Schreiben des Bytes in die Zieladresse dient.

Ausgelesen wird mit MOVC A,@A+DPTR (Akku vorher auf #00h gesetzt) und 
geschrieben wird mit MOVX @DPTR,A (Ziel-EEPROM an /WR angeschlossen).

Ich habe das Programm so geschrieben dass im Fehlerfall die aktuelle 
Zieladresse ausgegeben wird - also den aktuellen Inhalt des DPTR.

Kurioserweise zeigt es immer 7180h an, egal an welcher Ziel-Adresse der 
Schreibfehler auftrat.


Ich bin das Programm schon mehrmals durchgegangen und habe auch 
versuchshalber DPTRH und DPTRL vertauscht aber dann zeigt es 8071h an, 
also ist der DPTR wirklich 7180h. Nirgends im Programm wird der DPTR 
verändert zur Laufzeit der Kopierschleife und der Überprüfung.

Das Kopierprogramm funktioniert übrigens einwandfrei wenn ich das 
Ziel-EEPROM (mittels Schalter) freigebe, der Fehler des falschen 
DPTR-Inhaltes tritt nur im Schreib-Fehlerfall auf.



Hat jemand eine Idee ?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
H-G S. schrieb:
> Ich habe das Programm so geschrieben
Dann wäre jetzt genau dieses Programm mitsamt der Ausgabe interessant. 
Denn darin steckt vermutlich der Fehler...

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Beachte auch, das bei MCS51 der DPTR auch als direkte Adresse (SFR) 82h 
und 83h angesprochen werden kann.

von H-G S. (haenschen)


Angehängte Dateien:
  • preview image for A.jpg
    A.jpg
    57,1 KB, 255 Downloads
  • preview image for B.jpg
    B.jpg
    92,3 KB, 269 Downloads
  • preview image for C.jpg
    C.jpg
    65,4 KB, 302 Downloads
  • preview image for D.jpg
    D.jpg
    43,3 KB, 170 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Das PAP ist übersichtlicher wie der handgeschriebene Assemblercode :-)

von H-G S. (haenschen)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Edit: ich habe B-b vergessen :-)

von Carl D. (jcw2)


Bewertung
2 lesenswert
nicht lesenswert
H-G S. schrieb:
> Das PAP ist übersichtlicher wie der handgeschriebene Assemblercode :-)

Wirklich?
Der Vorteil von Assemblercode im File ist, daß man sicher sein kann 
daß jemand ausdauernder und korrekter (asm51) ihn in Binärcode 
verwandelt hat.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
H-G S. schrieb:
> Das PAP ist übersichtlicher wie der handgeschriebene Assemblercode :-)

Nicht Dein Ernst?

von H-G S. (haenschen)


Angehängte Dateien:
  • preview image for 1.jpg
    1.jpg
    194 KB, 211 Downloads
  • preview image for 2.jpg
    2.jpg
    236 KB, 294 Downloads
  • preview image for 3.jpg
    3.jpg
    57 KB, 130 Downloads
  • preview image for 4.jpg
    4.jpg
    153 KB, 215 Downloads
  • preview image for 5.jpg
    5.jpg
    235 KB, 153 Downloads
  • preview image for 6.jpg
    6.jpg
    184 KB, 192 Downloads

Bewertung
1 lesenswert
nicht lesenswert
Hoffentlich findet ihr keinen Fehler in den Opcodes, denn dann schäme 
ich mich mindestens eine Woche lang :-)

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Ich fühl mich nach 1985 zurück versetzt.

Du mußt es schon als *.asm in einen Texteditor tippen, damit man es 
assemblieren und simulieren kann.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte das Keil-Toolset schon installiert, aber von Simulator keine 
Spur.

Jetzt war da auch noch dieser komische Trojaner den der Windows Defender 
aufgespürt hat ... ich musste alles plattmachen und Windows 10 neu 
installieren.

Ich hab jetzt Angst Programme runterzuladen, vor allem da die gefundene 
infizierte Datei dieses gratis "Gerbix" (?) Gerber-Betrachtungsprogramm 
war. Bestimmt ist auch meine externe Festplatte und auch die USB-Sticks 
infiziert - oweh oweh.


Bla Bla :-)

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
Mit großer Wahrscheinlichkeit ein (sporadischer) Bug im Assembler ;-)

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
H-G S. schrieb:
> ich musste alles plattmachen und Windows 10 neu
> installieren.

Einigen Leuten scheint es ja unbändigen Spaß zu machen, Windows neu zu 
installieren und daher legen sie absichtlich kein Systemabbild an, 
welches man in wenigen Minuten wieder eingespielt hätte.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Ich werde die Opcodes morgen selber durchgehen ... ich war zwar 
sorgfältig aber wer weiss.

Peter D. schrieb:
> Einigen Leuten scheint es ja unbändigen Spaß zu machen, Windows neu zu
> installieren und daher legen sie absichtlich kein Systemabbild an,
> welches man in wenigen Minuten wieder eingespielt hätte.

Ich traue dem Virenzeug nicht, Systemwiederherstellung klingt nicht 
sicher.

: Bearbeitet durch User
von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
So habe ich vor >35 Jahren versucht mir meinen eigenen Assembler zu 
basteln (der nie fertig geworden ist ist, weil ich dann doch was 
fertiges zum Hex-Abtippen bekommen habe).
Wie kommt man heute auf so eine Idee??

von Lothar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
H-G S. schrieb:
> Ich hatte das Keil-Toolset schon installiert, aber von Simulator keine
> Spur

SDCC? EdSim?

http://www.edsim51.com/

von Schorsch X. (bastelschorsch)


Bewertung
0 lesenswert
nicht lesenswert
H-G S. schrieb:
> Ausgelesen wird mit MOVC A,@A+DPTR (Akku vorher auf #00h gesetzt) und
> geschrieben wird mit MOVX @DPTR,A (Ziel-EEPROM an /WR angeschlossen).

Das klappt nur, wenn die Quelle im Programmspeicher und das Ziel im 
externen R/W Speicher gemeint ist...

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Schorsch X. schrieb:
> Das klappt nur, wenn die Quelle im Programmspeicher und das Ziel im
> externen R/W Speicher gemeint ist...

Ist es ! Das Ziel-EEPROM hängt an /PSEN und an /WR.


Ich habe jetzt alle Opcodes einzeln geprüft und auch den Speicherinhalt 
im Programm-EEPROM - da sind keine Fehler.

Auch habe ich versuchshalber das "ZielF" von verschiedenen Punkten 
angesprungen, also vor dem Kopieren und auch vor dem Bit7-Polling.

Jedesmal wurde "Fehler bei Adresse 7180" angezeigt, also DPTR soll 
angeblich immer 7180 enthalten.


Das deutet ja auf einen Fehler nach "ZielF" hin, also dem Teil der die 
Nibble des DPTR ausgeben soll. Das ist aber bewährter Code und 
funktioniert in meinen anderen Unterprogrammen auch. Das Low-Nibble des 
Akku wird mit "ANL #0Fh" isoliert und mittels Unterprogramm 
"HexNibbleChar" in einen Buchstabencode für das LCD umgewandelt.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
H-G S. schrieb:
> Systemwiederherstellung klingt nicht
> sicher.

Du verwechselst da was. Die Systemwiederherstellung restauriert nur die 
Systemdateien unter Beibehaltung der Userdaten, Registry (und Viren).
Das Systemabbild bügelt C: aber komplett über.
C: wird also in den Zustand zur Zeit der Erstellung des Abbilds zurück 
versetzt. Daher geht es auch viel schneller. Es wird nichts repariert, 
sondern 1:1 kopiert.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Das Systemabbild bügelt C: aber komplett über.
> C: wird also in den Zustand zur Zeit der Erstellung des Abbilds zurück
> versetzt. Daher geht es auch viel schneller. Es wird nichts repariert,
> sondern 1:1 kopiert.

Wie macht man so ein Abbild und wo speichert man es ?



Übrigens habe ich soeben beim Betrachten des Programms ab "ZielF" den 
Fehler gefunden!

Das Unterprogramm "LCDStringCopy" verändert den DPTR beim Kopieren des 
Textes der Fehlermeldung. Irgendwie lässt es dabei immer den Wert 7180h 
drin. Ich werde den DPTR wohl sichern müssen vor dem Kopieren.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
H-G S. schrieb:
> Wie macht man so ein Abbild und wo speichert man es ?

Google weiß da Bescheid, z.B.:

http://techmixx.de/windows-10-system-image-erstellen/

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
H-G S. schrieb:
> Das Unterprogramm "LCDStringCopy" verändert den DPTR beim Kopieren des
> Textes der Fehlermeldung.

Gerade in Assembler sollte man immer einen Funktionskommentar verfassen, 
wo auch die Registerbenutzung beschrieben wird.
Auch sollte man sich generelle Regeln aufstellen, welche Register zur 
Parameterübergabe benutzt werden und welche zerstört werden dürfen.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Gerade in Assembler sollte man immer einen Funktionskommentar verfassen,
> wo auch die Registerbenutzung beschrieben wird.
> Auch sollte man sich generelle Regeln aufstellen, welche Register zur
> Parameterübergabe benutzt werden und welche zerstört werden dürfen.

Das ist wohl auch das Beste...ich werde wohl am Ende des Projektes die 
Liste der Unterprogramme mit Notizen versehen müssen.


Ich habe das Programm ab "ZielF" so geändert dass anstelle des letzten 
DPTR die originale Ziel-Adress-Variable angezeigt wird. Jetzt 
funktioniert das EEPROM-Kopier-Unterprogramm richtig.

Das "LCDStringCopy"-Unterprogramm schnell zu ändern geht nicht da dieses 
recht komplex ist ... es testet die Übergabe-Variablen auf alle 
möglichen Grenzüberschreitungen - da müsste ich viele POP und PUSH 
einfügen. Vielleicht mache ich das später mal.


Edit: aha ... bei den Optionen zur Systemabbildsicherung kann man eine 
Reparatur-DVD erstellen. Ich habe mich schon gefragt wie man eine 
Festplatte unter Win10 formatieren kann :-) das musste ich früher sehr 
oft machen...

: Bearbeitet durch User
von H.Joachim S. (crazyhorse)


Bewertung
1 lesenswert
nicht lesenswert
H-G S. schrieb:
> ...ich werde wohl am Ende des Projektes die
> Liste der Unterprogramme mit Notizen versehen müssen.

Vergiss es. Wenn man es nicht gleich macht, macht man es nie.
Die Sache ist fertig, es funktioniert, der drive ist raus. Ausserdem ist 
einem alles sonnenklar - so klar, dass es gar nicht kommentierenswert 
wäre...

Bei mir zumindest funktioniert nur ein Weg: direkt und sofort. Auch bei 
jeder Änderung.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Nunja ... es ist das erste Projekt dieser Größenordnung für mich. Ich 
wusste gar nicht ob ich überhaupt ausreichend programmierfähig bin oder 
ob die Schaltung läuft wie sie soll.

Davor habe ich nur ein größeres C-Projekt am PC gehabt, wo ich einen 
Gelände-Editor zusammengepfuscht hatte aus vielen .h und .c Dateien. 
Schade dass ich alles aus Zorn weggeworfen habe damals als ich sah dass 
es unmöglich ist am PC vernünftig zu programmieren (ständiger Wandel, 
sehr komplex, Compiler etc. nicht anwenderfreundlich, kein Zugriff auf 
Hardware-Low-Ebene etc.).

Ich hatte auch mal ein kleineres Projekt am PC wo ich mir selber ein 
langsames DSO-Oszilloskop bastelte und über den Druckerport den Speicher 
einlas - heute undenkbar bei dem USB-Zeug.

: Bearbeitet durch User
von Soul E. (souleye)


Bewertung
0 lesenswert
nicht lesenswert
H-G S. schrieb:

> Hoffentlich findet ihr keinen Fehler in den Opcodes, denn dann schäme
> ich mich mindestens eine Woche lang :-)

Nimm doch mal Dein Hexfile und schieb das durch einen Disassembler. Den 
so erzeugten Sourcecode vergleichst Du mit Deinem Entwurf. Dann fallen 
falsche Opcodes sofort auf.


Zu Apple's Zeiten war das die übliche Arbeitsweise. Programm auf 
Karopapier entwerfen, mit dem Zaks in der Hand die Opcodes eintragen 
(irgenwann kannte man die auswendig), dann die Sprünge berechen 
(Hexadezimal kopfrechnen konnte man auch irgendwann). "CALL-151", 
Hexcode eintippen. Und dann mit dem eingebauten Disassembler anzeigen 
lassen und vergleichen.

Einen Disassembler hatte der Apple ][ eingebaut, einen Assembler hätte 
man zukaufen müssen. Und der belegt natürlich einen Teil des Speichers, 
in dem ja später das Programm laufen soll.

von Schorsch X. (bastelschorsch)


Bewertung
-1 lesenswert
nicht lesenswert
H-G S. schrieb:
> Ist es ! Das Ziel-EEPROM hängt an /PSEN und an /WR.

Das kann nicht funktionieren. Es gibt keinen Befehl um auf den 
Programmspeicher zu schreiben.

von H-G S. (haenschen)


Bewertung
1 lesenswert
nicht lesenswert
Schorsch X. schrieb:
> Das kann nicht funktionieren. Es gibt keinen Befehl um auf den
> Programmspeicher zu schreiben.

Ich benutze den /WR-Befehl für externe SRAMs, um in das Ziel-EEPROM 
(32kB) zu schreiben. Das Ziel-EEPROM ist in die obere SRAM-Hälfte 
reingemappt. Das System läuft mit 1MHz und die Timings scheinen zu 
passen. Dafür verwende ich den "MOVX @DPTR,A"-Befehl. Danach lese ich 
das Ziel-EEPROM aus und warte bis Bit7 des gerade geschriebenen Bytes 
noch invertiert angezeigt wird, also der Schreibvorgang noch nicht 
beendet wurde.

Übrigens kopiert das System 32kB in 4 Minuten in so ein Atmel 
32kB-parallel-EEPROM  :-)

Beitrag #5014166 wurde vom Autor gelöscht.
von Abbild (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Von Veeam gibt es eine freie Edition für den PC.
Funktioniert hervorragend und komfortabel.

Erkennt beispielsweise angesteckte Festplatten automatisch, macht ein 
Image ( differential / change Block Tracking) und hängt das Device 
danach wieder ab...

von Bernhard S. (b_spitzer)


Bewertung
0 lesenswert
nicht lesenswert
Sind (unter anderem) die ersten beiden Befehle wirklich so gemeint??

im PAP steht DPTRH = 38h, dein "Bleistift-Assembler" macht daraus mov 
83h, 38h. Du kopierst also den RAM-Inhalt aus 0x38 in den Data-Pointer. 
Wo kommt da der gewünschte Inhalt vorher rein??
Wenn der DPTR auf 3839h gesetzt werden soll, wären das die Befehle
mov 83h, #38h
mov 82h, #39h
Also nicht Opcode 85, sondern 75.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
DPTR kann man in einem Befehl laden:
mov dptr, #3839h ;90 38 39

von Schorsch X. (bastelschorsch)


Bewertung
-1 lesenswert
nicht lesenswert
H-G S. schrieb:
> Ich benutze den /WR-Befehl für externe SRAMs, um in das Ziel-EEPROM
> (32kB) zu schreiben. Das Ziel-EEPROM ist in die obere SRAM-Hälfte
> reingemappt. Das System läuft mit 1MHz und die Timings scheinen zu
> passen. Dafür verwende ich den "MOVX @DPTR,A"-Befehl. Danach lese ich
> das Ziel-EEPROM aus und warte bis Bit7 des gerade geschriebenen Bytes
> noch invertiert angezeigt wird, also der Schreibvorgang noch nicht
> beendet wurde.

Da ist aber nirgends der /PSEN verbaut. Vielleicht würde ein 
Schaltbildauszug etwas helfen. Die Fischerei im Trüben wird sonst immer 
schlimmer.
Wo kommen /CS /OE /WR (wohl vom 8051 /WR) her ?

von Soul E. (souleye)


Bewertung
0 lesenswert
nicht lesenswert
Schorsch X. schrieb:

> Wo kommen /CS /OE /WR (wohl vom 8051 /WR) her ?

Beim 8051 war es früher gängige Praxis, das RAM schreibend mit /WR und 
lesend mit (/PSEN or /RD) anzusteuern. Auf diese Weise wird es sowohl 
als Programmspeicher (über /PSEN = low) als auch als Datenspeicher (über 
/RD = low) eingebunden.


Aber das war nicht die Frage des TO, die Hardware als solche läuft ja.

von H-G S. (haenschen)


Bewertung
1 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> im PAP steht DPTRH = 38h, dein "Bleistift-Assembler" macht daraus mov
> 83h, 38h. Du kopierst also den RAM-Inhalt aus 0x38 in den Data-Pointer.
> Wo kommt da der gewünschte Inhalt vorher rein ?

Da fehlt ein Teil des Programms, in dem wird dann die Variable geladen. 
Es ist übrigens ein "Adresse-nach-Adresse-MOV", der scheinbar einzige 
MOV-Befehl beim 8051 wo die Operanden vertauscht im Speicher liegen. Das 
erhöht bestimmt die Ausführungsgeschwindigkeit, wenn der Prozessor 
zuerst die Quelladresse lädt und dann die Zieladresse.




Peter D. schrieb:
> DPTR kann man in einem Befehl laden:
> mov dptr, #3839h ;90 38 39

Stimmt, es gibt auch einen 1-Byte-Befehl um den Akku auf 0 zu setzen ... 
aber diese Befehle werde ich wohl erst in den nächsten Programmen 
einsetzen.



Edit: Ich bin übrigens bald fertig mit dem Projekt, es fehlt nur noch 
das Laden/Speichern in einen steckbaren Massenspeicher (serielles 
EEPROM). Damit kann man das gesamte EEPROM2 in Bänke speichern oder 
laden, zB. beim 512kB EEPROM wären es 16 Bänke. Wäre doch schade wenn 
ich das "Betriebssystem" der Kiste nochmal eintippen müsste, es sind 
mittlerweile bestimmt über 3000Byte  :-) Ich meine es waren um die 200 
Byte die ich pro Stunde reinswitchen kann mitsamt Validierung, könnte 
aber auch mehr sein da ich das Reinswitchen im Blut habe mittlerweile.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.