He, dieser ist der Thread zum Artikel: GPIB-RS232-Schnittstelle. Viel Spaß damit, Sven
Das wären die aktuellen EAGLE-Dateien zum 22. April 2012. Nicht-kommerzielle Verwendung unter der Creative-Commons-Lizenz mit Namensnennung, Weitergabe unter gleichen Bedingungen (CC-BY-NC-SA). Quelltext folgt, sobald ich aufgeräumt habe.
Firmware zum 30. April 2012. Verwendung unter den Bedingungen der GPLv3.
Hallo Sven, im Prinzip wollte ich auch immer schon solch einen Umsetzer bauen, jedoch war kein dringender Bedarf vorhanden. Daher war ich auf Deine Schaltung und Dein Programm gespannt. Allerdings liegen viele Knüppel auf dem Weg, wenn man sich die Sachen ansehen will. Die .sch und .brd Dateine kann man sich nur ansehen, wenn man eine neuere Eagle-Version läd und anschließend aufpasst, sich seine eigenen, älteren Eagle-Dateien nicht zu zerschiessen. Die zweite Hürde ist diese .tar.bz2 Datei, dessen Endung ich noch nie zuvor gesehen habe. Irgendein Programm zum Öffnen, was ich heruntergeladen habe, stürzt nach der ersten offenen Datei ab. Eine .zip Datei hätte keine Probleme gemacht; ebenso .png oder .gif. Aber die größten Knüppel liegen im Wiki-Artikel unter 'Software'. Dort steht: "Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert." Warum hast Du nicht die passende Logik ergänzt? Die Funktion von ATN ist das A+O des GPIB. Und weiter am Ende des Absatzes steht: "Unterm Strich: Meistens funktioniert es." Das hat doch zur Folge, dass kein ernsthaft interessierter Anwender sich dieses Interface antuen wird. Vielleicht findest Du ja einen Weg, diese Probleme noch auszuräumen.
Willi schrieb: > Die .sch und .brd Dateine kann man sich nur ansehen, wenn man eine > neuere Eagle-Version läd und anschließend aufpasst, sich seine eigenen, > älteren Eagle-Dateien nicht zu zerschiessen. Die sind mit der Version 5.10 erstellt. > Die zweite Hürde ist diese .tar.bz2 Datei, dessen Endung ich noch nie > zuvor gesehen habe. Das ist das Standardformat schlechthin, zumindest unter Unix. Vorallem ist es ZIP in der Effizienz überlegen. Ich habe kein Windows, aber soweit ich weiß, kommen auch 7zip, Powerarchiver, IZarc und WinRAR damit zurecht. > Warum hast Du nicht die passende Logik ergänzt? Die Funktion von ATN ist > das A+O des GPIB. Weil sich mir die Brisanz des ATN erst spät erschlossen hat. Nach weiterem Nachdenken ist mir dann aufgefallen, dass ein Busteilnehmer auf ATN nur dann so schnell reagieren muss, wenn ATN fremd gesteuert wird, d.h. wenn ein anderer Controller am Bus regiert. Das habe ich auch im Artikel beschrieben. Und genau diesen Betriebsmodus benötige ich nicht, darum habe ich auf eine Anpassung der Schaltung verzichtet. Nochmal: Das ATN funktioniert (nach bestem Wissen) einwandfrei und standardkonform, solange die Schnittstelle als Controller arbeitet, denn genau dann steuert sie ATN und muss darum nicht drauf reagieren. > Und weiter am Ende des Absatzes steht: "Unterm Strich: Meistens > funktioniert es." > > Das hat doch zur Folge, dass kein ernsthaft interessierter Anwender sich > dieses Interface antuen wird. Nun, ich möchte es pragmatisch formulieren. Bitte fühle dich nicht angegriffen, ich verstehe schon, was du meinst. Ich habe in die Schnittstelle etwa 2 bis 3 Mannwochen gesteckt, da ich nie zuvor mit GPIB zu tun hatte. Dazu habe ich mich entschlossen, die Sache nach bestem Wissen und Gewissen der Allgemeinheit zur Verfügung zu stellen. Und das unter freien Lizenzen, sodass jeder, der kann und will, das Ding verbessern will. Es steht dir und allen anderen nun also frei, dem Teil eine Chance zu geben, es sogar zu verbessern -- dazu habe ich momentan wenig Zeit -- oder alternativ zum Beispiel für rund 700 Euro ein Gerät von NI zu erwerben. Es wird dich sicher weiter beunruhigen, dass ich auch noch Timeouts implementieren muss, die gibt es bislang noch nicht. > Vielleicht findest Du ja einen Weg, diese Probleme noch auszuräumen. Mit dem Archiv kann ich schon weiterhelfen. Im PDF findest du die Kupferlage in Originalgröße; Schrift und das 'F' sind nachher lesbar. Schaltplan und Bestückung findest du im Artikel verlinkt als Bild. Falls du noch etwas brauchst, melde dich einfach.
Glückwunsch Sven, Du würdest ge-hackaday-ed: http://hackaday.com/2012/05/01/gpib-connectivity-twofer/
Hallo Sven, erstmal vielen Dank für die coole Schaltung! Der SN75162 scheint nicht ganz einfach zu beschaffen zu sein. Aus den Datenblättern kann ich die Notwendigkeit (vs SN75161) nicht nachvollziehen: Demzufolge sind beim x162 die Signale (ATN, SRQ) und (REN, IFC) mit den beiden Steuerleitungen SC und DC unabhängig zu steuern. Wogegen beim x161 dies nur mit DC geschieht. In gpib.c setzt du immer
1 | _DC = 0; |
2 | _SC = 1; |
bzw
1 | _DC = 1; |
2 | _SC = 0; |
zusammen, somit verstehe ich nicht, weshalb dies nicht mit dem x161 und nur dem DC Signal alleine möglich ist. Gem. Datenblatt ist der x162 nur für Multi Controller Setups nötig.
Adi K. schrieb: > Hallo Sven, erstmal vielen Dank für die coole Schaltung! Der SN75162 > scheint nicht ganz einfach zu beschaffen zu sein. Ist in der Tat etwas schwierig weil Antiquität... alte GPIB-Karten sind einfacher zu kriegen. Ich habe den Baustein ja auch ausgeschlachtet. > Aus den Datenblättern > kann ich die Notwendigkeit (vs SN75161) nicht nachvollziehen: [...] Die ist auch momentan nicht gegeben. Die beiden Bausteine sind auch recht einfach gegeneinander austauschbar, es müssten nur drei Drahtbrücken zwischen je zwei Pins des IC-Sockels gelegt werden. Das kommt noch aus der Konzeption. Als ich damit anfing, wollte ich ein vollständig kompatibles Interface konstruieren, also auch Multi-Controller-fähig. Allerdings hat erst das dritte Buch zu GPIB mir die entscheidende Aussage mit der ATN-Leitung gebracht. Da kam dann halt obige Überlegung dazu, dass ich doch nur Single-Controller brauche. Zu dem Zeitpunkt hatte ich die Bausteine schon beschafft (alte GPIB-Karten) und wollte nicht nochmal bestellen. Da die Bausteine wie oben beschrieben quasi pinkompatibel sind, habe ich den größeren Sockel verbaut. Die Brücken wären dann: . VCC von 24 auf 23, . GND von 12 auf 11 und . DC von 13 auf 14. Die sind im Datenblatt als 'NC' bezeichnet; ich gehe davon aus, dass damit auch 'NC' gemeint ist und nicht 'DNC'.
In den günstigen USB auf GPIB Adaptern steckt übrigens nur ein Standard µC (ATmega) und der GPIB Stecker drin, die GPIB Kontakte gehen direkt auf den µC, also kann man die Spezialbausteine auch komplett einsparen wenn man will.
hallo liebe gemeinde, ich möchte diesen HP Plotter 7470A gerne mit windows ansteuern um damit meine platinen zu belichten funktioniert dafür der hier vorgestellte adapder oder auch dieser hier : http://cluster.physik.uni-freiburg.de/~kuhnen/pic/pic_usbgpib/ ich danke schonmal für antworten ! mfg sunny
Ich bin das nochmal ! Wenn ich den GPIB bus richtig verstehe ist mein bald zukünfitger plotter listener und der wandler müsste ja theoretisch nur talker sein da bräuchte ich ja auch nur die drei handshake leitungen das wäre doch mit einem kleinem pic relativ schnell erledigt wenn ich das jetzt alles richtig verstanden habe . Ich hoffe mich kann mal jemand genauer aufklären ! mfg sunny
Info: Alle Dateien konnten entweder mit 7zip oder eagle 6.2.0 problemlos geöffnet werden.
Marcel klug schrieb: > Wenn ich den GPIB bus richtig verstehe ist mein bald zukünfitger plotter > listener und der wandler müsste ja theoretisch nur talker sein Talkener und Listener sind die "Datenenden". Ohne Controller geht da nichts. > da > bräuchte ich ja auch nur die drei handshake leitungen das wäre doch mit > einem kleinem pic relativ schnell erledigt wenn ich das jetzt alles > richtig verstanden habe . Ja wenn, ein kleiner Blick in die Spezifikation ist da hilfreich.
@ Der Rächer der Transitormorde ich habe aber was anderes gelesen da geht es um ein Tektronix 2432A welches die gpib schnitstelle besitzt. http://spurtikus.de/basteln/gpib.html Also müsste das doch gehen das sozusagen der µC Talker ist und der plotter Listener (was er ja eigentlich logischerweiße sowieso sein müsste) mfg
Marcel klug schrieb: > Also müsste das doch gehen das sozusagen der µC Talker ist und der > plotter Listener (was er ja eigentlich logischerweiße sowieso sein > müsste) Der Controller ist zugleich Talker. Hab so was auch schon mal für einen Plotter gebaut, ist aber von scratch arges Gefummel. Wenn es Beispiele gibt, einfach probieren. Das Protokoll ist Standard und die Befehle kannst du mit Windows HPGL Treibern mit Dateiumleitung erzeugen.
okay also brauche ich dann im prinzip nur noch einen treiber wie zum beispiel www.winline.com . wenn das dann über die rs232 schnitstelle läuft wie muss ich mir das vostellen die daten werden ASCII conform über die schnitstelle zum µC gesendet und der übernimmt dann sozusagen nur die 3 handshake leitung des GPIB ? mfg sunny
misst ich war ja garnicht eingeloggt ... ich habe noch ein wenig "gegoogelt" wenn ich das jetzt mit einem µC mache müsste es doch reichen wenn ich dann unter dos " copy /B test.plt COMx " eingebe ? Zusätzlich würde ich die NRFD vom GPIB mit CTS der RS232 , natürlich invertierend , verbinden da ja auf dem GPIB bus eine 0 high pegel bedeutet. dann müsste ich ja auch später im µC die einkommenden daten Invertieren und dann ebend an z.b. PORTB ausgeben. Korrigiert mich bitte jemand wenn ihc da jetzt falsch liege ! mfg sunny
Wenn der copy-Befehl nicht funktioniert, setze ihm ein set mode voran. Ich habe zwar die Parameter nicht mehr im Kopf aber damit kannst Du deiner seriellen Schnittstelle sagen: Wie schnell es sein soll (Baudrate) und die Kommunikationsparameter befummeln. Immer vorausgesetzt den Befehl gibt es noch.
Ich habs mak über dos 7.1 im vmware probiert und funktioniert (hab mit einem zweiten rechner über hyperterm geschaut) jetzt bastel ich mal noch den converter und der plotter muss auch noch ankommen mal schauen Das mit mode habe ich probiert unter vmware geht nicht mehr als 9600 muss ich mal auf einem alten rechner probieren. ich melde mich dann wieder und kann ja hier dann auch alles posten wenns klappt ! mfg sunny
ich bins nochmal ich habe mir gerade mal die parallele schnitstelle angeschaut und muss feststelle das die sich der gpib schnitstelle stark ähnelt. würde es nicht reichen wenn ich die spannungspegel der gpib schnitstelle anpasse ? für einen plotter müsste das ja reichen !? mfg sunny
Marcel Klug schrieb: > ich bins nochmal ich habe mir gerade mal die parallele schnitstelle > angeschaut und muss feststelle das die sich der gpib schnitstelle stark > ähnelt. würde es nicht reichen wenn ich die spannungspegel der gpib > schnitstelle anpasse ? für einen plotter müsste das ja reichen !? Schon mit google gesucht? z.B. GPIB emulation on LPT port
okay ich hab das was gefunden http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&ved=0CHUQFjAJ&url=http%3A%2F%2Fcontent.imamu.edu.sa%2FScholars%2Fit%2FVisualBasic%2FParallel_Port_Complete_Programming%2C_Interfacing_and_Using_the_PCs_Parallel_Printer_Port.pdf&ei=AldIUOquGpDltQb_gIHIAQ&usg=AFQjCNH7CI0bQL1dYLr7J2LCt1d8TDA7gw so wie es aussieht muss ich nicht mal die pegel anbpassen da der parallelport eine erweiterung der gpib schnittstelle ist und somit ja darauf aufbaut ! ich werds mal versuchen und dann hier berichten ! mfg sunny
also irgendwie bekomme ich das nicht hin ich denke aber es liegt an mir (unwissenheit) ich versuche es hiermit http://www.programmersheaven.com/download/13475/download.aspx nun weiß ich aber nicht welches betriebsystem und wie ich die daten jetzt versende (programm) ich hoffe mir kann jemand helfen mfg sunny
Um noch mal auf das Prob mit den schwer erhältlichen SN75160/62 OCTAL GENERAL-PURPOSE INTERFACE BUS TRANSCEIVER zu kommen... könnte man stattdessen nicht einfach was konventionelles wie zB '244, 245 bzw '688(?) nehmen? Nebenbei: Steven Casagrande hat das ganze mit nem PIC ohne spezielle ICs gelöst. Wäre das wirklich so störend wenn man sie nicht (mit angepasstem Code) verwenden würde?
Joachim ... schrieb: > Um noch mal auf das Prob mit den schwer erhältlichen > SN75160/62 OCTAL GENERAL-PURPOSE INTERFACE BUS TRANSCEIVER zu kommen... Sind o.a. ICs in Stein gegossen? Nein! Diese Käfer wurden in Zeiten entwickelt, wo man versucht hat, ein paar diskrete Schaltelemente ein wenig kleiner in Plaste zu verfrachten. Was also hindert dich daran, jene Funktion(en) dieser ICs in "diskret" zurückzuverwandeln???
Joachim ... schrieb: > Nebenbei: Steven Casagrande hat das ganze mit nem PIC ohne spezielle ICs > gelöst. Wie auch bei diesem Projekt: http://www.spurtikus.de/basteln/gpib.html
Hallo Sven, das ist eine schöne Schaltung. Wo hast du denn die GPIB Printbuchse her? Auch aus der alten GPIB-Karte ausgeschlachtet? Beim Reichelt gibts ja die Centronics 24-polige Printbuchse, aber der fehlen die Schraubbolzen um den GPIB-Stecker festschrauben zu können.
Hallo Sven, wenn du noch mit liest: Mit was programmierst du die .bin Datei in den Mega16? Ich würde ungern selbst neu compilieren, weil man dann nie weiß ob man wirklich die gleiche Binärdatei hat wie die die der ursprüngliche Autor getestet hat. Das makefile sieht so aus als würdest du mit dem AVRDUDE eine .hex Datei programmieren, die ist im Firmware-zip aber nicht dabei. Gibts die Platine auch in 1:1? Ich würde die Platine nicht selbst fertigen sondern von einer Firma machen lassen, da fürchte ich dass ich eine Mini-Platine bekomme, egal was ich in der email dazu schreibe... Vielen Dank,
Steffen schrieb: > Hallo Sven, > > das ist eine schöne Schaltung. > Wo hast du denn die GPIB Printbuchse her? > Auch aus der alten GPIB-Karte ausgeschlachtet? Ja :-} Das doofe ist, dass es diese Buchsen noch spiegelverkehrt gibt. Also wenn man von vorn draufschaut, sieht man den trapezförmige Umriss der Buchse - da gibt es nun welche mit der längeren Seite zur Platine hin und andersherum. > Beim Reichelt gibts ja die Centronics 24-polige Printbuchse, > aber der fehlen die Schraubbolzen um den GPIB-Stecker festschrauben zu > können. Muss man auch nicht. Geht im Zweifelsfall auch wieder in die Hose, weil manche GPIB-Kabel Stecker mit metrische Schrauben haben und andre mit zölligen. Erkennst du meistens daran, ob der Stecker silber/Nickel ist oder schwarz.
asd schrieb: > Hallo Sven, > > wenn du noch mit liest: > > Mit was programmierst du die .bin Datei in den Mega16? Ich würde ungern > selbst neu compilieren, weil man dann nie weiß ob man wirklich die > gleiche Binärdatei hat wie die die der ursprüngliche Autor getestet hat. > Das makefile sieht so aus als würdest du mit dem AVRDUDE eine .hex Datei > programmieren, die ist im Firmware-zip aber nicht dabei. Ich nehme tatsächlich avrdude. Ist aber unsinnig, das mit ins Archiv zu packen, denke ich. Du kannst es dir einfach von der avrdude-Homepage herunterladen. > Gibts die Platine auch in 1:1? Ich würde die Platine nicht selbst > fertigen sondern von einer Firma machen lassen, da fürchte ich dass ich > eine Mini-Platine bekomme, egal was ich in der email dazu schreibe... Mittlerweile ja. Ich packs nachher mal zusammen.
Board in Originalgröße. Ist allerdings nun das neue XML-Format von Eagle, für das alte hab ich keine Lizenz.
Vielen Dank für die schnelle Antwort, und vielen Dank für die Eagle-Datei in Originalgröße. Zur Frage mit der .bin Datei: Bisher hab ich immer eine .hex Datei mit dem avrdude in den uC programmiert, und dein makefile sieht so aus als würdest du auch eine .hex Datei programmieren. Bin aber kein Experte auf dem Gebiet. Ich benutze für gelegentliches Programmieren den WinAVR (=Notepad++, gcc-avr und avrdude), der erzeugt gar keine .bin Datei, deswegen weiß ich nicht was ich mit der Datei anfangen kann. Selber compilieren hat auf den ersten Anlauf hin nicht funktioniert ("makefile:58: dependencies: No such file or directory" bzw. "make.exe: *** No rule to make target `all'. Stop.")
Jetzt hab ich ein wenig am makefile rumgespielt (bin wie gesagt kein Experte), und hab einen Fehler an dem ich nicht weiter komme: "u:\dateien\avr\rs232-gpib\firmware_selber-compile/configuration.c:83: undefined reference to `eeprom_update_block' " Wie kommt man da weiter?
asd schrieb: > Wie kommt man da weiter? Na, finde heraus, in welcher *.c-Datei die Funktion enthalten ist und finde heraus, warum diese *.c-Datei nicht im Makefile enthalten ist, bzw. warum die daraus erzeugte Objektdatei nicht gelinkt wird.
Angehängte Dateien:
-
hex-screenshot.png
19 KB
An sich soll die Funktion in der <avr/eeprom.h> enthalten sein die in der configuration.c auch includiert wird: http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html Wegen der .bin Datei: Da es von der Struktur der Datei eher nach einer .elf Datei aussah hab ich das per avr-objcopy -O ihex -I elf32-avr object.bin test2.hex in ein .hex umgewandelt. Man sieht im Hex-Viewer keinerlei Strings, was mich ein bisschen wundert weil das Programm ja per RS232 kommuniziert und da auch Klartext-Wörter versendet. Kann es sein dass die Daten für das EEPROM fehlen?
OK, am Wochenende hab ich es geschafft den Quellcode zu komplilieren. Meine Version vom WinAVR war zu alt, die Funktion `eeprom_update_block' gibts erst in einer neueren Version. Es kommt eine .hex Datei raus die der Ponyprog nicht öffnen mag, was an ein paar Zeilen am Ende der Datei liegt. (main.hex) ... :02000004008278 (1) :020000003FC1FE (2) :02000004008377 (3) :01000000EB14 (4) :00000001FF Was ich identifizieren kann sind in Zeile (2) und (4) die Fuses, die Zeilen kann ich ja löschen und die Fuses extra brennen. Aber was bedeuten die Zeilen (1) und (3)? Das Zeilenformat "04" steht eigentlich für 32Bit-Adressen, was hier aber keinen Sinn macht. @Sven: kannst du mir deine Version der Hex-Datei für das Flash (und ggf. EEPROM) schicken? Ich fürchte dass, egal was ich hier selbst kompiliere, dass einfach nichts geht wenn ich die Hardware baue und mein Kompilat flashe. Ist es möglich dass der Flash-Inhalt schon in der object.bin aus deinem zweiten Post (firmware.tar.bz2) steckt? Ich hab es mit avr-objcopy & Co. nicht geschafft dieser Datei einen Flash-Inhalt zu entlocken... Viele Grüße,
Angehängte Dateien:
-
Aussenansicht_s.jpg
100 KB -
Bestueckseite_s.jpg
130 KB -
Loetseite_s.jpg
120 KB
Hallo zusammen, basierend auf dem oben vorgestellten Projekt von Sven und dem LUFA-USBtoSerial-Projekt habe ich einen kleinen USB-nach-GPIB-Konverter gebastelt. Er basiert auf dem ATmega32U4, wobei von der Codegröße her wohl auch der mega16U4 ausreichen sollte. Die Leiterplatte ist sehr groß ausgefallen, da das vorhandene Etuigehäuse verwendet werden sollte. Bitte keine Kommentare über die Qualität der Ätzung -- Tonertransfer bei SMD-Platinen liefert leider nicht immer die perfekten Ergebnisse. Auch über das Verzinnen müssen wir nicht diskutieren. Da beim Ätzen das Kupfer mit Chlor-Ionen in Kontakt kam, verhindert die Verzinnung eine spätere Korrosion. Das ist meine persönliche Meinung und diese muss hier nicht kommentiert werden! Und nein, ich habe hier kein kostbares Lötzinn verschwendet; das verwendete Zinn stammt aus dem Sammelbehälter meines Entlötkolbens. Darüber hinaus erleichtert eine verzinnte Leiterplatte das Löten des QFP-Gehäuses ganz ungemein. An dieser Stelle möchte ich Sven und Dean ganz herzlich für die Bereitstellung Ihres Codes danken! Ohne diese Unterstützung hätte ich das Projekt vermutlich nie realisiert (und könnte mein HM8142 und HP3478A nicht fernsteuern). Die GPIB-Buchse ist eine modifizierte 24-polige Amphenolbuchse von Reichelt (SE 5724FR). Nach entfernen der Befestigungsschrauben können die Ösen der Federbügel mit einer Zange unter leichter Gewaltanwendung entfernt werden, ohne dass die Hohlniete herausgebohrt werden müssen. Mittels eines M3-Gewindeformers werden dann die zölligen Gewinde in den Blechwinkeln auf M3 umgeformt. Nun wird in die 8mm langen M3-Gewindebolzen (Reichelt DA 8MM) in das originale M3-Innengewinde ein M3,5-Gewinde geschnitten. Passende Gewindebohrer und -Former gibt es in diesem online-Auktionshaus. Fertig ist die (fast perfekte) GPIB-Buchse für EUR 2,14. Grüßle, Volker.
Hallo, ist es möglich für den USB-GPIB Adapter einen Schaltplan sowie den Source zu bekommen? Grüße
none schrieb: > Joachim ... schrieb: >> Um noch mal auf das Prob mit den schwer erhältlichen >> SN75160/62 OCTAL GENERAL-PURPOSE INTERFACE BUS TRANSCEIVER zu kommen... > Sind o.a. ICs in Stein gegossen? Nein! Diese Käfer wurden in Zeiten > entwickelt, wo man versucht hat, ein paar diskrete Schaltelemente ein > wenig kleiner in Plaste zu verfrachten. Was also hindert dich daran, > jene Funktion(en) dieser ICs in "diskret" zurückzuverwandeln??? Falls hier noch mal jemand reinschaut: Der Vorteil dieser Chips ist, dass sie dir den Bus nicht kaputt machen, wenn das Gerät ausgeschaltet ist und auch keinen Mist bauen, wenn das Gerät ein/ausgeschaltet wird. Das ist natürlich primär interessant für Multi-Controller-Umgebungen und wenn man eigene Geräte (Nicht-Controller) bauen möchte.
Nochmals zu den Open-Kollektor Bustreibern: es gibt da mehrere Möglichkeiten, diese zu ersetzen, angefangen von diskreten NPN-Transistoren/N-Kanal-Mosfets an den jeweiligen Ausgängen über den altbekannten ULN2803 Low-Side-Treiber (der 8 Kanäle in einem Dil-Gehäuse vereint) und galvanisch getrennten Lösungen über schnelle Optokoppler (die es auch mit Open-Coll./drain gibt!)bis hin zu den TTL-Bausteinen der 746xx Reihe, wobei man dort eben auch auf Bausteine mit Open-Collector/Drain achten muss. Letztere sind natürlich auch nicht mehr ohne Weiteres beschaffbar, aber immerhin hat man etwas mehr Auswahl für die Suche... Die reinen Ausgangstreiber diskret oder mit ULN2803 bedürfen natürlich noch eines JEWEILS zweiten Pins am Controller, um den gleichen Kanal auch eingangsseitig zu lesen, ca. 100Ohm in jeder I/O-Leitung (zw. µC und Treiber resp. externem Eingang) haben übrigens auch noch nie geschadet (ausser bei extrem Hi-Speed, aber das wäre andere Baustelle...) D.h. sollte man nicht gerade den Controller mit den wenigsten Pins dafür nehmen... Selbst wenn man bei einzelnen Controllern die Ausgänge ganz auf Open-Collector/Drain umstellen kann, würde ich dem Frieden eher nicht trauen, aber wie gesagt: Widerstand mit in die Leitung und alles ist gut... Will man die Eingänge weiter absichern, kann man 2 Dioden 1N4148 von GND nach Signal und Signal nach Vcc schalten (jeweils in Sperrichtung, versteht sich!) Damit leitet man negative resp. zu hohe Eingangsspannungen ab, natürlich nur solange man den Längswiderstand nicht zu klein gewählt hat respektive die angelegte Spannung nicht zu hoch und niederimpedant ist. Es gib dafür natürlich auch passende Doppeldioden in SMD-Packages wie SOT23 etc. Wenn man sich dann noch an die Regel hält, die Geräte nur im ausgeschaltetem Zustand zu verbinden und generell die Masseanbindung an die Stecker vorauseilend gestaltet und massiv auslegt (im Gerät: sternförmige Masse!), dann hat man schon gute Karten, nichts zu zerstören. Ein Interface RS232/USB(serielles Profil) <--> GPIB sollte man immer als Anschlussmöglichkeit für GENAU EIN Messgerät auslegen, dann kann man die (als passend herausgefundene) Initialisierungssequenz im Controller speichern und den Datenkanal transparent auslegen, was oft dazu führt, das man dann Software nutzen kann, die für eine optionale RS232/USB Schnittstelle ab Werk ausgelegt ist (die man aber dummerweise an seinem Gerät nicht hat...) Bislang bin ich fast nur Implementierungen begegnet (Bei Oszis, Generatoren und Netzteilen), die die gleichen Befehle auf beiden Interfaces verwenden, ist ja auch einfacher zu implementieren ;o) Finde die Herangehensweise von Spurtikus (s.o.) sehr gut, nur würde ich eher auf PIC als auf AVR setzen, aber will hier keine Grundsatzdiskussion erzeugen, nur meine Meinung ;o) Will man mehr als ein Messgerät steuern/abfragen, so stellt sich die Frage, ob man sich wirklich den Aufwand PC-seitig in SW antun will, einen GPIB-Controller zu emulieren, oder ob man nicht lieber zwei einzelne Interfaces wie oben baut und betreibt. Hat man Labview oder ein ähnliches Programm, dann stellt sich diese Frage natürlich kaum noch, dann aber eher die, ob das eigene Interface auch genau der von NI vorgegebenen "Meta"-Sprache für die Controllerfunktion entspricht... Vermutlich schreibt man da viel Code auf µC-Seite, der nie zur echten Anwendung kommt, nur um sicher zu gehen, das die Kommunikation auch immer klappt... Bin auf den Thread aufmerksam geworden, da ich für 2 ältere Scopes - die ich aus ebay ergattert und repariert habe - nun vor dem Weiterverkauf eine einfache und zeitgerechte Möglichkeit hinzufügen möchte, um deren Screenshots und eventuell auch Messreihen auf eine SD-Karte oder direkt in den PC zu bekommen. (Wobei ich einer SD-Kartenlösung sehr aufgeschlossen bin, da PC-Kopplung oft bei Messgeräten zu unerwünschten Effekten führt, sei es über die abgestrahlte EMV des PC, sei es über Erdschleifen oder einfach nur fehlendem Platz auf dem Labortisch/Lötplatz...)
Angehängte Dateien:
-
Usb2gpibV2.jpg
51 KB
Hallo zusammen, um ein paar der leider noch immer recht teuren und auch sehr störrischen GPIB-Kabel einzusparen, habe ich meine weiter oben vorgestellte Version des USB-nach-GPIB-Konverters etwas modifiziert: * Bustreiber im SOT-Gehäuse beschafft (Mouser). * Einen männlichen Centronics-Stecker mit Lötkelchen (Mouser), der mit einer Reihe direkt auf die Kante der Leiterplatte gelötet wurde, eingesetzt * Alles in ein kleines Kunststoffgehäuse (Reichelt) montiert * Aus zwei Stücken 4mm-V2A-Rundstahl, einem M3,5-Schneideisen (eBay) mit etwas Gewalt und einem Akkuschrauber zwei lange Verschraubungen "gezaubert" Neben der Hardware wurde auch die Software erweitert: SRQ wird nun auf das Ring-Indicator-Signal des CDC-Interface umgesetzt, so dass der Host darüber den Zustand der SRQ-Leitung pollen kann, um anschließend ggf. einen Serial Poll durchzuführen. Vielleicht implementiere ich auch noch das Parallel Poll, Platz hätte ich noch; die Firmware belegt weniger als 14k der zur Verfügung stehenden 32k des mega32U4-Flashs -- trotz stärkster Speed-Optimierung. Ein kleiner Hinweis am Rande: Die aktuellen TI-Datenblätter der SN75161 und 162 enthalten einen Fehler: Die Richtung des SRQ-Signals ist invertiert dargestellt. Sie muss dem ATN-Signal entgegengesetzt sein. In einem uralten National-Semiconductor-Datenblatt ist es korrekt eingezeichnet. Grüßle Volker
:
Bearbeitet durch User
Volker B. schrieb: > Bustreiber im SOT-Gehäuse beschafft (Mouser). Kannst du eine Bestellnummer angeben?
Florian schrieb: >> Bustreiber im SOT-Gehäuse beschafft (Mouser). > > Kannst du eine Bestellnummer angeben? Kein Problem! 595-SN75160BDWR 595-SN75162BDWR Den '161 haben die auch noch im Programm (Artikelsuche: SN75161) Der Vollständigkeit halber hier noch die Nummer des Centronics-Männchens: 636-111-024-103L001 Grüßle Volker.
:
Bearbeitet durch User
Hallo zusammen, da der GPIB hier noch Interesse findet, ein kleiner Hinweis: Der freie Software-Logic-Analyzer Sigrok besitzt mittlerweile einen GPIB-Protokolldecoder. In Verbindung mit einem billigen Cypress EZ-USB-Evaboard (das man online schon für ein paar Euro bekommt) und einer einfachen Pegelanpassung mittels 74VHC245 oder Spannungsteilern, erhält man für weniger als EUR 10,-- einen netten kleinen GPIB-Monitor, der mit bis zu 12MHz samplen kann. Grüßle Volker
Volker B. schrieb: > Neben der Hardware wurde auch die Software erweitert: SRQ wird nun auf > das Ring-Indicator-Signal des CDC-Interface umgesetzt, so dass der Host > darüber den Zustand der SRQ-Leitung pollen kann, um anschließend ggf. > einen Serial Poll durchzuführen. Kannst Du den Source Deiner Firmware-Erweiterung noch posten? Danke.
Gerd E. schrieb: > Kannst Du den Source Deiner Firmware-Erweiterung noch posten? Nein, das möchte ich nicht. Wie ich in meinem ersten Artikel schrieb, kombinierte ich Svens Firmware mit dem CDC-Device aus dem LUFA-USB-Stack. Ich habe keine große Lust, die entsprechenden Copyrights auseinander zu dividieren -- und noch viel weniger, alles "nachbausicher" zu dokumentieren. Ich gebe aber gerne Hilfestellung, falls jemand diese Arbeit "richtig und sauber" machen will. Außerdem habe ich Svens Code auf eine andere MCU portiert, wodurch mein Code definitiv nicht mehr zum Original kompatibel ist. Grüßle Volker
:
Bearbeitet durch User
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.