www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik HP-IB und AVR


Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab diverse HP-Komponenten (HP-Rechner; Plotter; Diskettenlaufwerke 
und Kabel) in Verwendung, welche recht gut laufen, aber halt in die 
Jahre gekommen sind. Ich würde gerne mittels AVR einige Komponenten 
ersetzen (z.B. den Plotter um die Druckdaten direkt auf SD-Karte 
ausgeben).

Ich hab mich etwas in den HP-Bus eingelesen und würde gerne mir ne 
Interfacekarte zur Ansteuerung bauen. Der Bus ist ja laut IEC-625 bzw 
IEEE-488 TTL und somit "pinkompatibel" um nen AVR direkt an den Bus zu 
klemmen.

Wichtig wäre mir mal die Floppylaufwerke und die Disketten. Letzteres 
würd ich gerne auslesen und am PC abspeichern für Sicherungszwecke 
(Disketten sind nicht PC-Kompatibel, daher das Auslesen über Umwege) um 
diese später zurückzukopieren (auf neue Disketten).

Ich hab auch ein paar Projekte hier angeschaut, welche sich mit dem GPIB 
(HP-IB kompatibel) beschäftigen. Nur find ich leider nirgends die Info 
(Steuercodes) wie ich z.B. ne Diskette über das HP-Drive (9122) auslese.

Hat jemand ein ähnliches Projekt bzw kann mir jemand helfen?

Grüße und frohe Weihnachten
Alex

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich musste letztens für die Schnittstellenkarte eines Messgerätes die 
Firmware neu schreiben, bin da mittlerweile, nach einigen Problemen, 
also gut drin.

Zum IEEE488 gibt es ein gutes Buch, nennt sich einfach "IEC-BUS", Autor 
habe ich gerade nicht im Kopf, habe mein Exemplar gerade verliehen...
Ein wenig findet man auch im "Schnittstellen-Handbuch" von 
J.Elsing/a.Wienncek. DAs gibt es öfter auch mal bei Ebay für 1 eur...
Ansonsten ist auch fast alles bei NI auf den Internetseiten zu finden.

Bei der Umsetzung direkt mnit dem Atmega wirst du aber Probleme 
bekommen. So einfach wie es aussieht ist es nicht!
Zum einen gibt es definierte Aussagen zur erlaubten Belastung des Busses 
und zu minimal möglichen Stromabgabe. Ich bin mir nicht scher ob der 
Atmega das dann so kann.
Aber das ist nur das allerkleinst Problem. ICh würde da einfach, je nach 
deinem Schaltungskonzept, einen Bustreiber wie dem 74H245 vorsehen.

Das Problem liegt in der Tatsache begrpndet das der Bus sich zwar immer 
am langsamsten Gerät orientiert, man theoretisch also fast mit DIP 
schaltern und Tabelle takkern könnte, es aber in der Beschreibung eine 
Zeitkritische Vorschrift gibt!

Es ist spezifiziert das der BUS, welcher ja bi-direktional ist, nach 
erhalt des ATN Steuersignals innerhalb von 200ns reagieren MUSS 
(Antwortzeit). Dies umfasst auch die evtl. Umschaltung des 
Bidirektionalen Datenbusses von Senden auf Empfangen.
Findet diese Antwort zu langsam statt kommt es evtl. zu Fehlfunktionen!
Im Schlimmsten Fall zur Zwerstörung deiner Hardware falls auch die SE 
Umschaltung zu langsam ist, da dann die Treiber zweier Geräte 
gegeneinander Treiben!
Da dieser ATN Befehl jederzeit plötzlich auftreten kann muss man immer 
vom schlechtesten Fall ausgehen, das bedeutet das nach den 200ns bei 
20Mhz Taktfrequenz maximal genau ein befehl abgearbeitet ist.
Im besten Fall ist die CPU also gerade am Kopf der Interruptroutine 
gesprungen. Das kann so also nicht funktionieren.

Daher ist es also alles andere als Trivial!

Es gibt nun drei mögliche Lösungswege:

1. Da eine Atnwortzeit von 200ns bei einführung des IEEE-BUSSES durch 
reine Software absolut Illiusorisch war,  teilweise war 1,xx MHz 
Quarztakt noch die Regel, vom Befehlszyklus ganz zu schweigen..., hat 
man spezielle Controller entwickelt die den ganzen ablauf erledigen. Man 
übergibt nur noch die Daten an den Controller, der übernimmt den ganzen 
Ablauf. (Also zum beispiel das was heute auch Controller wie der 
ENC28J60 für Ehternet machen)
Bei diesen Controllern ist der TEil welcher die Reaktion auf das ATN 
Kommando realisiert als "State Maschine" (LOGIK) auf dem Chip 
integriert, der sonstige Ablauf wird von einem Prozesorkern übernommen.
Diese Controller sind auch heute noch verfügbar und gut dokumentiert. 
Aber recht teuer. Mit etwas Glück aber in auszuschlachtenden IEEE488 
fähigen Geräten zu finden. (Gab nur eine Handvoll Standart-ICs)

2. Du nimmst statt einem Atmega einen IC der Schnell genug ist um das zu 
realisieren. Evtl. könnte das bei sehr effizienter Programmierung ein 
flinker ARM als Beispiel. Wenn das nicht reicht bleibt auch noch der 
Griff zum FPGA!

3. Die dritte Lösung ist diejenige welche auch auf der Steuerkarte 
welche ich bearbeitet habe realisiert war. Es wird einfach der Aufbau 
eines Controllers halbdiskret nachempfunden. Du nimmst einen beliebigen 
µC, zum beispiel irgendeinen AVR, mit genug Ports der die normale 
Programmabarbeitung übernimmt. Das Programm muss aber dann das gesamte 
Protokoll sauber beherrschen. ISt schon etwas Knobellei, aber machbar.
Extern baust du mit Logikgattern dann eine StateMaschine, welche bei 
erhalt eines ATN Signals einmal einen Interrupt im µC auslöst, 
andererseits aber automatisch die Busrichtung umkehrt. Auch das ist 
etwas Tricky da es ja nicht reicht einfach innerhalb von ein paar ns 
z.b. einen 74HC245 umzupolen, dann würden ja CPU und Treiber 
gegeneinander treiben, aber mit Gehirnschmalz machbar. (Mir liegt 
natürlich eine Lösung hier vor, aber mehr darf ICH dazu aber an dieser 
Stelle nicht schreiben das sind dann Interna...Denke aber das die 
Hinweise ausreichen sollten ;-) )

Gruß
Carsten

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Carsten,

danke erstmal für Deine Erläuterungen! Klingt interesannt!

