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 ?
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...
Beachte auch, das bei MCS51 der DPTR auch als direkte Adresse (SFR) 82h und 83h angesprochen werden kann.
Das PAP ist übersichtlicher wie der handgeschriebene Assemblercode :-)
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.
H-G S. schrieb: > Das PAP ist übersichtlicher wie der handgeschriebene Assemblercode :-) Nicht Dein Ernst?
Hoffentlich findet ihr keinen Fehler in den Opcodes, denn dann schäme ich mich mindestens eine Woche lang :-)
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.
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 :-)
Mit großer Wahrscheinlichkeit ein (sporadischer) Bug im Assembler ;-)
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.
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
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??
H-G S. schrieb: > Ich hatte das Keil-Toolset schon installiert, aber von Simulator keine > Spur SDCC? EdSim? http://www.edsim51.com/
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...
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
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.
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.
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/
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.
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
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.
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
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.
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.
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 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...
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.
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 ?
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.
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
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.