Forum: Mikrocontroller und Digitale Elektronik Suche Personen mit uPD7210 Erfahrung


von Jonas G. (upd7210)


Lesenswert?

Guten Tag,

ich bin zurzeit an meiner Bachelorarbeit und muss ein kleines Gerät 
entwickeln, welches ich überden GPIB (IEEE488.1, IEC625) ansteurn muss. 
Soweit so gut. Aus Restbeständen ist noch der uPD7210 vorhanden. Diesen 
habe ich mit Treibern und Arduino auf eine Platine gepackt. Dann habe 
ich den Arduino programmiert die Register dieses Controllers zu 
beschreiben. Gibt es hier überhaupt Personen die Erfahrung mit diesem 
Controller haben?

von STK500-Besitzer (Gast)


Lesenswert?

ist schn etwas her...
Was willst du wissen?

von Peter D. (peda)


Lesenswert?

Der uPD7210 läßt sich doch prima in den Data-Memory mappen, dann kannst 
Du die 8 Register direkt unter C ansprechen.
Du brauchst nur einen AVR mit Memory-Interface, z.B. ATmega162, 
ATmega2561.

von m.n. (Gast)


Lesenswert?

Peter D. schrieb:
> Du brauchst nur einen AVR mit Memory-Interface, z.B. ATmega162,
> ATmega2561.

Nicht unbedingt, denn auf den uPD7210 durfte nicht zu schnell 
zugegriffen werden. Daher ist es nicht von Nachteil, seine Schnittstelle 
per IO-Port und 'Bitwackeln' anzusprechen.
Weiterhin muß man beim Auslesen des Statusregisters aufpassen, weil die 
Bits beim Zugriff gelöscht werden. Deshalb muß der Status in einem Byte 
zwischengespeichert werden.
Das ist der Stand meiner Erinnerung, wie es vor 30 Jahren gemacht wurde 
;-)

von Jonas G. (upd7210)


Lesenswert?

Ich habe den uPD7210 in einer Schaltung mit dem Arduino Uno.

Ich habe einen Ablauf geschrieben um die Register zu beschreiben:

  R5W, B00000010 //Resets the chip and put it to idle

  R5W, B00101000 //Set counter to 8MHz

  R5W, B10100000 //Set fast Handshake

  R4W, B00110001 //Controller mode 1 (talk or listen)

  R6W, B00110101 //Controller gpib address 5

  R6W, B11100000 //Deactivate sekundary address

  R3W, B10110000 //Answer to serial poll with einself!!!111

  R5W, B01100101 //Answer to parallel poll with einself!!!111, mode:low

  //CHES and NTNL and DISTCT
  R5W, B01001011

  //EOS sign
  R7W, B00001101

  //Data receiving mode and EOS
  R5W, B10011100

  R1W, B00000000 //Unmask all interrupts

  R2W, ZEROBYTE //Unmask all interrupts

  R5W,ZEROBYTE //Take chip out of idle, lets rock!!!111einself


Also habe ich soweit ich sehe alle (notwendigen) Register beschrieben. 
Ich mache, nachdem die Daten angelegt wurden 10us Pause, damit der 
uPD7210 das Byte übernehmen kann. Das deckt sich soweit auch mit einem 
anderen Programm das mir zugekommen lassen worden ist. Einziger 
unterschied Adresse in Adress-Register 2.

Zum schreiben lege ich die entsprechende Register-Adresse an, und ziehe 
dan /CS auf LOW (CS), warte 10us, dann wieder HIGH.

Ich habe Testweise einmal alle Interrupts aktiviert. Wenn ich nun (über 
eine NI-Software einen Scan laufen lasse, wo die Software) ein *IDN? 
schicke, werden keine Interrupts gesetzt. Sprich, irgendwie will der 
uPD7210 nicht kommuizieren, es ist auch irgendwie Blöd das man ihn nicht 
wie einen Mikrocontroller auslesen kann.

von Ralph B. (rberres)


Lesenswert?

Jonas G. schrieb:
> Wenn ich nun (über
> eine NI-Software einen Scan laufen lasse, wo die Software) ein *IDN?

Da wirst du auch vermutlich nichts bekommen.

Der µPD7210 sorgt nur für das richtige Handshake zum Bus.

Die Befehle welches du sendest must du schon selber auswerten.


Ralph Berres

von Jonas G. (upd7210)


Lesenswert?

Ich wollte ja erstmal sehen ob ich etwas aus der anderen Seite von dem 
IC rausbekomme. Deswegen habe ich Probeweise alle Interrupts gesetzt, 
aber es wurde nie einer ausgelöst.

Daraufhin habe ich in dem AUXILIARYMODE-REGISTER einfach mal den INT auf 
active HIGH gesetzt. Siehe da, die INT-Leitung bleibt trotzdem LOW.

Ich habe langsam das Gefühl, ich mache etwas bei der Programmierung des 
ICs falsch.

Ich lege an RS0-RS2 die Adresse an, an /WR oder /RD die entsprechenden 
Register (Lesen oder schreiben) und /CS lege ich auch auf LOW. Dann lege 
ich das Byte an, warte zwischen 10us und sogar 1s, um dann /CS auf HIGH 
zu setzen und alles andere auch zu ändern.

So sollte doch die allgemeine Vorgehensweise sein oder habe ich das 
irgendetwas falsch Verstanden?

von pete (Gast)


Lesenswert?

