Forum: PC Hard- und Software KE5FX toolkit unter Wine: Einstellungen COM-Port


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

>  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 ...

von 900ss (900ss)


Lesenswert?

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.

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

Das hier habe ich eben noch gefunden dazu...
https://usercomp.com/news/1036506/application-under-wine-cannot-access-any-serial-ports

Da stehen workarounds drin. Mal ausprobieren. Scheint nicht ungewöhnlich 
dein Problem unter wine.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Angehängte Dateien:

Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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:
1
Communications Parameters:
2
 Line: /dev/cu.0, speed: 115200, mode: local, modem: generic
3
 Parity: none, stop-bits: (default) (8N1)
4
 Duplex: full, flow: none, handshake: none
5
 Carrier-watch: off, close-on-disconnect: off
6
 Lockfile: /var/spool/lock/LCK..ptscuaU5
7
 Terminal bytesize: 8, escape character: 28 (^\)
8
9
 Carrier Detect      (CD):  Off
10
 Dataset Ready       (DSR): Off
11
 Clear To Send       (CTS): Off
12
 Ring Indicator      (RI):  Off
13
 Data Terminal Ready (DTR): On
14
 Request To Send     (RTS): On

Wäre jetzt die Frage, ob man das mit einem Firmwareupdate auf dem ESP32 
korrigieren kann und ob es auch tatsächlich das Problem von KE5FX ist.

: Bearbeitet durch Moderator
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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".

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Dort steht auch:
1
#ifndef SERIAL_CONTROL_MODE
2
#define SERIAL_CONTROL_MODE hfUseRTS | hfRequireCTS
3
#endif

Das könnte auf das oben genannte Problem mit CTS deuten. Vielleicht 
müsst man das Ganze nur mal recompilieren mit
1
#define SERIAL_CONTROL_MODE hfUseRTS

(Einige andere Tools definieren SERIAL_CONTROL_MODE zu 0 vor dem 
#include, prologix.cpp macht es nicht.)

: Bearbeitet durch Moderator
von Dieter S. (ds1)


Lesenswert?

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...

von 900ss (900ss)


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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.

: Bearbeitet durch User
von 900ss (900ss)


Lesenswert?

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.

:)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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 ;)

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

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:

1
interface_settings  com215:baud=115200 parity=N data=8 stop=1
2
3
is_Prologix          1

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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:

1
++ver
2
++eos 0
3
++mode 0
4
++addr 5

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Richtig testen kann ich aber erst heute Abend wieder. Aus der Ferne ist 
nicht alles machbar.

von Dieter S. (ds1)


Lesenswert?

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.

: Bearbeitet durch User
von Hugo H. (hugo_hu)


Lesenswert?


von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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).

von Harald K. (kirnbichler)


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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."

von Harald K. (kirnbichler)


Lesenswert?

Na gut, dann freu Dich halt. Hast mich bei einem Irrtum ertappt, kannst 
Dir jetzt also großartig überlegen vorkommen.

von Hans-Georg L. (h-g-l)


Lesenswert?

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 ?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Sie sind nicht mit dem Internet verbunden.

Ah ja. Es gibt einen Button "Fortfahren". Das verstehe, wer will.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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)
4
      |                      ^~~~~~~
5
      |                      |
6
      |                      const void*

Waren unter den vielen Warnungen untergegangen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wenn ich mit -fpermissive compiliere, bekomme ich beim Linken alle 
möglichen undefined symbols für __imp*.
1
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\users\j\Temp\cczZW837.o:prologix.cpp:(.text+0x389): undefined reference to `__imp_ntohs'
2
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\users\j\Temp\cczZW837.o:prologix.cpp:(.text+0x394): undefined reference to `__imp_inet_ntoa'
3
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\users\j\Temp\cczZW837.o:prologix.cpp:(.text+0x3c6): undefined reference to `__imp_inet_ntoa'
4
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\users\j\Temp\cczZW837.o:prologix.cpp:(.text+0x424): undefined reference to `__imp_WSAStartup'
5

Fehlt mir da noch die Angabe irgendeiner Bibliothek?

von Hugo H. (hugo_hu)


Angehängte Dateien:

Lesenswert?

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 ...

von Dieter S. (ds1)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

Jörg W. schrieb:
> Fehlt mir da noch die Angabe irgendeiner Bibliothek?

Das dürfte die Importlibrary für die Winsock-Funktionen sein.

Siehe WSAStartup:

https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsastartup

.. nach unten scrollen, da steht dann Ws2_32.lib

Die sollte auch ntohs und ntoa enthalten.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Hugo H. (hugo_hu)


Angehängte Dateien:

Lesenswert?

Probier mal

von Dieter S. (ds1)


Lesenswert?

Jörg W. schrieb:
>
>
1
> specan.cpp:251:10: fatal error: ni488.h: No such file or directory
2
>
>
> Die kommt vermutlich von irgendwelchem National Instruments Paketen,
> oder?

ni488.h liegt doch im gpiblib Verzeichnis des KE5FX GPIB Toolkit.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Dieter S. (ds1)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Mir war so, als müsste man im Advantest die Adresse des Plotters 
angeben. Schau ich heute Abend mal.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Die libs an sich sind da, ich muss nur mal gucken, die Link-Optionen im 
Makefile anzupassen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

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).

: Bearbeitet durch Moderator
Bitte 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
Noch kein Account? Hier anmelden.