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
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
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.
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...
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
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
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.
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
Schau dir mal die Bausteine 75161 / 75162 an. http://focus.ti.com/lit/ds/symlink/sn75162b.pdf Die sind dafuer gemacht.
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
>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.
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.
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.
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
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
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
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.
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
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
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
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.
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.
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=PA400&lpg=PA400&dq=200ns+ieee488&source=bl&ots=CM4XxTGmj8&sig=Z_COHLsKGDVUt2whosOOhbZXXxg&hl=de&ei=4MUVTd__H4Wl8QPKw92CBw&sa=X&oi=book_result&ct=result&resnum=10&ved=0CF4Q6AEwCTgK#v=onepage&q=200%20ns&f=false 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
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
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
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
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 :-)
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
Hier http://ieee2iec.t-winkler.net/ dürfte auch schon die ein oder andere brauchbare Routine dabei sein.
@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 :-(
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.
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
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
>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.
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
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
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
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
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-electronics-software/universal-data-acquisition-systems/quantumx/ Da kannste sehen wie man so etwas heute macht, mit Firewire!
@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.
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.
>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, .... :-)
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
>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 :-)
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
Sie ist angekommen und ich habe es Dir bestätigt. Ich denke, jetzt ist alles klar.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.