Die Steuersignale sind aktiv LOW.
Zum Schreiben musst du erst die Daten ausgeben, bevor /WR und /CS 
aktiviert wird. Bei schnellen uP die Mindestzeiten beachten.
Beim Lesen nach Aktivierung von /RD ebenso die Mindestzeit (hold time 
o.ä. im Datenblatt) abwarten bevor Daten erfasst werden.

von Georg G. (df2au)


Angehängte Dateien:

Lesenswert?

Sieh dir mal das Timing Diagramm "CPU Write" an.
Die Daten werden vom uPD mit der steigenden Flanke von /WR übernommen. 
Erst danach und nach einer kleinen Wartezeit darfst du die 
Datenleitungen und /CS wieder verändern.

von Ralph B. (rberres)


Lesenswert?

Besitzt du das Buch IEC-Bus von Dr. Anton Piotrowski ISBN3-7723-6952-9 ?

Dort ist unter anderem die Programmierung des µPD7210 erschöpfend 
beschrieben.

Wer sich tiefer mit der Materie IEC-Bus befassen will, dem ist das Buch 
wärmstens empfohlen.

Ralph Berres

von Jonas G. (upd7210)


Lesenswert?

Das Buch besitze ich nicht, muss ich wohl mal anschaffen lassen. 
Vielleicht liegt da der Fehler, das ich /WR TRUE setze, und direkt 
dannach das Byte vom Bus nehme. Danke für den Hinweis, werde ich gleich 
Morgen mal probieren.

von Georg G. (df2au)


Lesenswert?

Jonas G. schrieb:
> /WR TRUE

In meiner Logik ist das Low Pegel. Hast du mal nachgemessen, ob deine 
aktiv-Low Signale wirklich aktiv-Low sind? Vertrauen ist gut, ...

von m.n. (Gast)


Lesenswert?

Ralph B. schrieb:
> Dort ist unter anderem die Programmierung des µPD7210 erschöpfend
> beschrieben.

Dann hast Du wohl eine neuere Ausgabe; in meiner (1982) steht da noch 
nichts drin.

> Wer sich tiefer mit der Materie IEC-Bus befassen will, dem ist das Buch
> wärmstens empfohlen.

So ist es!

Ohne jetzt wieder Alles aufzuwärmen, aber um dem µPd eine Reaktion 
abzutrotzen, sollte man ihn als Controller aktivieren ('take control' 
o.ä.). Daraufhin aktiviert er ATN asynchron zu anderen Ereignissen auf 
dem Bus.

Jonas G. schrieb:
> Vielleicht liegt da der Fehler, das ich /WR TRUE setze,

Die Information befindet sich im Datenblatt!

von Jonas G. (upd7210)


Lesenswert?

Also das auf der IEC-Bus-Seite sämtliche Signale aktive-Low sind weiß 
ich, deswegen auch /NRFD, /DAV, /D0-D7, .....

Auf der PC-Seite sind D0-D7 aktive-High, wie RS0-2 und dann gibt es 
aktive-Low wie /WR, /RD und /CS. Ich habe mit einem Oszi mal 
nachgeschaut und Bytes haben grundsätzlich den Zustand den sie haben 
sollen -> sprich Daten- und Adressbyte aktive-HIGH.

Im Datenblatt steht ja zb:
|----------------------|-------|------|------|------|------|------|
|Register              |  RS2  |  RS1 |  RS0 |  WR  |  RD  |  CS  |
|----------------------|-------|------|------|------|------|------|
|Data-Out Register (OW)|   0   |  0   |   0  |   0  |   1  |   0  |
|----------------------|-------|------|------|------|------|------|

Daraus folg ja:
|----------------------|-------|------|------|------|------|------|
|Register              |  RS2  |  RS1 |  RS0 |  /WR |  /RD |  /CS |
|----------------------|-------|------|------|------|------|------|
|Data-Out Register (OW)|   0   |  0   |   0  |   1  |   0  |   1  |
|----------------------|-------|------|------|------|------|------|
für das anzulegende Byte.


Next: TRUE setze und zu schnell das Datenbyte vom PC-Bus (CPU-Bus) 
nehme.

: Bearbeitet durch User
von Georg G. (df2au)


Lesenswert?

Jonas G. schrieb:
> Daraus folg ja:

Ich gestehe, dass ich nichts verstehe.

von Jonas G. (upd7210)


Lesenswert?

Entschuldigung das es so lange gedauert hat, aber mir sind die Feiertage 
dazwischen gekommen und eine Krankschreibung :O.

Ich habe den Controller erfolgreich ansprechen können mit folgendem 
Ablauf:

  8x pinMode(x, 1);    //Databus to output

  digitalWrite(WR PIN, 0);   //!WR Low -> WR High

  delayMicroseconds(1);

  8x digitalWrite(x, data[x]);   //Datenbyte an die Eingänge des UPD 
legen

  delayMicroseconds(1);

  digitalWrite(WR PIN, 1);   //!WR High -> WR Low

Sprich, schreiben aktivieren -> etwas warten -> Daten anlegen -> etwas 
warten -> schreiben deaktivieren.

Ich glaube der erste Controller den ich benutzt habe war defekt. Benutze 
mittlerweile den PIN und Softwarekompatiblen NAT7210.

Vielen Dank erstmal für die Hilfe, hatte die Timings im Datenblatt 
einfach knallhart überlesen :D

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.