Was ich aber nicht verstehe ist, das die Geräte selber nichtmal 8MHz 
haben und mit Leitungslängen von 100m haben dürfen. Ich denke die 200nS 
sind bei denen hier (BJ <1990) wohl weniger kritisch, da bei der Antwort 
von nem Floppy schon mehr als 200nS dauert (oder irre ich mich da?). Ich 
hab in den Gertäten (hab mal nen Floppy zerlegt) nur 74xx595 in Dil. 
Damit wird wohl keine schnelle Umschaltung möglich sein, oder?

Ich könnt doch beim AVR über nen Interrupt den Ausgang zwingen zum 
Eingang zu werden, um ein gegeneinandertreibe zu verhindern. Notfalls 
würde es ein CPLD tun, welcher als "Bustreiber" die Vorlogik übernimmt.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alex,

KLEINER DENKFEHLER bei dir...
Die 200ns sind seit den 70ern, also bereits seit Einführung des IEEE488 
Busses relevant! Damit ist auch nicht gemeint das eine Antwort bereits 
200ns nach setzen der ATN Leitung beim Master ankommen muss...

Es ist gefordert das 200nS nach Änderung des Pegels der ATN Leitung an 
der jeweiligen Schnittstelle des Devices ein Zustand AN DIESER 
SCHNITTSTELLE hergestellt werden muss der dem  Empfangsstatus 
entspricht. Die Laufzeiten durch Leitungslängen sind somit hier nicht 
relevant...
Es ist war, das insbesondere bei den alten Geräten, kaum (eher kein) ein 
Gerät bereits 200ns später die Befehler verarbeiten könnte. Aber alle 
Geräten haben in dieser Zeit ihre Treiber auf dem Datenbuss und den 
Steuerleitungen (mit ausnahme der OC Treiber auf den Handshake Leitungen 
NRFD und NDAC) abgeschaltet. Egal in welchem Zustand sie sich vorher 
befanden! Und genau das bekommst du in Software mit einem kleinen 
(langsamen) µC wie dem AVR niemals hin.

Dafür nimmt man deshalb dann die Logik... Entweder wirklich mit 74er 
Bausteinen diskret aufgebaut oder halt im CPLD, GAL oder FPGA.
Wenn du mit CPLDs umgehen kannst würde ich doch einfach in diesem einen 
Bidirektionalen Bustreiber, der aber auch einen Tri-State Zustand kennt 
implementiren. Ausserdem noch eine State-Maschine die bei Empfang des 
ATN Signals den Treiber in den TriState Zustand schaltet, den Prozessor 
einem Interrupt mitteilt und dafür sorgt das solange der Prozessor noch 
nicht bereit ist keine Daten ankommen...  (War da nicht was mit NRFD...? 
;-) )
Statt mit einem CPLD kann man das natürlich auch mit Standart 
Logikbausteinen machen, ist nur etwas mehr verdrahtungsaufwand. Das ist 
auch genau das was in den normalen integrierten IEEE488 Controllern 
passiert. Wie gesagt, die haben einen getrennten CPU und Logik-Kern!
JETZT Musst du aber alleine auf den Rest kommen...

Ach ja- mit Logikbausteinen wie den 74xxx595 sind deutlich schnellere 
REaktionen als 200ns möglich!

GRuß
Carsten

P.S.: War die zulässige Leitungslänge wirklich 100m? Ich habe da eher 
etwas mit 15m im Kopf... Bin aber da nicht sicher, die HW Specs waren 
nicht mein Bereich, da die ja bereits bestanden, nur die Firmware hat in 
Verbindung mit HS488 fähigen Geräten ein Problem verursacht... Daher 
habe ich das jetzt nicht so im Kopf - und jetzt auch keine Lust das 
nachzuschlagen...

