Ich bin gerade auf der Suche nach einer plattformunabhängigen Lösung zum Zugriff auf FTDI-Geräte von PC-Software unter Linux und Windows. Eine Möglichkeit ist ja der Zugriff über virtuelle COM-Ports, aber ich suche nach einer Lösung für den direkten Zugriff (D2XX). Bekannt ist mir die D2XX-Lösung unter Windows, die auf der FTDI-Webseite angebotene Linux-Lösung aus dem Jahr 2008 riecht mit ihrer WinTypes.h (da gibt es schon kollidierende Definitionen für DWORD und UDWORD in der sqltypes.h meines wxWidgets-Projekts) und der vorkompilierten Library riecht schon sehr stark nach massiven Problemen bei der Nutzung auf verschiedenen Linux-Maschinen. Der Zugriff über die libftdi (http://www.intra2net.com/en/developer/libftdi/) scheint keine unter Windows nutzbare Lösung zu sein. Abgesehen stellt sich bei der Lib so nebenbei die Frage, wie ich mir alle FTDI-Geräte am PC auflisten kann (vergleichbar zu FT_CreateDeviceInfoList und FT_GetDeviceInfoList der D2XX-Lib), denn die Funktion "ftdi_usb_find_all" erwartet Vendor- und Produkt-ID, nach der sie suchen soll (weiß ich aber nicht, kann ganz verschieden sein). Nun ja, zurück zur eigentlichen Frage: Gibt es noch andere Möglichkeiten, ohne für die jeweilige Plattform den Zugriff auf die FTDI-Geräte neu implementieren zu müssen?
Hallo, grundsätzlich sind Linux und Windows gerade inm Treiberbereich viel zu verschieden. Du könntest dir höchstens für eigene Zwecke eine ganz eigene abstrakte Klasse schreiben, aber schon beim open musst du wohl Windows und Linux Code völlig getrennt schreiben. Und dir eine eigene Namensstategie ausdenken, denn wenn deine Schnittstellen einheitlich COM2 usw. heissen, wirst du im Linux-Lager gelyncht. Deshalb auch nur für eigene Zwecke - sowas für die Allgemeinheit zu schreiben grenzt an Selbstmord, daher denke ich auch, wirst du nichts Fertiges finden. Gruss Reinhard
Eine möglichkeit wäre per JNI eine Java abstraktionsschicht zu definieren und für das jeweilige Zielsystem eine passende DLL/SO zu stricken. Hatte ich auch mal angedacht nur magels FTDI bisher noch nicht umgesetzt. Jetzt hab ich zwar prinzipiell ein Versuchskaninchen rumliegen aber momentan nicht so sher viel Zeit.. ;)
Man könnte auch die LibUSB bemühen, ist allerdings dann etwas aufwendiger. Aber die LibUSB Funktionen sind unter Linux und Windows nahezu gleich. Allerdings müsste man dazu in Erfahrung bringen, in welche Endpoints was zu schreiben ist, damit man die gleichen Funktionen erhält, wie bei der FTDI Lib.
Hmm, scheint also so, als hätte ich da nichts übersehen und eine halbwegs gleiche Programmierung ist da nicht möglich. Schade, zumindest FTDI hätte es ja möglich machen können, über Abstraktionsschichten dieselbe Treiberschnittstelle zu bieten. :o( Na mal sehen, was ich da so treibe. Wahrscheinlich werde ich dann wohl die Programmteil, der direkt auf die Treiber zugreift, kapseln. Allerdings einfach in C++. Zur libusb: Inwiefern könnte die mir weiterhelfen? Das hieße ja, den FTDI-Treiber nachzuprogrammieren. Allerdings fehlen da doch sicher die entsprechenden Informationen von FTDI oder kennt da jemand eine entsprechende Application Note?
Zumindest der Treiber für MacOS D2XX basiert auf libusb. Der liegt ja auch im Quelltext vor. Ich nehme an, unter Linux wird das ganz ähnlich sein. Ich bin hier grad dabei, einen Treiber neu zu schreiben, der bisher nackt mit libusb auf den FTDI-Chip zugegriffen hat, aber jetzt Ärger macht, weil die "alte" libusb 0.17 nicht auf Mac mit 64 bit baut. Mein Plan ist, über D2XX etwas zu bekommen, was sowohl für Mac gepflegt wird, als auch unter windows geht (da wird mir libusb recht sicher auch ärger machen). Zu der Sache mit DWORD usw: Ich werd den Kram so kapseln, dass diese Header jeweils nur in einem einzigen CPP-file eingebunden werden. Sind ja Windows-Typen und damit will ich im Hauptprogramm nix zu tun haben.
Ich habe nochmal in das Verzeichnis des libftd2xx-Treibers für Windows hineingeschaut. Quellen gibt es da leider keine, aber der basiert auch auf der libusb. Befindet sich der Quelltext in der *.dmg-Datei, die auf der FTDI-Webseite angeboten wird? Mit der kann ich leider nichts anfangen... Axel Jäger schrieb: > Zu der Sache mit DWORD usw: Ich werd den Kram so kapseln, dass diese > Header jeweils nur in einem einzigen CPP-file eingebunden werden. Sind > ja Windows-Typen und damit will ich im Hauptprogramm nix zu tun haben. Klingt vernünftig.
In dem DMG sind die Sourcen für den Mac-Treiber, weil man den neu kompilieren muss, wenn man eigene Vendor/Device-IDs haben will. Unter Windows müsstest du dazu ja das inf-file anpassen. Wenn aber der Windows-Treiber auch auf libusb basiert, heißt das ja, dass ich, wenn ich VID/PID verändere, den neu signieren muss, zumindest für 64 bit. Das sind ja keine schönen Neuigkeiten für mich... Schau mal nach, wie die sich vorstellen, dass man eine angepasste Version für andere VID/PID unter Windows machen soll. Da müsste es dann entweder die Source geben oder einen anderen nicht minder spannenden Ansatz.
Gastino G. schrieb: > Ich habe nochmal in das Verzeichnis des libftd2xx-Treibers für Windows > hineingeschaut. Quellen gibt es da leider keine, aber der basiert auch > auf der libusb. Befindet sich der Quelltext in der *.dmg-Datei, die auf > der FTDI-Webseite angeboten wird? Mit der kann ich leider nichts > anfangen... > Für die FTD2XX gibts für keine Plattform Quellcode von FTDI, ist und bleibt Black Box. Wenn man aber auf die wenigen Windows typischen Funktionen für Dateizugriff der Win FT2XX.DLL verzichtet sind die Funktionsaufrufe plattformunabhänig. Zumindest ist es möglich für FTD2XX eine Winelib zu erstellen der Windows Programme unter Wine vollen Zugriff auf die FTDI Chips erlaubt siehe http://coolla.freeunix.net/winelib.html D2XX geht in Linux über libusb Kernelzugriff und in Windows über FTDI sys Treiber. MAC???. Libusb und libusb-win32 sind keine gute Wahl. Die Windows Version hat Erweiterungen wie asynchron IO und basiert auf uralt libusb. Benutzt man die FTDI D2XX Treiber hat man noch den vorteil dass Win64 Treiber vorhanden sind.
Wolfgang R. schrieb: > Zumindest ist es möglich für FTD2XX eine Winelib zu erstellen der > Windows Programme unter Wine vollen Zugriff auf die FTDI Chips erlaubt > siehe > http://coolla.freeunix.net/winelib.html Ich will ja selber für Windows und Linux (nativ) meine Software mit Hilfe von wxWidgets entwickeln (bzw. tue das ja bereits). Hauptplattform ist dabei Linux, ein Windows-Programm dann unter Wine laufen zu lassen, fällt daher aus. Lieber lasse ich dann die Windows-Version weg, wenn der Portierungsaufwand zu groß wird. > D2XX geht in Linux über libusb Kernelzugriff und in Windows über FTDI > sys Treiber. MAC???. D2XX unter Linux macht leider aufgrund des Alters und der Wintypes-Schweinereien, die mir prompt um die Ohren geflogen sind, keinen guten Eindruck. Mal sehen, ob ich das sauber kapseln kann, damit es keine Kollisionen mit bereits definierten Datentypen gibt.
> D2XX unter Linux macht leider aufgrund des Alters und der > Wintypes-Schweinereien, die mir prompt um die Ohren geflogen sind, > keinen guten Eindruck. Mal sehen, ob ich das sauber kapseln kann, damit > es keine Kollisionen mit bereits definierten Datentypen gibt. Ich habe zum übersetzen und binden der winelib unter Linux den ganzen WIN Schwachsinn in ftd2xx.h auskommentiert. Übersetzt ohne Probleme.
Wolfgang R. schrieb: > Ich habe zum übersetzen und binden der winelib unter Linux den ganzen > WIN Schwachsinn in ftd2xx.h auskommentiert. Übersetzt ohne Probleme. Bist Du sicher, dass es da nicht irgendwo still und leise knirscht, weil FTDI vielleicht von bestimmten Datentypen ausgeht?
Die Datentypen der Funktionsaufrufe sind alle in Linux schon definiert. Da gibts hier ja nur drei Typen DWORD LPVOID LPDWORD; #include <stdarg.h> und gut ist es. Und die Typen dienen ja nur zu Kontrolle des Programmierers, damit keine falschen Typen übergeben werden.
Wolfgang R. schrieb: > Die Datentypen der Funktionsaufrufe sind alle in Linux schon definiert. > Da gibts hier ja nur drei Typen DWORD LPVOID LPDWORD; #include > <stdarg.h> und gut ist es. > Und die Typen dienen ja nur zu Kontrolle des Programmierers, damit keine > falschen Typen übergeben werden. Ganz so einfach ist es ja nicht. Die Datentypen sind in der WinTypes.h teilweise unterschiedlich zu den Linux-Typen definiert. Sonst gäbe es ja gar kein Problem. Das kommt damit einer Änderung der Datentypen an den Schnittstellen gleich und wir wissen ja nicht wirklich, ob das innerhalb der FTDI-Lib dazu führen kann, dass Informationen verloren gehen oder verfälscht werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.