Hallo Mitstreiter,
ich habe 1987 im Rahmen meiner Diplomarbeit eine normkonforme IEEE488 (DIN-IEC 66.22 / 625) für ein 6502 System entwickelt und nach einigen Versuchen mit einer Softwarelösung über die üblichen I/O Bausteine (MOS6522...) eingesehen, dass einige Forderungen der Norm ohne zusätzliche Hardware nicht zu erfüllen sind. Ich habe damals den GPIB Controller uP7210 eingesetzt.
Die Diskussion über die exakte Normeinhaltung ist aber eher akademisch. Commodore hat Gerätefunktionen wie z.B. den 64ms Timeout mit Schnittstellenfunktionen vermisch - das Ganze sollte halt irgendwie funktionieren.
Der 64ms Timeout hat übrigens überhaupt nix mit der Norm zu tun, normkonforme Schnittstellenfunktionen warten auch auf extrem langsame Listener/Talker ohne abzubrechen.
<br><blockquote username="Diddl" linkhref="'index.php?page=Thread&postID=520554#post520554'">Ne aber ich möchte mit einem IEEE-488 slave die IEEE-488 Normen möglichst gut einhalten.<br><br>Das soll auch sicher funktionieren wenn grad ein SPI Transfer von der SD Karte und/oder ein Timer Interrupt läuft. <br><br><br>Nicht so wie die Commodore Festplatten, wo man 2€ für ein paar Gatter gespart hat, und beim 8032 das Timeout mit dem POKE ausschalten muss, damit nicht immer zwischendurch das "device not present error" kommt ...</blockquote>
Also ein paar Informationen zum "ATN Problem" 
- Am IEEE488 Bus kann nur ein Controller, nur <b>ein </b>Talker aber <b>mehrere </b>Listener parallel ardessiert sein. In der Regel gibt es aber Geräte, die nicht adressiert sind und sich bei den normalen Datenaustausch am BUS neutral verhalten müssen. Wenn z.B. ein CBM8032 als Listener Daten von einer CBM2031 Floppy empfängt, nimmt ein am Bus angeschlossener, aber nicht adressierter Drucker nicht am Dreidraht-Handshake teil.
- Das Dreidraht-Handshake ist so konzipiert, dass schnelle Geräte einwandfrei mit sehr langsamen Geräte kommunizieren können. Das Commodore Timeout sorgt nur dafür, dass nicht ewig gewartet wird, wenn sich ein Teilnehmer 'aufgehangen' hat.
- Wenn der Controller Befehle an die Geräte schicken will, setzt er ATN auf low. Das kann völlig asynchron zu einem gleichzeitig stattfindendem Datenaustausch passieren. Auf ATN = low werden <b>alle Geräte am Bus Listener</b> und dass wiederum muss zuverlässig synchron zu ATN stattfinden. Deshalb sieht die Norm vor, dass alle Geräte als Reaktion auf ATN=low das Listerner Handshake initialisieren und innerhalb von <b>200ns NRFD und NDAC ebenfalls auf low</b> bringen.
- 200ns is so kurz, dass es unmöglich ist, dass ein sehr schneller Listener schon Daten von Controller abholt, während langsame Listener noch nicht zum Handshake bereit sind. 200ns sind aber mit Programmierung auf einem MCU nicht einzuhalten. Das geht nur z.B. mit Gattern wie z.B. bei der CBM2031, einem speziellen IEEE488 Buscontroller (z.B. uP7210) etc.</li><li>Auch professionelle USB-IEEE488 Devices wie z.B. der Prologix USB-GPIB Controller halten das nicht ein.
Grosse Frage!! Ist das in der Praxis überhaupt von Bedeutung?
- Nein, solange alle Geräte NRFD und NDAC auf low bringen, <b>bevor </b>der schnellste Listener sein NRFD wieder auf high setzt und Empfangsbeteitschaft zu signalisieren, passiert garnichts. Nach meiner Erfahrung dauert das i.d.R. mehrere 100us. D.h. wenn ein Gerät auf ATN=low innerhalb von 2-5 us antwortet ist erfahrungsgemäß noch alles o.k.Besonders in der Commodorewelt.
- Unten seht ihr, dass eine CBM2031 ungefähr 540us benötigt um NRFD wieder auf high zu setzen.