Autor: Om Pf (ompf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex W. schrieb:

> Ich würde gerne mittels AVR einige Komponenten
> ersetzen

Hier ist ein Beispiel für einen GPIB nach USB-Umsetzer: 
http://lpvo.fe.uni-lj.si/gpib/ (guckst Du unter self-build)

Ich habe die Schaltung vor einiger Zeit modenisiert und etwas 
überarbeitet (mit ATmega16 und FT245R), von den Dingern haben wir privat 
und in der Firma ein Dutzend im Einsatz.

Statt des FTDI kannst Du natürlich auch eine SD-Karte oder ein Display 
dranbasteln.


> Ich hab auch ein paar Projekte hier angeschaut, welche sich mit dem GPIB
> (HP-IB kompatibel) beschäftigen. Nur find ich leider nirgends die Info
> (Steuercodes) wie ich z.B. ne Diskette über das HP-Drive (9122) auslese.

Das sind zwei Baustellen. Erstmal musst Du das GPIB-Busprotokoll 
umsetzen. Das ist ein Parallelschnittstelle mit Handshake. Wie 
Druckerport, nur umständlicher. Die physical layer hat TTL-Pegel, kann 
aber deutlich mehr Strom treiben.

Dann brauchst Du den Befehlssatz Deines Gerätes. Das können 
Hexadezimalzahlen sein (die Logikgatter treiben), oder ASCII-Zeichen 
("!0099200000\r", "CF100M;SPAN1M;PLOT\n\r"), die von einen Prozessor 
interpretiert werden. Genormt ist da genau gar nix, auch wenn es mal den 
Versuch einer Standardisierung (IEEE488.2) gab. Damit kannst Du die 
passenden Kommandos abschicken und die Antwort auswerten.


Gruß
Patrick

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube auch nicht das die 200ns kritisch sind. Der Prologic USB-GPIB 
Adapter hat z.B. auch einfach einen ATMega ohne weitere Schnittstellen 
Bausteine drin.
Zur Not baut man sich halt noch einen "echten" Open Collector Ausgang 
mit Transistoren dran, dann kann nichts schlimmes passieren.

Ein AVR Projekt gibt es z.B. hier:
http://www.spurtikus.de/basteln/gpib.html

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem schaut viel entschaerfter aus, wenn man einen Busmaster 
machen muss. Wenn man also dem PC durch einen AVR ersetzen will. Ich bin 
auch in diesem Prozess, aber noch nicht abgeschlossen.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
O.. oha Jetzt ! schrieb:
> Das Problem schaut viel entschaerfter aus, wenn man einen Busmaster
> machen muss. Wenn man also dem PC durch einen AVR ersetzen will. Ich bin
> auch in diesem Prozess, aber noch nicht abgeschlossen.

Wenn man sicher ist, das man definitv nur den einen selbstgebauten 
Master im System hat, dann ist das tatsächlich kein Problem. Mann muss 
nur dafür sorgen das man selbst langsam genug ist...

Sobald aber auch nur die Möglichkeit besteht das mehrere Geräte die 
Master-Funktion übernehmen können, sollte man sich tunlichst an die 
Specs halten.
Sonst hat man schneller einen Hardware-Defekt als man denkt. Im besten 
Fall auf seiner eigenen Hardware, den Fehler findet man schnell...
Aber wenn der Treiber im anderen Gerät schneller den Geist aufgibt, dann 
viel Spass. Und das es 1000mal gut geht wenn die zwei Treiber für ein 
paar µS gegeneinader Treiben bedeutet nicht, das es auch das 1001mal 
klappt!

Eine saubere Lösung kostet nicht mal einen Euro an Bauteilen, die man 
selbst beim Elektronikkrämer um die Ecke bekommt, mehr...
Warum also dieser Aufstand und Probleme riskieren?

Gruß
Carsten

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal die Bausteine  75161 / 75162 an.

http://focus.ti.com/lit/ds/symlink/sn75162b.pdf

Die sind dafuer gemacht.

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Regel ist aber der PC der Master. Und wenn ein anderes Gerät den 
Master spielen will oder soll, muss er entweder explizit von vorne 
herein als Master eingestellt sein ( z.B. als nur Talker ) oder ermuss 
vom Master  ( sprich PC ) dazu aufgefordert werden. Es gibt aber in der 
Praxis kaum Fälle, wo der PC vorübergehend seinen Master an einen 
anderen Busteilnehmer abgibt.

Die 200ns sind in der Tat dann kritisch, wenn mehrere Master auf einem 
Bus beteiligt sind. Bei reinen Talker und Listnerfunktionen gibt das 
langsamste adressierte Gerät den Bustakt an, bis er wieder vom Master 
deadressiert wird.

Es gibt eine Reihe von IEC-Bus Controller ( die aber wohl alle schon 
lange abgekündigt wurden ). Nec upd7210 und Texas Instruments TMS9914 
sind wohl die bekanntesten. Von National Instruments ist wohl ein 
Ersatzchip, welcher gut dokumentiert ist erhältlich. Es nennt sich 
NAT7210 und ersetzt die beiden zuvor genannten Chips. Leider gibt es die 
nur im Pack von 9 Stück zu einen Preis von deutlich über 200 Euro. 
Früher konnte man von National Instruments ein Entwicklungskit mit 2 
Stück erwerben. Aber das Angebot scheint es nicht mehr zu geben.

Die Alternative wäre in der Bucht irgend eine alte Isabus IECbus Karte 
für wenig Geld zu erwerben. Da ist meistens noch der NEc upd7210 darauf 
und auch die Treiber SN75160 und SN75162 die man auch benötigt.

Der Treiber muss einen Strom von 48mA treiben können und hat für die 
Handshakeleitungen zwingend Opencollector und für die Datenleitungen auf 
hochohmig schaltbare Ports. Damit kann man dann 15 Geräte am Bus 
betreiben.
Die maximale zulässige  Länge des gesamten Busses beträgt 20 Meter.
Die Gerätebefehle ( auch Mehrdrahtbefehle genannt sind standarisiert 
IEEE488-1 und später mit den Befehlen *IDN usw IEEE488-2, für die 
Befehle der Teilnehmer hat sich die Sprache SCPI hearauskristallisiert.

Was das HS488 Prodokoll von National Instruments betrifft, ist es ein 
verzweifelter Versuch den IEC Bus noch schneller zu machen in dem es in 
den Dreidraht Handshake eingreift und nicht mehr zwingend wartet bis der 
langsamste seinen Bus geräumt hat. Es hat jedenfalls nur Probleme 
bereitet.



Ralph Berres

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>75162

Danke fuer den Tip.
Digikey hat's im Angebot : 2.80$, aber nicht an Lager
Mouser international hat's fuer 5.86$ und an Lager.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist nicht zwingend, dass der PC der Master ist. Ich bin zB an einem 
System, wo wir einen Frequenzzahler haben, den ich mit einem AVR 
auslesen moechte. Da ist kein PC, der das machen wuerde. Zudem moechen 
wir mit dieser Zaehlgroesse einen Prozess steuern... ein AVR ist in 
diesem Fall einfach besser geeignet. Der Zaehler hat leider nur IEEE488.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
75160 (Datentreiber) und 75161 (Steuerleitungstreiber) gibt es bei 
Reichelt.
Den 75162 leider nicht.

Die Teile haben zum Bus hin Opencollector Ausgaenge. Sollte eigentlich 
nix passieren.

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
O.. oha Jetzt ! schrieb:
> Es ist nicht zwingend, dass der PC der Master ist. Ich bin zB an einem
>
> System, wo wir einen Frequenzzahler haben, den ich mit einem AVR
>
> auslesen moechte. Da ist kein PC, der das machen wuerde.

Dann muss der Zähler aber als only Talker eingestellt werden. Damit wird 
er zum Master. Sonst geht es nicht.

Ralph Berres

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei die Diskussion hier im Thread ja nur theoretisch ist...
Denn der TE möchte ja definitiv ein SLAVE Device bauen. Somit sind die 
200ns einzuhalten.

Nur wenn man wie im Beispiel angegeben etwas wie den PC-USB auf IEEE-488 
umsetzer bauen will - und Sicher ist das kein anderes Gerät eine Master 
funktion übernehmen soll, zum beispiel der PC nur als Datenlogger für 
einen als Master funktionierenden Funkmessplatz (ein Anwendungsbeispiel 
hier bei mir)arbeiten soll, dann könnte man auf die 200ns Spec. 
verzichten...
Es sind übrigends definitv NICHT alle Leitungen mit OC Treibern 
bestückt! Das ist nur bei Steuerleitungen der Fall, da daort ja OC als 
einzig funktionierendes Konzept möglich ist, denn immerhin können hier 
bis zu 15 Geräte auf ein Signal zugreifen und nur wenn alle Geräte 
dasselbe Signalisiseren das das Signal gültig sein. (Halt ein 
AND-Verhalten)
Das geht halt nur mit OC... Bei den Datenleitungen haben viele Devices 
kein OC Verhalten beim Senden!

Ach ja, zu dem Tip mit den alten ISA Karten....
ICh habe gerade mal geschaut was bei mir so im Arsenal ist:
Bei einer NI-GPIB-PCIIA Rev.A  (Assy180810-01) befindet sich ein 
NEC7210C sowie jeweils ein DS75160 und DS75162 auf der Karte.

Bei einer NI-GPIB-PCII/IIA- Rev.D  (Assy181065-01) befinden sich zwar 
jeweils ein DS75160 und DS75162 auf der Karte, aber anstelle des NEC une 
deiner Menge Logik Gatter nur ein PLCC Baustein von VLSI solution auf 
der Karte.

Bei einer 488-PC2 Karte Rev-3 von "ICS Electronics Corporation" sind so 
wie bei der ersten NI Karte auch der 7210C und die 75160/75162 verbaut.
Die sonstigen ISA Karten sind momentan alle Verbaut. Und bei den PCI 
karten braucht man gar nicht erst schauen. (Wobei da der PReis sowieso 
uninterressant ist für eine reine Bauteilspende!)

So, jetzt ruft die Familie, weiteres frühestens Morgen!

Gruß
Carsten

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Denn der TE möchte ja definitiv ein SLAVE Device bauen. Somit sind die
>
> 200ns einzuhalten

Carsten da irrst du.

Nur wenn die Karte als Master benutzt wird, muss sie die 200nS 
einhalten.
Und auch nur dann wenn das vermurkste HSS488 Prodokoll von National 
Instruments benutzt wird.

ATN ist die Leitung die den angeschlossenen Geräten mitteilt ob ein 
Mehrdrahtbefehl ( IEC-Bus Adresse z.B. ) oder ein Gerätebefehl gesendet 
wird. Der Master nimmt den ATN erst dann zurück, wenn das zu 
adressierende Gerät über die Handshakeleitungen den Mehrdrahtbefehl 
bestätigt hat. Es geht also immer die Richtung von PC ( Master ) in 
Richtung Gerät ( Listner/ Talker ). Erst wenn der PC ( Master ) einen 
anderen Teilnehmer als Master deklarieren will, muss er aufpassen, weil 
dann seinerseits der neue Master die Kontrolle über die ATN Leitung 
übernimmt.

Ralph Berres

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die NAT9914 gibts gerade beim ebay, habe auch schon welche gekauft für 
den GPIB USB Agilent 82357B clone.

National Instruments hat sehr interessante preise auf der website, mit 
USA in den Landeinstellungen kosten die 9stk 149$, mit Deutschland 
249EUR.
Da hat wohl einer super umgerechnet.

ISA karten mit 7210 gehen natürlich auch, bloss keine "unbekannte" 
geräte wie der Philips 9547 (G) kaufen, da gibts nur grütze drin und 
kein richtiges GPIB controller, siehe:

http://www.eevblog.com/forum/index.php?topic=2025.0

Die bus treiber z.zt. nur über Reichelt verfügbar, den 75161 kann man 
zur 99.9% ohne weiteres als ersatz für 75162 nehmen.

Autor: Om Pf (ompf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas R. schrieb:

> ISA karten mit 7210 gehen natürlich auch, bloss keine "unbekannte"
> geräte wie der Philips 9547 (G) kaufen, da gibts nur grütze drin

Der PM9547 ist ein I2C-to-GPIB - Konverter und gehört zum 
Videosignalgenerator PM5518. Das Ding ist zum schlachten ein bisschen zu 
teuer.

Philips hat den GPIB eigentlich immer mit solchen CMOS-Gräbern 
realisiert. Der PM9696 für die Frequenzzählerserie PM66xx schaut ähnlich 
aus.


Gruß
Patrick



BTW: wer ein PM9696 loswerden will, bitte melden

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph Berres schrieb:
> Carsten Sch. schrieb:
>> Denn der TE möchte ja definitiv ein SLAVE Device bauen. Somit sind die
>> 200ns einzuhalten
>
> Carsten da irrst du.
>
> Nur wenn die Karte als Master benutzt wird, muss sie die 200nS
> einhalten.
> Und auch nur dann wenn das vermurkste HSS488 Prodokoll von National
> Instruments benutzt wird.
> ...
>
> Ralph Berres

Nee, Ralph, ich habe da schon recht, der Denkfehler liegt bei dir ;-)

Und das hat auch nix mit dem HS488 Protokoll zu tun, denn die Doku 
welche welche die 200ns vorgibt ist ca. 20Jahre vor dem HS488er 
Protokoll entstanden.
Und es sind einzig und allein diese 200ns, weshalb überhaupt alle welt 
diese IEEE488 Controller einsetzte und auch noch bis heute einsetzt. 
Ohne die 200ns Anforderung hätte es ja ein simpler 8080, 8049,Z80 oder 
was auch immer für weniger als 10% der Kosten getan...

Die Funktion des ATN ist mir schon klar...
Ja, der Master setzt den ATN Befehl, was bedeutet das als nächstes ein 
BEFEHL (ggf. nichtadressiert) übertragen wird.
Dieses Auftreten des ATN Befehls hat höchste Priorität und kann 
JEDERZEIT passieren. Somit kann es eine laufende Datenübertragung 
unterbrechen!

Und die Spec schreibt nun vor, das ein Device, welches einen ATN Befehl 
ERHÄLT 200ns später nicht mehr den Bus treiben darf. Auch wenn es gerade 
im Sendemodus war... Dies- und nur dieses "Nicht mehr treiben", ist das 
kritische. Der Slave macht selber gar nichts mit dem ATN Signal, er 
bekommt es nur und schaltet seine Treiber ab. Ausserdem werden 
unverzüglich die beiden anderen Handshakeleitungen (NDAC und NRFD) 
zurückgesetzt, denn die können ja bis zum erhalt des Befehl ein "Klar" 
Signalisieren. Spätestens 200ns NACH ERHALT dieses Befehls darf das aber 
nicht mehr der Fall sein... Die spätere Abwicklung des Befehls hat gar 
nichts mehr mit den 200ns zu tun und kann (wird!) viel viel langsamer 
erfolgen...

Das der Master aber selbst bestimmt wann er den ATN Befehl setzt ist er 
das einzige Device am Bus für das die 200ns Vorgabe ebend NICHT gilt!

Gruß
Carsten

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Und die Spec schreibt nun vor, das ein Device, welches einen ATN Befehl
>
> ERHÄLT 200ns später nicht mehr den Bus treiben darf. Auch wenn es gerade
>
> im Sendemodus war..

1. Sage mir mal in welcher Specification das geschrieben steht.
2. Solange ein Device am senden ist, wird der Master niemals ein ATN 
setzen. Tut er es doch, dann hängt sich zwangsläufig der Bus auf.
Es gibt nicht adressierte Mehrdrahtbefehle. Das setzt aber eben vorraus 
das sämtliche Geräte deadressiert sind. Es gibt Befehle wie parallel 
Poll
und seriel poll, welches durch ATN vom device angekündigt werden. Aber 
auch das setzt vorraus das keine Aktivität auf dem Bus stattfindet. 
Dieses wird wiederum durch den 3 Draht Handshake sichergestellt.

Ich habe ein Gerät von Rohde&Schwarz in welcher überhaupt kein 
Kontroller verbaut ist sondern nur ein IC Grab. Dieser hatte genau den 
Fehler, das im abgeschalteten Gerät das ATN dauernd gesetzt war. Der 
hatte einfach nur den Bus blockiert, ( Geräte konnten nicht adressiert 
werden )und das wars.

Frohe Festtage noch

Ralph Berres

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick S. schrieb:
> Hier ist ein Beispiel für einen GPIB nach USB-Umsetzer:
> http://lpvo.fe.uni-lj.si/gpib/ (guckst Du unter self-build)

Das Ding hab ich auch mal nachgebaut. Ein paar Meßgeräte von HP hier 
haben allesamt damit funktioniert. Obwohl es sicher die 200ns nicht 
einhalten kann.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Bei den Datenleitungen haben viele Devices kein OC Verhalten beim Senden!
Und das ist lau Spec erlaubt? Hab ich anders in Erinnerung.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SEUFZ!
Warum glaubt mit keiner...

Ralph Berres schrieb:
> 1. Sage mir mal in welcher Specification das geschrieben steht.
Gerne: ANSI/IEEE Standard 488.1-1987. Wobei es fast sicher auch schon in 
der 1978er Version vorhanden ist, nur liegt mir diese nicht vor...
Leider sind die "Standards" nicht frei im Web verfügbar sondern nur -wie 
viele normen- kostenpflichtig einsehbar...

Da aufgrund der Verwendung von Standart-Schnittstellencontrollern die 
das von sich auch gemacht haben, aber diese kleine -aber feine- Timing 
frage für Hersteller und Bastler irrelevant war hat sich das nicht 
allgemein im Bewusstsein festgesetzt!

Aber es gibt ja trotzdem auch genügend "Second-Source" Quellen die ich 
verlinken kann:
1.
ATN: Attention; When low (true) the system places all devices in Command 
Mode, when high (false) the system places all devices in the Data Mode. 
In Command Mode the Controller passes data to devices, in Data Mode the 
Talker passes data to the Listener. *All device must monitor the ATN 
line and respond within 200nS.*
Zu finden auf: http://www.interfacebus.com/Design_Connector_GPIB.html

2.
Unter "ATN" im Buch: "PC based Instrumentation: Conceps an practice" von 
M. Mathivanan auf Seite 380 oben steht geschrieben:
"All Devices monitor the ATN signal at ALL TIME an response to it 
within 200ns "!
Auszugsweise zu finden unter der Google Buch-Suche auf:
http://books.google.de/books?id=OB65rMNQDo8C&pg=PA...

3. In dem von HP herausgegebenen "Tutorial Description of the 
Hewlett-Packard Interface Bus" aus dem (glaube) Jahr 1988 steht unter 
Punkt 2.4.3:
"ATN (Attention) *All devlces must monitor ATN at all times and respond 
to it wlthln200 ns.* When true, ATN places the interface ln the "Command 
Mode" whereall devices accept (handshake) data on the Data Lines and 
interpret it as Com-mands or Addresses. When false, ATN places the 
Interface tn the “Data Mode"where the actlve talker sources device 
dependent Data to all active listeners "
Zu finden zum beispiel als PDF hier:
http://www.bitsavers.org/pdf/hp/hpib/TutorialDescrOfHPIB.pdf
Fundstelle ist auf Seite 15, oberes drittel...
*q.e.d.*

Ich hätte noch gut 10 weitere Fundstellen -zum beispiel auch von NI-, 
aber ich glaube dies sollte ausreichen, insbesondere ja selbt ein HP 
eigenes Dokument dabei ist!

> 2. Solange ein Device am senden ist, wird der Master niemals ein ATN
> setzen. Tut er es doch, dann hängt sich zwangsläufig der Bus auf.
> Es gibt nicht adressierte Mehrdrahtbefehle. Das setzt aber eben vorraus
> das sämtliche Geräte deadressiert sind. Es gibt Befehle wie parallel
> Poll und seriel poll, welches durch ATN vom device angekündigt werden.
> Aber auch das setzt vorraus das keine Aktivität auf dem Bus stattfindet.
> Dieses wird wiederum durch den 3 Draht Handshake sichergestellt.

Nee, du liegst immer noch daneben...
ATN wird NUR vom Master gesetzt. Wenn ein Slave also nun sendet, also 
Daten auf dem BUS hat und DAV auf TRUE gesetzt ist, dann darf der Master 
das mit ATN unterbrechen. Daher steht ja auch ganz eindeutig: "All 
devlces must monitor ATN at all times" in den Specs!
Bei deinem Fehler hat aber ein SLAVE die ATN Leitung auf True gezogen 
was den Master daran gehindert hat die Kontrolle über den Bus zu 
übernehmen.
Die ATN Leitung ist bei Geräten die NUR als Slave funktionieren aber 
eigendlich NUR ein Eingang...

900ss D. schrieb:
> Patrick S. schrieb:
>
>> Hier ist ein Beispiel für einen GPIB nach USB-Umsetzer:
>> http://lpvo.fe.uni-lj.si/gpib/ (guckst Du unter self-build)
>
> Das Ding hab ich auch mal nachgebaut. Ein paar Meßgeräte von HP hier
> haben allesamt damit funktioniert. Obwohl es sicher die 200ns nicht
> einhalten kann.
[GENERVT] JA, glaube ich dir- Das Thema hatten wir hier bereits...

Dieses Modul fungiert als MASTER auf dem Bus. Der MASTER sendet aber 
seinerseits das ATN Signal, also muss er nicht selbst darauf reagieren. 
Das müssen die SLAVES. Solange es also sicher -GANZ SICHER- nur EINEN 
Master gibt kann man bei diesem EINEN MASTER auf die Einhaltung der 
200ns verzichten. Natürlich kann man auch wenn man einen eigenen MAster 
baut dann auch bei den Slaves langsamer sein, aber wehe dann kommt ein 
anderer nicht selbst entwickelter MAster der schneller ist... Die ganze 
geschichte ist dann halt nur noch IEEE488 ähnlich und man wundert sich 
in drei Jahren dann auf einmal warum es nicht merh läuft und die 
Schnittstelle des Skopes nun defekt ist... Für nicht einmal 90ct. an 
Bauteilen (reichelt Preis) die man sparen wollte.

Jörg S. schrieb:
> Carsten Sch. schrieb:
>
>> Bei den Datenleitungen haben viele Devices kein OC Verhalten beim
> Senden!
> Und das ist lau Spec erlaubt? Hab ich anders in Erinnerung.
Wie gesagt, die Hardwarebeschreibung war nicht meine Baustelle. Ich 
meine aber trotzdem das das jeweils Sendende Gerät immer den BUS treibt 
und die Empfänger im OC Modus arbeiten.
Bei den Handshakeleitungen war OC Verhalten für die Slaves aber definitv 
vorschrift. Bei den Datenleitungen...? wie gesagt glaube nicht - das 
aber im gegensatz zu den 200ns ohen Gewähr!

Gruß
Carsten

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei den Datenleitungen sind oft Tristateausgänge. Das ist erlaubt, weil 
immer nur einer Daten auf den Bus legt. Die Handshakeleitungen
NDAV NFRD und NRFD müssen zwingend Open-Collektor sein, weil sie ein 
verdrahtetes Or Gatter darstellen. Sowohl die Daten als auch die anderen 
Leitungen sind negative Logik. Das heist eine logische 1 entspricht 0V 
auf dem Bus und eine logische Null entspricht +5V auf dem Bus.

Sieh mal die Datenblätter vom SN75160, SN75161 und SN75162.

Ralph Berres

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> dann darf der Master
>
> das mit ATN unterbrechen.


Nee darf er nicht, und kann er auch nicht. Solange Daten auf dem Bus 
sind
muss der Master erst mit DAV antworten, damit der Device seine Daten 
wieder vom Bus nehmen kann. Und obendrein muss der Master erst das EOI 
abwarten, welches mit dem letzten Datum übermittelt wird. Entweder mit 
dem Setzen der Leitung EOI oder durch Senden des CR bzw LF als Daten. 
Erst dann kann er den ATN setzen wieder setzen um dann in diesem Falle 
den Device zu deadressieren.

Ich meine die 200nS beziehen sich darauf, wenn die maximal mögliche 
Busgeschwindigkeit ausgenutzt werden soll.

Man kann ( und das habe ich auch bei einer Fehlersuche schon gemacht ) 
schön mit 16 Kippschalter an den Busleitungen den Datenverkehr inclusive 
Handshake Step by Step durchspielen, und dabei mit einen Logikanalyzer 
oder einen Oszillografen die einzelnen Aktivitäten produkollieren. Da 
habe ich garantiert keine 200ns eingehalten. Sozusagen Einzelsteppmodus.

Ralph Berres

Autor: Om Pf (ompf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:

> "ATN (Attention) *All devlces must monitor ATN at all times and respond
> to it wlthln200 ns.*

Primär gehr's darum, den Bus freizugeben. Das kann man relativ einfach 
über ein paar Gatter und ein Flipflop machen. Um sich das Kommandobyte 
danach genauer anzuschauen, haben die Devices deutlich mehr Zeit. Dann 
kann der Prozessor die Leitungen entsprechend setzen und sich die 
Kontrolle über TE zurückholen.


> ATN wird NUR vom Master gesetzt. Wenn ein Slave also nun sendet, also
> Daten auf dem BUS hat und DAV auf TRUE gesetzt ist, dann darf der Master
> das mit ATN unterbrechen.

So z.B. um eine Druckausgabe abzubrechen. Wobei da nicht wirklich jedes 
Gerät drauf reagiert...


> Bei den Handshakeleitungen war OC Verhalten für die Slaves aber definitv
> vorschrift. Bei den Datenleitungen...? wie gesagt glaube nicht - das
> aber im gegensatz zu den 200ns ohen Gewähr!

Die Datenleitungen sind totem pole. Außer im parallel poll-Betrieb, da 
wird auf open collector geschaltet.

Die 75xxx sind per design kurzschlußfest. Im Datenblatt wird jedoch 
keine thermische Überwachung erwähnt, so daß man sicherstellen muß, daß 
der Kurzschlußstrom den Käfer nicht auf mehr als 70°C erwärmt. Daraus 
folgt, daß ein Kurzschluß immer durch externe Maßnahmen (Software) 
zeitlich begrenzt werden muß.


Gruß
Patrick

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist lange her, dass ich mit IEEE488 etwas zu tun hatte.
Aber ich meine mich zu erinnern, dass der Bus-Master zu jeder Zeit ATN 
aktivieren darf; sonst wäre er ja nicht Master und könnte auch kein 
Timeout/Bushänger abfangen und beseitigen.

Es reicht meines Erachtens, per FlipFlop die ATN-Aktivierung zu 
registrieren, daraufhin alle Ausgänge auf tristate zu schalten (per 
hardware Gatter) und NRFD zu aktivieren. Ein Interrupt zum µC kann dann 
in Ruhe (per handshake) das Protokoll abarbeiten und das FF für ein 
neues ATN zurücksetzen.

Das würde ich gerne aus Spaß einmal testen, müßte aber zunächst einen 
uralten Rechner mit µPD7210 wieder anwerfen, um die Controller-Funktion 
zu haben. Den Aufwand scheue ich aber :-)

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick S. schrieb:
> So z.B. um eine Druckausgabe abzubrechen. Wobei da nicht wirklich jedes
>
> Gerät drauf reagiert...

Da gibt es noch die Leitung IFC Interface clear, REN Remote enable ,
und SRQ Service Request. Mit SRQ kann der Drucker dem Master z.B 
mitteilen das das Papier leer ist oder es zum Papierstau gekommen ist. 
Mit SRQ wird üblicherweise ein Interupt im Hauptprogramm ausgelöst. Man 
kann es aber auch umgekehrt verwenden. Der Master sendet ein SRQ an den 
Drucker mit der Bitte das Drucken abzubrechen. SRQ ist auch beim
Serielpoll eine wichtige Leitung.



Entwickler schrieb:
> Es ist lange her, dass ich mit IEEE488 etwas zu tun hatte.
>
> Aber ich meine mich zu erinnern, dass der Bus-Master zu jeder Zeit ATN
>
> aktivieren darf; sonst wäre er ja nicht Master und könnte auch kein
>
> Timeout/Bushänger abfangen und beseitigen.

Einen Bushänger kann er auch nicht abfangen. Er kann mit einen Timeout 
reagieren und ein Interfaceclear an sämtliche Geräte schicken. Dazu 
braucht er kein ATN.

Ralph Berres

Autor: Unsigned (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier http://ieee2iec.t-winkler.net/ dürfte auch schon die ein oder 
andere brauchbare Routine dabei sein.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralph Berres

Per IFC? Mad sein, das weiß ich nicht mehr.

Aber wie steht es mit meiner Annahme, auf ATN per Hardware mit NRFD zu 
reagieren. Würde das so funktioniern?
Ich finde meinen Piotrowski nicht mehr. Vor ewigen Zeiten verliehen und 
nicht zurückbekommen :-(

Autor: hbloed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Für einen Slave gibt es eine super einfach Lösung
8291 von Intel. Der ist zwar seit langem obsolete,
wird aber des öfteren im ebay angeboten. Hab neulich
welche für 2€ gekauft. Ich hätte auch noch ein
Treiberbeispiel dafür, das ist allerdings in PL/M.
Bin gerade dabei das in C umzustricken.

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hbloed schrieb:
> Aber wie steht es mit meiner Annahme, auf ATN per Hardware mit NRFD zu
>
> reagieren. Würde das so funktioniern?

Schwierig zu sagen. Der Master darf ja nichts auf den Bus legen solange 
nicht sämtliche Device no rady for Data vom Bus genommen haben.
NRFD ist einer der 3 Handshakeleitungen.

Ich glaube was du vorschlägst ist eine todsichere Methode den Bus zum 
hängen zu bekommen.

Der 8291 ist zum Teil kompatibel zum Nec upd 7210. Aber auch nur fast.

Ich hatte den Versuch mal gemacht den Nec7210 anstelle des 8291 
einzusetzen und auch umgekehrt. In beiden Fälen gab es sporadische 
Hänger , dessen Grund ich nie dahinter gekommen bin.

Ralph Berres

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

jetzt hat sich zuviel getan um noch in der Zeit bis der Familienwahnsinn 
;-) weitergeht alles sauber auseinanderzufriemeln...

Der Standart IEC625 bzw. IEEE488.1 sagt ganz klar: Eine Reaktion auf ATN 
muss jederzeit und immer erfolgen können!
Und der Master DARF jederzeit ATN setzen. Das eine gerade stattfindende 
übertragung dadurch unterbrochen wird ist fakt, daher sollte man dafür 
Sorge tragen das es nur in Ausnahmefällen geschieht.
Es darf- und kann- aber jederzeit vorkommen.

BTW: Das DAV Signal setzt nicht der MAster, sonder der jeweilige Talker. 
Das muss ebend nicht der Master sein. Kommt aber während des Sendens ein 
ATN muss der Talker SOFORT auf Listener umschalten.

@Patrik S. Was du schreibst habe ich ja schon weiter oben auch 
angedeutet. Per StateMaschine (=Logik) entweder im CPLD oder auch mit 
normalen 74er gattern reagiert man aud das ATN;
Treiber werden automatisch auf TS, High Impedance gesetzt, alle 
Handshakeleitungen zurückgesetzt und die NDAC auf TRUE gelegt. die ganze 
Logik, Treiberanaordung geht intern in einem sicheren Zustand.
Dann erst übernimmt der CPU wieder die Kontrolle, passt seine eigene 
Einstellung den gegebenheitna an, übernimmt wieder die Kontrolle über 
die Schnittstelle und nimmt NDAC zurück um den Befehl zu empfangen.

@Entwickler
Piotrowski! Ok ,der Wars, kam gerade nicht mehr drauf weil mein Buch 
auch verliehen ist. IEC-Bus von Piotrowski, das ist eine gute Lektüre.
Aber NDAC ist das Signal der Wahl, nicht NRFD ;-)

Gruß
Carsten

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber NDAC ist das Signal der Wahl, nicht NRFD ;-)

Gut zu wissen!
Und anschließend kann der µC FF und Gatter wieder zurücksetzen, was mit 
heutigen Controllern doch eigentlich ein Klacks ist.
Aber auf gute Treiberbausteine und gute Kabel würde ich nicht 
verzichten. Mit Rechnern von Commodore mit ihren VIAs und PIAs konnte 
man noch Flachbandkabel verwenden. Aber sobald ein schneller Controller 
im Spiel war, blieb der Bus oft hängen (Übersprechen, Reflexionen).

Eine andere Frage ist aber, ob es in der heutigen Zeit nicht doch bloß 
eine Liebhaberei ist, sich den IEC-Bus flott zu machen.

Autor: hbloed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich wollte ja hier mal so ein Gateway entwickeln 
(Ethernet,CANOpen,RS232,IEEEE488), das ist aber von
der Helikopterfraktion zerredet worden.

"Beitrag "Ethernet auf IEEE-488 Gateway"

Da bin ich noch kräftig am werkeln. Ich hatte schon einen
Steckbrettaufbau fertig und konnte diverse HP-Geräte damit
bedienen. Ich habe solche HPIB-Extender von HP, die zicken
noch. Z.zt. arbeite ich am TCPIP-Stack und am CANOpen - Interface.

Demnächst werde ich mal eine Platine machen.

Das ganze ist ein AT90CAN-128 mit SN7516Xer Treibern.

Ich werde das ganze aber nicht über dieses Forum laufen
lassen, weil es hier zuviele von diesen Helikoptertypen
gibt. Wer will kann gerne mitmachen.

MfG
Edgar

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entwickler schrieb:
> Eine andere Frage ist aber, ob es in der heutigen Zeit nicht doch bloß
>
> eine Liebhaberei ist, sich den IEC-Bus flott zu machen.

Es gibt eigentlich nur ein von Messgerätehersteller zunehmend benutztes 
Bussystem welches dem IEC Bus ernsthaft Konkurenz machen könnte. das ist 
TCP-IP. USB ist meines Wissens nicht multimasterfähig und ich weis auch 
nicht ob man ihn explizit adressieren kann. Zudem wartet der USB Bus 
nicht auf den langsamsten Teilnehmer bis der Bus frei geräumt ist. RS232 
ist kein Bus sondern eine Punkt zu Punkt Verbindung und dafür sogar 
extrem langsam.

Ich meine der IEC Bus wird speziell in der Messtechnik noch eine ganze 
Weile erhalten bleiben. Die Geschwindigkeit von bis zu 1Mbyte/ Sek ist 
mehr als ausreichend. Ich kenne kein Messgerät was so schnell seine 
Daten loswerden muss. Bildschirminhalte vielleicht noch, aber da reicht 
die Übermittlungszeit auch noch dicke aus.

Der Nachteil dieses Busses ist das er relativ teuer ist. Aber wenn 
Messgeräte in dieser Klasse 1000 Euro und mehr kosten relativiert sich 
das schnell wieder. Mittlerweile bekommt man sowohl die Buskarte für den 
PC als auch die Kabel in der Bucht zu durchaus erschwingliche Preise.

Besonders wenn man noch ältere Messgeräte hat bleibt einen nichts 
anderes übrig als den IEEE488 Bus einzusetzen.

Ralph Berres

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten sind die Nec 7210 mittlerweile bei dir eingetroffen?

Ralph Berres

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ralph,

Ralph Berres schrieb:
> Carsten sind die Nec 7210 mittlerweile bei dir eingetroffen?
>
> Ralph Berres

Nee, noch nicht...
Aber angesichts der Tatsache das gestern erst ein DHL Paket, am letzen 
Samstag  von mir aufgegeben worden, in Bayern angekommen ist- Genauso 
wie ein Paket welches ich Dienstag aufgegeben habe und das ebenfalls 
gestern in Duisburg ankam, da denke ich das es noch etwas dauern kann 
;-)

