Hallo zusammen! Bei meinem "Intel P80C51" (DIP 40) tut sich nichts an den Write und Read Anschlüssen. EA ist richtig beschaltet und Oszilloskop-Messung an den anderen Signalen sowie eine P3.0 Wechsel-Funktion parallel zum WR/RD zeigt Funktion an. Muss man vielleicht den Port 3.7 bzw. 3.6 irgendwie initialisieren ? Nach dem Reset ist der Port 3 auf FF.
Matthias S. schrieb: >> EA ist richtig beschaltet > > Will heissen? Auf externe Funktion bzw. ich sehe es gerade nicht weil unter Drähten versteckt. Aber der Prozessor holt sich sein Programm aus dem externen EEPROM und führt es richtig aus. Das Teil ist aus ebay ...
Sind denn in Deinem Code MOVX-Befehle? Nur diese steuern die Signale RD und WR.
Mario M. schrieb: > Sind denn in Deinem Code MOVX-Befehle? Nur diese steuern die Signale RD > und WR. Ja (MOVX A,@DPTR und MOVX @DPTR,A) - habe ich beides durchprobiert. Vor jedem dieser Befehle war ein Umschalten von P3.0 als Prüfmöglichkeit ob das Programm überhaupt tut was es soll (tat es).
Hülfe! schrieb: > Aber der Prozessor holt sich sein Programm aus dem externen > EEPROM und führt es richtig aus. Für das Ansprechen des Eproms ist das Signal /PSEN zuständig - /RD bzw /WR haben beim Epromzugriff keine Funktion (geteilter Adressraum Programmspeicher Datenspeicher). Mein Vorschlag: DPTR mit beliebiger Adresse, zB 0x8000, laden und den Inhalt dieser Adresse einlesen bzw in adressierte Speicherstelle schreiben. Gleichzeitig das Oszi auf ALE synchronisieren und /RD bzw /WR beobachten.
Lassen sich P3.6 und P3.7 auf 0 schalten? Könnte ja sein, dass die Ausgangstransistoren defekt sind. Andererseits sind die Impulse an /RD und /WR sehr kurz und im Vergleich zu /PSEN und ALE selten. Da muss der Trigger schon genau eingestellt sein. Zeitbasis z.B. auf 1 µs, Trigger auf single shot und dann am Triggerpegel drehen.
Hülfe! schrieb: > Aber der Prozessor holt sich sein Programm aus dem externen > EEPROM und führt es richtig aus. Da ist ja alles gut. Überprüfe mal deine Messmittel.
Hülfe! schrieb: > Muss man vielleicht den Port 3.7 bzw. 3.6 irgendwie initialisieren ? Nö, die Zusatzfunktionen sind AND verknüpft. Du kannst also auch jederzeit P3.6/7 per "CLR bit" auf 0 setzen. Wenn Du ne Schleife mit "CPL P3.6" programmierst, sollten 2,5V zu messen sein.
P3.6 (/WR) lässt sich per SETB/CLR umschalten. MOVX @DPTR,A geht weiterhin nicht. Ich habe Ersatz bestellt. Schade dass so ein Atmel AT89LP51 erst programmiert werden muss, damit er von 0000 aus dem externen EEPROM läuft. Ich hätte nämlich einen hier liegen.
Hülfe! schrieb: > P3.6 (/WR) lässt sich per SETB/CLR umschalten. > MOVX @DPTR,A geht weiterhin nicht. Was für`n Prozessor ist es denn überhaupt? Genaue Bezeichnung wäre nützlich und evtl. Foto.
Hülfe! schrieb: > Ich habe Ersatz bestellt. Schade dass so ein Atmel AT89LP51 erst > programmiert werden muss, damit er von 0000 aus dem externen EEPROM > läuft. Ich hätte nämlich einen hier liegen. Hat der keine /EA-Pin? Böse Falle. AT89S51 und AT89C51 konnte man noch direkt einsetzen. G. O. schrieb: > Was für`n Prozessor ist es denn überhaupt? Genaue Bezeichnung wäre > nützlich und evtl. Foto. Intel P80C51, steht doch im allerersten Posting. Also einer der Urahnen, ohne A am Ende. Aber immerhin schon CMOS. Wenn der TO verrät wo er ansässig ist kann ihm bestimmt jemand ein paar Exemplare aus seinem Fundus abgeben. Heutzutage sind die ja nur noch als E-Bedarf oder für Schul- und Ausbildungszwecke relevant.
Hülfe! schrieb: > Ich habe Ersatz bestellt. Ich vermute, das wird nichts bringen. Der Fehler wird eher bei Dir liegen, denn die Portpins sind ja nicht durchgebrannt. Hülfe! schrieb: > Schade dass so ein Atmel AT89LP51 erst > programmiert werden muss, damit er von 0000 aus dem externen EEPROM > läuft. Ich hätte nämlich einen hier liegen. Schreib das Programm einfach an 0x2000. Dann wird der leere Flash (0xFF) durchlaufen und dann das externe Programm ausgeführt. Nur für das Umleiten der Interrupts mußt Du den Flash programmieren, aber zum Testen brauchst Du keine Interrupts. Der Pin POL (formerly /EA) muß auf high gelegt werden oder RST auf high.
Peter D. schrieb: > Schreib das Programm einfach an 0x2000. Dann wird der leere Flash (0xFF) > durchlaufen und dann das externe Programm ausgeführt. Opcode 0xFF wäre zwar MOV R7, A aber der bräuchte wie ein NOP auch nur einen Maschinenzyklus, und wenn man seine Register zu Programmbeginn passend initialisiert, macht's auch nix, wenn der vorher 0x2000 Mal den gleichen Wert ins gleiche Register kopiert hat. Es sei denn, man hat eines der Exemplare, bei denen die Register bei Schreibzugriffen einem gewissen Verschleiß unterliegen. ;-)
Hülfe! schrieb: > P3.6 (/WR) lässt sich per SETB/CLR umschalten. > MOVX @DPTR,A geht weiterhin nicht. Es gibt noch eine weitere Methode die angesprochenen Signale zu aktivieren: MOVX @ri, a bzw MOVX a, @ri wobei mit ri entweder R0 oder R1 der aktuellen Registerbank gemeint sind. Allerdings sollte P2 vor Ausführung der genannten Befehle sinnvoll initialisiert sein. soul e. schrieb: > Intel P80C51, steht doch im allerersten Posting. Also einer der Urahnen, > ohne A am Ende. Nach meiner Kenntnis hat Intel keine CMOS-Prozessoren ohne Zusatz hergestellt. Daher die Nachfrage.
Durch die große Anzahl von verschiedenen 8051-Derivaten (>1000), ist es immer sinnvoll, die exakte und vollständige Bezeichnung zu posten.
Danke für die Hinweise! Ich warte aber lieber bis einer der bestellten Bausteine ankommt. Es ist übrigens ein P81C51FA1.
Hülfe! schrieb: > Es ist übrigens ein P80C51FA1. Der hat eine zusätzliche Compare/Capture Unit zum Einlesen der Raddrehzahlsensor-Signale. FA wurde ursprünglich für einen (damals amerikanischen) Automobilzulieferer entwickelt, dann aber allgemein vertrieben. Das Ding reagiert ganz normal auf /EA und erzeugt /RD, /WR. Wenn es das nicht tut ist es kaputt.
Ohmann... ohne euch gehts nicht weiter :-) Ich habe wie empfohlen den AT89LP51 durchlaufen lassen bis 2000h und der zeigt doch glatt das gleiche Fehlerbild (kein /WR) - der Pin P3.0 wechselte aber im Sekundentakt wie erwartet. Danach habe ich ausgiebig gemessen und festgestellt dass auch kein A15-Signal kommt. Ich habe auch alle Drähte von den Signalen abgeklemmt um Kurzschlüsse auszuschliessen. Es ist als wäre dieses MOVX aus dem angehängten Programm nicht existent. Solche Fehler darf es doch gar nicht geben oder ? Das sind die totalen Projekt-Töter.
Man könnte vielleicht noch den Befehls-Fetch überprüfen (dieses F0 des MOVX), aber da scheinbar das restliche Programm funktioniert wird das wohl auch zu nichts führen. Der P3.0-Wechsel wäre aber vielleicht als Trigger zu gebrauchen.
Hülfe! schrieb: > der Pin P3.0 > wechselte aber im Sekundentakt wie erwartet. der P3.0 wechselt in deinem Code wirklich im Sekundentakt - du siehst mal den low Pegel sehr lange anliegen, danach den high Pegel sehr lange anliegen. der WR verhält sich völlig anders: der wird immer nur für einen µs Puls lang aktiv, danach ist er für ca. 99,999% der Zeit inaktiv. Um diesen kurzen Puls zu erkennen musst du "genauer hinschauen" als um das schnarchlangsame toggeln des P3.0 zu erkennen. Hülfe! schrieb: > Solche Fehler darf es doch gar nicht geben oder ? Gibt es auch nicht, der Fehler liegt entweder an deiner Messung oder an deiner Konfiguration des Controllers. Hülfe! schrieb: > Ich habe wie empfohlen den AT89LP51 durchlaufen Der AT89LP51 kann MOVX Befehle entweder nach außen leiten oder auf sein integriertes XRAM. Setze sicherheitshalber das Bit EXRAM im AUXR-Register auf 1 - damit wird der gesamte Adressraum bei MOVX nach außen gemappt. Sobald du sicher bist, dass der Zugriff auch wirklich nach außen geht: ersetzte in deinem Code das setb b0 und das clr b0 in beiden Fällen durch die Sequenz: clr b0 setb b0 Damit bekommst du auch auf P3.0 nur noch kurze Pulse. Kannst du die mit deiner Messmethode erkennen? Dann solltest du auch die Pulse auf WR erkennen.
Achim S. schrieb: > der WR verhält sich völlig anders: der wird immer nur für einen µs Puls > lang aktiv, danach ist er für ca. 99,999% der Zeit inaktiv. Du scheinst recht zu haben: als ich ein kleines Programm getestet habe, dass nur 5 mal MOVX macht und dann zurückspringt, konnte ich die (600ns-) /WR-Pulse sehen! Ausserdem habe ich noch einen Schaltungsfehler gefunden, weswegen die Gesamtschaltung gar nicht funktionieren konnte. Ich habe zu allem Überfluss das EEPROM bei laufender Schaltung aus dem Sockel gefummelt! Es scheint aber noch zu funktionieren. Es gibt also noch Hoffnung - morgen aber erst :-)
Hülfe! schrieb: > Du scheinst recht zu haben: als ich ein kleines Programm getestet habe, > dass nur 5 mal MOVX macht und dann zurückspringt, konnte ich die > (600ns-) /WR-Pulse sehen! Na also. Vermutlich benutzt Du noch ein altes Analog-Scope. Schreib das beim nächsten mal gleich dazu. Und den Code, damit man sieht, daß MOVX nur alle Jubeljahre aufgerufen wird.
Peter D. schrieb: > Vermutlich benutzt Du noch ein altes Analog-Scope. Schlimmer: es ist so ein modernes Siglent-DSO :-) Ich kann mir gerade noch merken wie ich den Cursor zum Messen aufrufe ... Ich habe immer gehofft dass die 2Gs reichen um ein Spitzchen anzuzeigen aber bei 1s Zeitbasis verfehlt das wohl die Spitze. Man müsste wohl immer die Schleifenzeit reduzieren bei soetwas.
Hülfe! schrieb: > Man müsste wohl immer die Schleifenzeit reduzieren bei soetwas. Nö. Es reicht auf das gewünschte Signal zu triggern und die Zeitbasis halbwegs an das erwartete Signal anzupassen. Und in diesem speziellen Fall dann noch Trigger in Normal Mode (statt in Auto), damit in der ewig langen Pause zwischen den Pulsen die Messung nicht überschrieben wird.
Seltene Ereignisse immer in Normal oder Single Shot. Ich hätte an Deiner Stelle einfach ne Schleife aus MOVX und SJMP programmiert, dann kriegt man das auch in Auto prima getriggert. Was hat Dich geritten, zwischen den MOVX so elend lange Wartezeiten einzufügen?
Peter D. schrieb: > Was hat Dich geritten, zwischen den MOVX so elend lange Wartezeiten > einzufügen? Die Schleife löst etwas aus, dass man mit dem Auge noch verfolgen kann - also eine Aktion jede Sekunde.
Achim S. schrieb: > Nö. Es reicht auf das gewünschte Signal zu triggern und die Zeitbasis > halbwegs an das erwartete Signal anzupassen. Erklär das mal einem Informatiker. Die drücken auf STOP und zoomen rein.
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.