P80C51 gibt weder /WR noch /RD aus ?

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

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.

Da ist ja alles gut.
Überprüfe mal deine Messmittel.

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:

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

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

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

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.

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.