Ich wundere mich gerade immer noch wie so läppische paar cm Schnee, die 
wir hier ja seit etwas über einer Woche haben, so ein Chaos anrichten 
können. (Ok, seit gestern morgen sind es teilweise wirklich für die 
hiesige Gegend ungewöhnliche Höhen von Flächendeckend 30-40cm, bei 
Schneeverwehungen auch deutlich mehr - aber vorher...)

Ich berichte dir dann wenn die da sind. Montag wäre ja passend, dann bin 
ich hier mit meinen Umbauarbeiten incl. Ausmisten im Arbeitszimmer auch 
fertig, könnte dann direkt loslegen.

Gruß
Carsten

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph Berres schrieb:
> Es gibt eigentlich nur ein von Messgerätehersteller zunehmend benutztes
> Bussystem welches dem IEC Bus ernsthaft Konkurenz machen könnte. das ist
> TCP-IP. USB ist meines Wissens nicht multimasterfähig und ich weis auch
> nicht ob man ihn explizit adressieren kann. Zudem wartet der USB Bus
> nicht auf den langsamsten Teilnehmer bis der Bus frei geräumt ist. RS232
> ist kein Bus sondern eine Punkt zu Punkt Verbindung und dafür sogar
> extrem langsam.

USB ist in der tat nicht Multimaster fähig, aber das ist das kleinste 
Problem. Was den USB Bus als vollwertigen ersatz des IEEE488 Busses 
völlig disqualifiziert ist die fehlende Echtzeitfähigkeit!
Weder kann ein Device genau zu einem Ereigniss ein Signal von sich aus 
Auslösen, noch kann GLEICHZEITIG eine Nachricht an mehrere Teilnehmer 
gesendet werden. (Zum Beispiel ein Triggersignal)

