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?
Gast
#4516842
ist schn etwas her... Was willst du wissen?
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.
Gast
#4517036
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 ;-)
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.
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
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?
Gast
#4518767
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.
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.
Angehängte Dateien:
-
Clipboard01.png
(3,8 KB)
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
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.
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, ...
Gast
#4518810
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!
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.
Jonas G. schrieb: > Daraus folg ja: Ich gestehe, dass ich nichts verstehe.
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.