Ich verzweifle gerade am KE5FX toolkit.
Ich habe Hans' schönen AR488-Adapter aus der Sammelbestellung, der
soweit auch funktioniert. Nun wurde mir in
Beitrag "Sammelbestellung AR488 kompatibler USB-GPIB Adapter. Interesse?"
empfohlen, den KE5FX-Toolkit zu benutzen, um einen HP-GL-Plotter zu
emulieren. Im Prinzip läuft der Toolkit unter Wine, aber ich komme mit
der Konfiguration des COM-Ports dort nicht klar.
Ich habe Wine so konfiguriert, dass es das CDC-Device des AR488 als COM5
mappt (da es nicht gleich klappte, sowohl per Eintrag
HKLM\Sofware\Wine\Ports über winereg als auch per Symlink in
~/.wine/dosdevices).
Wenn ich PuTTY darauf loslasse, kann ich mich mit COM5 verbinden und
++ver zeigt mir den Versionsstring des AR488 an.
Der KE5FX-Toolkit findet aber nichts. Wenn ich prologix.exe aufrufe,
sehe ich keine Geräte zur Auswahl. Ich editiere da drin das connect.ini
und trage ein
interface_settings com5:baud=115200 parity=N data=8 stop=1
Abspeichern -> keine Änderung
Hat jemand noch Ideen?
> The GPIB Toolkit is provided with full C++ source code for public-> and private-sector, educational and Amateur Radio / hobbyist use.
(Aus irgendeinem Grund aber hinter so einem beknackten Exe-Installer
versteckt)
... Oh. Ach Du Scheiße. Der packt den Sourcecode nach "c:\program files"
Das ist derb.
Oh, und der Sourcecode ist ... hässlich. Ich hab' ja schon wirklich
hässliches Windows-Gefrickel gesehen, aber das hier ist schon sehr
speziell.
Fängt schon mit den benutzerdefinierten Typen an, und dann wird auf die
"ini-Datei" nicht mit den dafür vorgesehenen Funktionen
(GetPrivateProfile-Etcetera) zugegriffen, sondern mit einem irgendwie
selbstgefrickelten Parser.
Und die serielle Schnittstelle .. wird mit BuildCommDCB angesteuert. Daß
jemand diese Funktion verwendet, habe ich zuletzt irgendwann in den
frühen 90ern gesehen, als ich noch mit 16-Bit-Windows unterwegs war.
Der String in der sogenannten "Ini-Datei" wird direkt dieser Funktion
übergeben:
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-buildcommdcba
Hmm. Ganz dumme Frage: Hast Du beim Bearbeiten der Datei daran gedacht,
daß unter Windows CRLF als Zeilentrenner verwendet wird, und manche
Software da sehr penibel ist? Ich nehme an, daß Du einfach irgendeinen
Texteditor verwendet hast, und vermutlich nutzt der einen anderen
Zeilentrenner ...
Jörg W. schrieb:> Hat jemand noch Ideen?
Hast du mal versucht einen simplen seriell-USB Adapter mit dem Tool zu
öffnen? Oder evtl. hast du einen native seriellen Port den du in wine
mappen kannst. Nur um zu sehen ob es grundsätzlich geht.
Aber wenn die SW schon so gruselig ist, vielleicht nimmt sie auch einen
speziellen Weg um serielle Schnittstellen zu nutzen. Und der klappt mit
wine nicht.
Sonst vielleicht eine Windows VM probieren.
Jörg W. schrieb:>> Hat jemand noch Ideen?
Es gibt wohl Probleme weil sich zumindest der original AR488 nicht
vollkommen identisch wie der Prologix verhält, siehe u.a. hier:
https://ar488.readthedocs.io/en/latest/main/tools.html
Ob das auch das Problem unter Wine ist kann ich nicht sagen, ich habe
den Adpater aus der Sammelbestellung noch nicht mit dem KE5FX-Toolkit
ausprobiert.
900ss schrieb:> Aber wenn die SW schon so gruselig ist, vielleicht nimmt sie auch einen> speziellen Weg um serielle Schnittstellen zu nutzen. Und der klappt mit> wine nicht.
Ich könnte die Soße morgen mal nebenbei meinem Compiler vorwerfen und
sehen, was das Zeug so macht, vielleicht ist ja die Fehlerbehandlung
ähnlich, ähm, "ausführlich" wie der Sourcecode lesbar.
Das aber würde ich nur tun, um Jörg einen Gefallen zu machen.
Falls sich jemand das ansehen will, ich hab' den Sourcecode (bis auf die
diversen Ressourcen-Dateien) mal extrahiert und hier angehängt.
Allerdings hab' ich keinen GPIB-Adapter, kann das also funktional nicht
testen.
Harald K. schrieb:>> Und die serielle Schnittstelle .. wird mit BuildCommDCB angesteuert. Daß> jemand diese Funktion verwendet, habe ich zuletzt irgendwann in den> frühen 90ern gesehen, als ich noch mit 16-Bit-Windows unterwegs war.
Nur zur Klarstellung: Der kostenlose KE5FX GPIB Toolkit, den man mit
Source Code bekommt, arbeitet unter Windows problemlos mit sehr vielen
unterschiedlichen GPIB Adaptern und macht einige Dinge, die man sonst
nirgends oder nur gegen sehr gute Bezahlung bekommt.
Aber es gibt halt auch ganz schlaue Schwätzer die nur eines gut können:
schlau daher reden.
Ach ja, mit dem Source Code kommt man ebenfalls gut klar, zumindest wenn
man mehr kann als nur schlau daher reden.
Dieter S. schrieb:> Ach ja, mit dem Source Code kommt man ebenfalls gut klar, zumindest wenn> man mehr kann als nur schlau daher reden.
Dann mach doch.
Harald K. schrieb:>> The GPIB Toolkit is provided with full C++ source code for public->> and private-sector, educational and Amateur Radio / hobbyist use.>> (Aus irgendeinem Grund aber hinter so einem beknackten Exe-Installer> versteckt)
yup
Aber zumindest hat der erstmal funktioniert.
> ... Oh. Ach Du Scheiße. Der packt den Sourcecode nach "c:\program files"
Ja, gleich neben die Executables.
> Fängt schon mit den benutzerdefinierten Typen an, und dann wird auf die> "ini-Datei" nicht mit den dafür vorgesehenen Funktionen> (GetPrivateProfile-Etcetera) zugegriffen, sondern mit einem irgendwie> selbstgefrickelten Parser.
Scheint mir alles sehr, naja, "historisch gewachsen".
> Und die serielle Schnittstelle .. wird mit BuildCommDCB angesteuert.
An welcher Stelle eigentlich? Die habe ich noch nicht gefunden.
> Daß> jemand diese Funktion verwendet, habe ich zuletzt irgendwann in den> frühen 90ern gesehen, als ich noch mit 16-Bit-Windows unterwegs war.
Wenn man sieht, dass noch irgendwelche Workarounds für Win98SE drin
sind, aus der Zeit wird der Code stammen.
enumerate_ports() in prologix.cpp geht irgendwie über
SetupDiClassGuidsFromNameA(). Ich würde mir ja mal ausgeben lassen, was
dort unter Wine alles so gefunden wird, aber ich habe keinen
Windows-Cross-Compiler zur Hand. Der FreeBSD-Port für mingw32-gcc wurde
vor einiger Zeit eingestampft, weil das MinGW32-Projekt tot ist, einen
anderen habe ich aber auch nicht.
> Hmm. Ganz dumme Frage: Hast Du beim Bearbeiten der Datei daran gedacht,> daß unter Windows CRLF als Zeilentrenner verwendet wird, und manche> Software da sehr penibel ist?
Da ich gar nicht gewusst hätte, wo die Datei zu finden ist, habe ich die
dort eingebaute Funktion zum Editieren der Datei aufgerufen. Diese
wiederum startet ein notepad.exe. Daran sollte es also nicht liegen …
900ss schrieb:> Hast du mal versucht einen simplen seriell-USB Adapter mit dem Tool zu> öffnen?
Ich bekomme das Tool ja gar nicht dazu, mir irgendwas anzuzeigen.
Wie geschrieben, am Mapping in Wine liegt es nicht, denn PuTTY kann auf
COM5 zugreifen.
Dieter S. schrieb:> Es gibt wohl Probleme weil sich zumindest der original AR488 nicht> vollkommen identisch wie der Prologix verhält,
Hans' AR488 nutzt ja eine CDC, die sowieso die Signale nur emuliert. Es
sieht so aus, als würde die CDC tatsächlich kein CTS (virtuell) anlegen.
Wenn ich auf dem Host mit Kermit drauf gehe und mir den Status anzeigen
lasse, bekomme ich:
Dieter S. schrieb:> Der kostenlose KE5FX GPIB Toolkit, den man mit Source Code bekommt,> arbeitet unter Windows problemlos mit sehr vielen unterschiedlichen GPIB> Adaptern und macht einige Dinge, die man sonst nirgends oder nur gegen> sehr gute Bezahlung bekommt.
Das mag ja sein, aber im vorliegenden Fall funktioniert er erstmal
schlicht nicht, und es ist noch nicht völlig klar, woran das liegt. (Es
gibt ja auch noch niemanden, der besagten AR488 native unter Windows
damit zum Laufen bekommen hat.)
"kostenlos" als Qualitätskriterium zu deklarieren, ist ohnehin nicht
sinnvoll, und dass man den Sourcecode direkt neben die Executables legt
ist, naja, nennen wir es mal "unorthodox".
Jörg W. schrieb:>> Und die serielle Schnittstelle .. wird mit BuildCommDCB angesteuert.>> An welcher Stelle eigentlich? Die habe ich noch nicht gefunden.
Ah gefunden. gpiblib/comblock.h, Klasse SERBLOCK. (Klassennamen in ALL
CAPS ist auch nicht gerade üblicher coding style.)
Jörg W. schrieb:>> Das könnte auf das oben genannte Problem mit CTS deuten. Vielleicht> müsst man das Ganze nur mal recompilieren mit
Es muss nichts neu kompiliert werden, es reicht wenn man mit "++id
verstr" den AR488 Version String setzt. Da prologix.cpp "Version x.x"
erwartet (das V zählt nicht), der Adapter aber "ver. x.x" schickt
klappt es nicht. Mit der Versionsnummer muss man eventuell
experimentieren weil diese die Features festlegt. Zumindest funktioniert
dann die Erkennung des Adapters unter Windows.
Übrigens, Deine Einstellung auch noch Erwartungen an kostenlose
Software, die mit Source Code kommt, zu stellen finde ich schon sehr
seltsam. "Früher" hieß es mal "nimm den Source Code und mach es selber
wenn Dir was nicht passt" aber so ändern sich die Zeiten...
Dieter S. schrieb:> Zumindest funktioniert> dann die Erkennung des Adapters unter Windows.
Ah okay, das hätte ich sonst nachher mal in einer Windows-VM probiert.
Kurzer Nachtrag zu weiter oben: Es ist die Datei "gpiblib\gpiblib.cpp",
die den Versionsstring auswertet, nicht prologix.cpp.
"++id verstr Version 4.0" ist die Einstellung für einen möglichen
Versionsstring der funktioniert, aber wie schon geschrieben, anhand der
Versionsnummer werden die Features des Adapters festgelegt, das müßte
man sich eventuell noch genauer ansehen.
Harald K. schrieb:> ... Oh. Ach Du Scheiße. Der packt den Sourcecode nach "c:\program files">> Das ist derb.>> Oh, und der Sourcecode ist ... hässlich.
Ich fand dazu in den FAQ von KE5FX diesen Kommentar:
It's important to note that each of these tools was written -- usually
in a hurry -- in response to a need I've encountered in my own work.
They're not meant to be polished commercial-quality applications, and
they often play fast and loose with current best practices in
professional Windows development.
:)
Dieter S. schrieb:> "Früher" hieß es mal "nimm den Source Code und mach es selber wenn Dir> was nicht passt"
Würde ich ja tun, wenn es denn so einfach wäre.
Da ich kein Windows habe, muss ich leider erstmal gucken, wie ich einen
Crosscompiler dafür zum Laufen bekomme. Hatte jetzt den Tipp bekommen,
MinGW64 unter Wine zu installieren, mal gucken.
Das mit der Versionsnummer werde ich mal probieren, ich habe nur den
Eindruck, dass die KE5FX-Tools bislang noch gar nicht mit der
Schnittstelle überhaupt reden. Da kann ich mich natürlich auch täuschen.
900ss schrieb:> Ich fand dazu in den FAQ von KE5FX diesen Kommentar:
Das erklärt es durchaus.
Jörg W. schrieb:>> Das mit der Versionsnummer werde ich mal probieren, ich habe nur den> Eindruck, dass die KE5FX-Tools bislang noch gar nicht mit der> Schnittstelle überhaupt reden. Da kann ich mich natürlich auch täuschen.
Zwei Screenshots von prologix.exe unter Windows, einmal ohne Anpassung
der Version (AR488_original_Version.PNG) das andere mal mit Anpassung
(AR488_Version_4_0.PNG). Wenn die Kommunikation passt wird immer etwas
angezeigt, auch wenn der Adapter nicht erkannt wird.
"GPIB0" im Screenshot ist eine GPIB Karte, "COM1" die serielle
Schnittstelle des PC, die werden also bei Dir nicht zu sehen sein und
COM215 mit dem AR488 heißt sicher anders.
Bei mir ist da schlicht gar nichts zu sehen, auch keine Standard-COM1
(die per Default auf die serielle Hardware-Schnittstelle des PCs gezeigt
hatte).
Ob das nun an Wine liegt oder an den KE5FX-Tools, wird man wohl nur
durch weitere Tests finden können. Erstmal brauche ich dafür einen
Crosscompiler. Wie oben geschrieben, PuTTY kann unter Wine drauf
zugreifen, also ist nicht so, dass es grundsätzlich gar nicht geht.
Jörg W. schrieb:> Bei mir ist da schlicht gar nichts zu sehen
Unter wine könntest du putty nutzen und den Adapter testen. Hab ich
gerade gemacht. Ich habe den GPIB-Adapter angeschlossen, dass device
ttyACM0 wurde automatisch auf com35 gemappt.
Bei putty hab ich nur die Baudrate von 9600 auf 115200 gesetzt was
wahrscheinlich nicht nötig ist. Und ich habe com35 als serial line
eingetragen und auf Open geklickt. Dann konnte ich mit dem Adapter
reden.
Also ich habe die Adresse mit ++addr abgefragt, dann geändert und wieder
abgefragt. Hat funktioniert.
++ver ergab: "AR488 GPIB controller, ver. 0.49.4, 02/03/2021".
putty version ist 0.74.
Damit wäre dann erstmal sichergestellt das der Port mit dem Adapter
unter wine grundsätzlich funktioniert.
Oder du weißt das schon, was ich aber nicht rauslesen konnte ;)
900ss schrieb:> Jörg W. schrieb:>> Bei mir ist da schlicht gar nichts zu sehen>> Unter wine könntest du putty nutzen und den Adapter testen.
Hatte ich geschrieben ;-), habe ich gemacht, damit funktioniert es. Nur
der KE5FX sieht nichts davon.
Jörg W. schrieb:> Bei mir ist da schlicht gar nichts zu sehen, auch keine Standard-COM1> (die per Default auf die serielle Hardware-Schnittstelle des PCs gezeigt> hatte).
Eventuell liegt es nur daran wie prologix.exe die verfügbaren COM Ports
ermittelt. Aber man kommt auch ohne prologix.exe aus, man kann ja
connect.ini auch per Hand editieren.
Wenn in connect.ini der richtige COM Port eingetragen ist, also z.B. so
passend zu den Screenshots weiter oben:
kann man folgendes ausprobieren:
- 7470.exe starten
- Menü "Acquire" - "Wait for device-initiated plot" auswählen
- geht das schief weil die Schnittstelle nicht erkannt wird kommt eine
Fehlermeldung:
1
---------------------------
2
CreateFile error: Port unavailable or in use
3
---------------------------
4
Das System kann die angegebene Datei nicht finden.
- geht das schief weil die Kommunikation über die Schnittstelle mit dem
Adapter nicht funktioniert kommt eine Fehlermeldung:
1
---------------------------
2
GPIB Error
3
---------------------------
4
Read error: 0x2
5
(Communications error)
- ist der COM Port verfügbar und die Kommunikation funktioniert halbwegs
sieht es so wie im Screenshot aus.
Das ist erstmal nur ein Test ob der GPIB Toolkit die serielle
Schnittstelle sieht und der Adapter irgendwas bei "++ver" zurückschickt,
die Version ist hier egal.
Dieter S. schrieb:> Eventuell liegt es nur daran wie prologix.exe die verfügbaren COM Ports> ermittelt. Aber man kommt auch ohne prologix.exe aus, man kann ja> connect.ini auch per Hand editieren.
connect.ini lässt sich ja über prologix.exe (und dessen Aufruf von
notepad) editieren, das ist bereits erfolgt.
> - 7470.exe starten>> - Menü "Acquire" - "Wait for device-initiated plot" auswählen
An der Stelle passiert schlicht nichts. Kein Fehler, gar nichts.
Jörg W. schrieb:>> An der Stelle passiert schlicht nichts. Kein Fehler, gar nichts.
Mach doch mal den Vergleich was passiert wenn ein nicht vorhandener COM
Port eingestellt ist und, falls das möglich ist, ein COM Port auf dem
nichts zurück kommt wenn man etwas schickt. Das Ganze nur um sicher zu
sein dass diese Zustände erkannt werden.
Alternativ, kannst Du unter Wine sehen was auf der seriellen
Schnittstelle passiert? Es müßten folgende Kommandos zu sehen sein:
Dieter S. schrieb:> Alternativ, kannst Du unter Wine sehen was auf der seriellen> Schnittstelle passiert?
So richtig nicht bzw. ich weiß nicht wie.
Ein syscall tracer zeigt mir erstmal nichts in Richtung meiner
Schnittstelle. Allerdings ist mir die Architektur von Wine auch nicht
komplett klar. Es könnte sein, dass das über den wineserver läuft und
ich den noch nicht getracet habe.
Jörg W. schrieb:>> So richtig nicht bzw. ich weiß nicht wie.
Eventuell zwei "USB auf Seriell" (RS232 oder UART) Adapter, beide
verbinden (Nullmodem), einen nach Wine durchreichen, den zweiten unter
Linux mit einem Terminalprogramm beobachten. Da es fast nur lesbare
Texte bei den Kommandos sind sollte das eigentlich ausreichen.
Hugo H. schrieb:> Schau mal da
Hatten wir schon.
Da Hans' AR488-Nachbau ein CDC benutzt, helfen die dortigen Workarounds
nicht. Wenn, dann müsste man die Steuersignale auf CDC-Ebene anders
emulieren. Diskussion dazu gibt's im AR488-Thread. Aber ich bin noch
nicht völlig davon überzeugt, dass es das bringt. Ich denke immer noch,
das KE5FX irgendwas mit den seriellen Schnittstellen drastisch anders
macht als andere (wie beispielsweise PuTTY), und dass es deshalb unter
Wine nicht richtig geht.
Aber erstmal brauch ich dafür einen Compiler, um auch mal Debugausgaben
in den Code einbauen zu können.
Ich habe mir die KE5FX Tools auch eben unter wine installiert.
Ist hier auch so, es werden keine seriellen ports aufgelistet während
putty funktioniert.
Ich nutze wine-10.0 unter Linux Mint.
Jörg W. schrieb:>> Ich denke immer noch, das KE5FX irgendwas mit den seriellen Schnittstellen> drastisch anders macht als andere (wie beispielsweise PuTTY), und dass es> deshalb unter Wine nicht richtig geht.
Ich gehe stark davon aus dass lediglich das Enumerieren der COM Ports in
prologix.cpp ungewöhnlich ist und dieses Tool ist nur für das einfache
Konfigurieren zuständig. Daher auch der Vorschlag weiter oben mit
7470.exe ohne das Enumerieren der COM Ports.
Die Kommunikation in comport.cpp ist eigentlich Standard und dieser Teil
wird für die restlichen Tools verwendet (wenn per COM Port kommuniziert
wird).
> Aber erstmal brauch ich dafür einen Compiler, um auch mal Debugausgaben> in den Code einbauen zu können.
Geht unter Windows problemlos mit der Microsoft Visual Studio IDE,
selbst mit ziemlich alten Versionen.
Jörg W. schrieb:>> "Früher" hieß es mal "nimm den Source Code und mach es selber wenn Dir>> was nicht passt">> Würde ich ja tun, wenn es denn so einfach wäre.
OK, dank eines Tipps aus den FreeBSD-Foren habe ich jetzt mingw64 unter
Wine installiert. Damit lässt sich zumindest prologix.cpp compilieren,
wenngleich auch mit 151 Warnungen (insbesondere darüber, dass man eine
String-Konstante nicht zu C8* wandeln darf).
Das sollte erstmal als Basis genügen, um da ein paar Debug-Zeilen
einbauen zu können.
Welches "make" würde man nehmen, das mit dem mitgelieferten makefile
zurecht kommnt?
Dieter S. schrieb:>> Aber erstmal brauch ich dafür einen Compiler, um auch mal Debugausgaben>> in den Code einbauen zu können.>> Geht unter Windows problemlos mit der Microsoft Visual Studio IDE,> selbst mit ziemlich alten Versionen.
Ich glaube, die will ich mir unter Wine nicht auch noch antun, wenn sie
denn überhaupt installieren würde.
Dann lieber mingw64.
Jörg W. schrieb:>> Ich glaube, die will ich mir unter Wine nicht auch noch antun, wenn sie> denn überhaupt installieren würde.
Eventuell mit ein wenig Anpassung am Makefile würde es relativ sicher
auch mit den uralt Windows DDKs funktionieren. Das waren "damals" nur
die Commandline Tools ohne die IDE mit überschaubarer Größe und obwohl
es "Driver Development Kit" heißt kann man damit auch andere Windows
Komponenten entwickeln (den Windows SDK gab es ja ebenfalls).
Dieter S. schrieb:> würde es relativ sicher> auch mit den uralt Windows DDKs funktionieren.
Äh, nein. Das DDK ist das "Driver Development Kit", das benutzt(e) man,
um Devicetreiber zu erzeugen. Falsche Baustelle, Du meinst das SDK, aber
das enthält schon lange keinen Kommandozeilencompiler mehr.
Harald K. schrieb:>> Äh, nein. Das DDK ist das "Driver Development Kit", das benutzt(e) man,> um Devicetreiber zu erzeugen. Falsche Baustelle, Du meinst das SDK, aber> das enthält schon lange keinen Kommandozeilencompiler mehr.
Du bist so schlau, schrieb ich ja schon weiter oben.
Ich habe mich auf "uralt Windows DDKs" bezogen, dazu Zitat aus
"relnote.htm" zu "Windows Server 2003 Service Pack 1 (SP1) - Driver
Development Kit (DDK)":
"The Microsoft® Windows® DDK ships a complete set of tools for building
drivers. These tools have been upgraded from those released with the
Windows XP DDK. As in the Windows XP DDK, Microsoft Visual C++® is no
longer required to be installed.
Use the included tools for all Windows Server™ 2003, Windows XP, and
Windows 2000, drivers. This version of the DDK does not support building
drivers using a version of Visual C++ other than the one supplied with
the DDK."
Dieter S. schrieb:> "The Microsoft® Windows® DDK ships a complete set of tools for building> drivers.
Hier geht es aber darum eine Anwendug zu debuggen das ist etwas ganz
anderes. Hast du schon mal einen Treiber geschrieben und mit diesen
Tools gearbeitet ?
Hans-Georg L. schrieb:> Hier geht es aber darum eine Anwendug zu debuggen das ist etwas ganz> anderes.
Nö, es ging um den Compiler. Der war damals wohl halt beim DDK mit
dabei.
Habe jetzt die virtuelle Disk in meiner Windows-VM vergrößert, um den
Studio-Kram da mal reinzupopeln. Eigentlich bräuchte ich ja nur mal ein
nmake.exe, aber das gibt's nicht mehr einfach so, ohne dass man viele
Gigabyte and Rundherum mit installiert.
Jörg W. schrieb:> Habe jetzt die virtuelle Disk in meiner Windows-VM vergrößert, um den> Studio-Kram da mal reinzupopeln.
Grummel, geht nicht.
"Bevor wir loslegen
Sie sind nicht mit dem Internet verbunden."
Quark, natürlich kann die VM ins Netz, alle anderen Anwendungen außer
diesem *** Installer haben kein Problem damit. (Der Installer hatte ja
zuvor auch schon Kram runter geladen, nur dann musste ich die VM nochmal
runterfahren, um die virtuelle Disk zu vergrößern.)
Da werde ich wohl auf nmake.exe verzichten und das Makefile für ein
anderes make umbauen.
Jörg W. schrieb:> Damit lässt sich zumindest prologix.cpp compilieren,> wenngleich auch mit 151 Warnungen (insbesondere darüber, dass man eine> String-Konstante nicht zu C8* wandeln darf).
Sind halt nicht nur Warnungen, sondern auch errors:
1
prologix.cpp: In function 'void show_last_error(C8*, ...)':
2
prologix.cpp:645:22: error: invalid conversion from 'const void*' to 'LPVOID' {aka 'void*'} [-fpermissive]
3
645 | LPVOID lpMsgBuf = "Hosed"; // Default message for Win9x (FormatMessage() is NT-only)
Vielleicht gibt Dir die Anlage Inspiration - ist alt, aber ich finde
z.B. die Aussage zu "Leerzeichen in Pfadnamen" (wenn ich Deine Pfadnamen
mit Punkten so betrachte) ganz interessant.
Hast Du aber vermutlich auch schon gelesen ...
Hans-Georg L. schrieb:>> Hier geht es aber darum eine Anwendug zu debuggen das ist etwas ganz> anderes. Hast du schon mal einen Treiber geschrieben und mit diesen> Tools gearbeitet ?
Schon wieder ein ganz Schlauer. Es wurde eine Build-Umgebung gesucht, um
den Source Code des KE5FX GPIB Toolkit zu übersetzen. Ich habe die alten
Windows DDKs deshalb empfohlen weil da alles nötige enthalten ist (und
nur das, ohne den Ballast einer IDE), diese eine noch relativ
überschaubare Größe haben und zur Not auch ohne Installation
funktionieren.
Und ja, ich habe damit schon einige Treiber geschrieben, auch wenn das
nichts zur Sache tut.
Hugo H. schrieb:> wenn ich Deine Pfadnamen mit Punkten so betrachte
Die haben allerdings nichts mit Leerzeichen gemein. Die kommen nur von
der Toolchain, weil sie auf diese Weise self-contained ist und mit
relativen Pfadnamen ihre Komponenten suchen kann.
Zumindest habe ich jetzt auch ein nmake.exe (für das das originale
makefile geschrieben wurde). Außerdem habe ich alles mal in ein lokales
git Repo gepackt. Leider finde ich keine richtige Lizenz da drin, die es
gestatten würde, das bspw. auf github allen in dieser Form verfügbar zu
machen.
Harald K. schrieb:> Jörg W. schrieb:>> Fehlt mir da noch die Angabe irgendeiner Bibliothek?>> Das dürfte die Importlibrary für die Winsock-Funktionen sein.
OK, mal gucken, wie die bei mingw64 heißt.
Nächster Stolperstein allerdings:
1
specan.cpp:251:10: fatal error: ni488.h: No such file or directory
Die kommt vermutlich von irgendwelchem National Instruments Paketen,
oder?
Ah OK, dann hätte er #include "gpiblib/ni488.h" schreiben sollen oder
einen Kommandozeilenschalter für das Verzeichnis im Makefile haben
müssen.
Strange.
Jörg W. schrieb:> Ah OK, dann hätte er #include "gpiblib/ni488.h" schreiben sollen oder> einen Kommandozeilenschalter für das Verzeichnis im Makefile haben> müssen.
Dieser Teil wird ja nur für 64-Bit verwendet, da der Toolkit wohl bisher
nur als 32-Bit Build ausgeliefert wird könnte das bisher nicht
aufgefallen sein.
BTW, der Adapter und 7470.exe funktionieren mit einem HP8569B, der
sollte sich wie Dein Advantest verhalten. Allerdings ging das bei mir
nur nach einer kleinen Modifikation am Adapter, die Details werde ich
später im Thread zur Sammelbestellung schreiben.
Nachtrag: Zumindest beim HP8569B kann man das Ganze auch nur per
Terminalprogramm erledigen, die Kommandos an den Plotter sind nur Text.
Wenn man das dann in Grafik umgewandelt bekommt (7470.exe sollte das
können) hätte man das selbe Ergebnis, nur nicht ganz so komfortabel.
Damit reicht es wenn die serielle Kommunikation per Terminalprogramm
funktioniert.
Dieter S. schrieb:> Nachtrag: Zumindest beim HP8569B kann man das Ganze auch nur per> Terminalprogramm erledigen, die Kommandos an den Plotter sind nur Text.
Stimmt natürlich, ich muss den Adapter ja nur auf einer bestimmten
Adresse hören lassen, das geht per ++ Kommandos. Gute Idee!
Mehr als HP-GL brauche ich an sich nicht, damit komme ich dann schon
klar.
> Dieser Teil wird ja nur für 64-Bit verwendet, da der Toolkit wohl bisher> nur als 32-Bit Build ausgeliefert wird könnte das bisher nicht> aufgefallen sein.
Das würde es natürlich erklären. Ich muss dann wohl den Compiler einfach
mal im 32-Bit-Modus starten.
Jörg W. schrieb:>> Stimmt natürlich, ich muss den Adapter ja nur auf einer bestimmten> Adresse hören lassen, das geht per ++ Kommandos. Gute Idee!
Eine Adresse wird nicht benötigt, der Advantest sollte sich eigentlich
wie mein HP8569B verhalten, das wären dann nur die folgenden Kommandos
(Device Mode, Listen Only):
1
++mode 0
2
++lon 1
Eventuell muss man noch EOI und EOS richtig konfigurieren.
Ob es aber auch ohne die bei mir nötige Hardware Modifikation geht kann
ich nicht sagen, ich habe nur einen dieser Adapter zum Testen.
Dieter S. schrieb:> Ob es aber auch ohne die bei mir nötige Hardware Modifikation geht kann> ich nicht sagen, ich habe nur einen dieser Adapter zum Testen.
Scheint erstmal nicht zu klappen. Ich werde mir deine
Hardwaremodifikation mal ansehen.
Jörg W. schrieb:> OK, mal gucken, wie die bei mingw64 heißt.
Falls Du keine findest, prinzipiell kann man sich die auch selbst
stricken. Das ist nämlich nur eine Importlibrary für die gleichnamige
DLL. Und es gibt Werkzeuge, mit denen man eine solche Importlibrary
automatisch erzeugen kann.
Das müssten "dlltool" und "gendef" sein.
gendef ws2_32.dll
Das Sollte eine Datei namens ws2_32.def erzeugen, die für den nächsten
Schritt benötigt wird.
dlltool --ddlname ws2_32.dll --def ws2_32.def --output-lib ws2_32.lib
Und das erzeugt die Library.
Dabei musst Du darauf achten, die richtige Version der dll zu verwenden;
wenn Du 32-Bit-Code erzeugen willst, liegt die auf einem normalen
Windows-System unter c:\windows\syswow64, während die 64-Bit-Version
unter c:\windows\system32 liegt.
Ja, das klingt schwachsinnig, ist aber so.
Jörg W. schrieb:> Scheint erstmal nicht zu klappen. Ich werde mir deine> Hardwaremodifikation mal ansehen.
Ich kann deine Hardwaremodifikation nachvollziehen. Nur mit dem Pullup
an REN/DC funktioniert es bei mir nicht: sowie der Spekki was senden
will, entsteht da eine Art Schwingung von reichlich 10 MHz, weil der
Spekki offenbar auch REN immer wieder herunter zieht, was natürlich DC
beeinflusst.
Erst wenn ich (wie du) DC hart per Pullup auf high setze (und dann erst
nach ++mode 1 den AR488 an den Bus stecke), funktioniert das Plotten.
Anbei das Spektrum der Rundfunksender.
Aber alles in allem klingt das nach Fortschritt. 7470.exe brauch ich
dann auch nicht unbedingt, HP-GL-Daten kann ich auch mit anderen Mitteln
weiter verarbeiten (habe ich früher schon bei einem HP54512B gemacht).
Thread beobachten
Seitenaufteilung abschalten