Gerade diese Möglichkeit war -und ist es- aber die IEEE488 zur 
Verkopplung von Messtechnik so wertvoll gemacht hat.
Die reine sequentielle Datenübertragung bzw. Einzelfernsteuerung wie die 
meisten Hobbyisten nur einsetzen könnten auch "tausend" andere 
Schnittstellen... Da wo es drum geht verschiedene Messgeräte eine 
Messung genau gleichzeitig beginnen zu lassen, da schlägt bis heute 
nichts den GPIB!

Gruß
Carsten

Autor: hbloed (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Sch. schrieb:
> Gerade diese Möglichkeit war -und ist es- aber die IEEE488 zur
> Verkopplung von Messtechnik so wertvoll gemacht hat.
> Die reine sequentielle Datenübertragung bzw. Einzelfernsteuerung wie die
> meisten Hobbyisten nur einsetzen könnten auch "tausend" andere
> Schnittstellen... Da wo es drum geht verschiedene Messgeräte eine
> Messung genau gleichzeitig beginnen zu lassen, da schlägt bis heute
> nichts den GPIB!

Dann geh mal zu:

http://www.hbm.com/en/menu/products/measurement-el...

Da kannste sehen wie man so etwas heute macht, mit Firewire!

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hbloed

das ist unsinn, eine eigene produkt familie kann ich mit morse code und 
zwei bambus stäben auch steuern. Hier gehts um ein universelles 
BUS/Protokol wo auch fremdgeräte angeschlossen werden können, da nutzt 
firewire herzlich wenig.

Autor: Kevin K. (nemon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal, dass in Zukunft die Ethernet-basierenden Standards LXI 
und evtl. Ethercat bei Laborgeräten größere Bedeutung bekommen. Von 
Firewire in der Gerätevernetzung hab ich bislang noch nichts gehört.

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der Nachteil dieses Busses ist das er relativ teuer ist.

Ich glaube, das ist der Punkt.
Dicke Kabel, dicke Stecker, viele parallele Leitungen und doch eine 
relativ kurze Reichweite, die nur im Labor akzeptabel ist.

> Carsten sind die Nec 7210 mittlerweile bei dir eingetroffen?

Habe mal in den Keller geschaut, drei davon habe ich auch noch :-) Falls 
jemand die 7210 heute verwenden will, ein kleiner Tipp: bitte den 
Zugriff aufs Statusregister mehrfach nacheinander machen und jeweils in 
ein Zielregister 'odern'. Die Teile waren für 8080er wohl schnell genug, 
mit der "Lesegeschwindigkeit" eines 68k wurden sie schon überrannt.

Ich habe auch noch CBM4040, SFD1001, .... :-)

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entwickler schrieb:
> Ich glaube, das ist der Punkt.
>
> Dicke Kabel, dicke Stecker, viele parallele Leitungen und doch eine
>
> relativ kurze Reichweite, die nur im Labor akzeptabel ist.

