mikrocontroller.net

Forum: Projekte & Code GPIB-RS232-Schnittstelle


Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
He,

dieser ist der Thread zum Artikel: GPIB-RS232-Schnittstelle.

Viel Spaß damit,
Sven

Autor: Sven P. (haku) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Firmware zum 30. April 2012.

Verwendung unter den Bedingungen der GPLv3.

Autor: Willi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hownottobeseen (ohne Login) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Glückwunsch Sven,

Du würdest ge-hackaday-ed: 
http://hackaday.com/2012/05/01/gpib-connectivity-twofer/

Autor: Adi K. (adi-ch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
    _DC = 0;
    _SC = 1;
bzw
    _DC = 1;
    _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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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'.

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcel Klug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

ich danke schonmal für antworten !

mfg sunny

Autor: Marcel klug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: khmweb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Info: Alle Dateien konnten entweder mit 7zip oder eagle 6.2.0 problemlos 
geöffnet werden.

Autor: Der Rächer der Transitormorde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcel klug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Der Rächer der Transitormorde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcel klug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcel Klug (sunny198828)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: amateur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcel Klug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcel Klug (sunny198828)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Rächer der Transitormorde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcel Klug (sunny198828)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay ich hab das was gefunden
http://www.google.de/url?sa=t&rct=j&q=&esrc=s&sour...

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

Autor: Marcel Klug (sunny198828)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/do...

nun weiß ich aber nicht welches betriebsystem und wie ich die daten 
jetzt versende (programm)

ich hoffe mir kann jemand helfen

mfg sunny

Autor: Joachim ... (joachim_01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: none (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

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

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: asd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Board in Originalgröße. Ist allerdings nun das neue XML-Format von 
Eagle, für das alte hab ich keine Lizenz.

Autor: asd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.")

Autor: asd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: asd (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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__...

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?

Autor: asd (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: Volker Bosch (Firma: L-E-A) (vobs)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Denis Köllner (denis_tbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist es möglich für den USB-GPIB Adapter einen Schaltplan sowie den 
Source zu bekommen?

Grüße

Autor: Marian  ​ (phiarc) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Rob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)

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.