mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik P80C51 gibt weder /WR noch /RD aus ?


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.
Autor: Hülfe! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hülfe! schrieb:
> EA ist richtig beschaltet

Will heissen?

Autor: Hülfe! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Mario M. (thelonging)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Sind denn in Deinem Code MOVX-Befehle? Nur diese steuern die Signale RD 
und WR.

Autor: Hülfe! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: G. O. (aminox86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mario M. (thelonging)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: michael_ (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Hülfe! (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: G. O. (aminox86)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nachdenklicher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: G. O. (aminox86)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Durch die große Anzahl von verschiedenen 8051-Derivaten (>1000), ist es 
immer sinnvoll, die exakte und vollständige Bezeichnung zu posten.

Autor: Hülfe! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hinweise! Ich warte aber lieber bis einer der bestellten 
Bausteine ankommt.

Es ist übrigens ein P81C51FA1.

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hülfe! (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hülfe! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Achim S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hülfe! (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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   :-)

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hülfe! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Achim S. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hülfe! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

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.

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