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.
:
Bearbeitet durch User
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.
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
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:
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
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.)
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
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
AR488_original_Version.PNG
16 KB -
AR488_Version_4_0.PNG
14 KB
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 ;)
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
7470.PNG
6,3 KB
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
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:
1 | ++ver |
2 | ++eos 0 |
3 | ++mode 0 |
4 | ++addr 5 |
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.
Richtig testen kann ich aber erst heute Abend wieder. Aus der Ferne ist nicht alles machbar.
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
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.
:
Bearbeitet durch User
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."
Na gut, dann freu Dich halt. Hast mich bei einem Irrtum ertappt, kannst Dir jetzt also großartig überlegen vorkommen.
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.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Sie sind nicht mit dem Internet verbunden. Ah ja. Es gibt einen Button "Fortfahren". Das verstehe, wer will.
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.
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?
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.
:
Bearbeitet durch User
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.
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.
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?
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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Mir war so, als müsste man im Advantest die Adresse des Plotters angeben. Schau ich heute Abend mal.
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.
Die libs an sich sind da, ich muss nur mal gucken, die Link-Optionen im Makefile anzupassen.
Angehängte Dateien:
-
plot.gif
45 KB
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
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.