Um den Einsatz im Labor und um Fertigungsinseln geht es nun mal. Niemand
wird in einer großen Fertigungsstrasse Stand Alone Messgeräte einsetzen.
Da wird wohl mehr der VMX Bus gefragt sein, bei denen Messgeräte nur 
noch Einschübe ohne eigenes Bedienfeld und Display sind.

Entwickler schrieb:
>> Carsten sind die Nec 7210 mittlerweile bei dir eingetroffen?
>
>
>
> Habe mal in den Keller geschaut, drei davon habe ich auch noch

Falls du die nicht mehr verwenden willst. Ich kann die noch gebrauchen.

Ralph Berres

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Falls du die nicht mehr verwenden willst. Ich kann die noch gebrauchen.

Aber gerne doch! Nimm die sechs Buchstaben aus f4ra-q#u(a bei gmxpunkt 
net und gib mir Deine Anschrift. Dann bring ich das morgen zur Post.
Zu Weihnachten schenkt man doch gerne :-)

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entwickler schrieb:
> Aber gerne doch! Nimm die sechs Buchstaben aus f4ra-q#u(a bei gmxpunkt
>
> net und gib mir Deine Anschrift

Meine Mail an dich kam als unzustellbar zurück.

Schreibe mir doch mal unter R-Berres@arcor.de oder rufe mich mal an 
0651-44016

Ralph Berres

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sie ist angekommen und ich habe es Dir bestätigt.
Ich denke, jetzt ist alles klar.

Autor: Ralph Berres (rberres)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja besten Dank.

Ralph Berres

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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