www.mikrocontroller.net

Forum: PC-Programmierung FTDI und plattformunabhängige Programmierung


Autor: Gastino G. (gastino)
Datum:

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

Autor: Reinhard Kern (Gast)
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

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

Autor: Christian R. (supachris)
Datum:

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

Autor: Gastino G. (gastino)
Datum:

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

Autor: Axel Jäger (axeljaeger)
Datum:

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

Autor: Gastino G. (gastino)
Datum:

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

Autor: Axel Jäger (axeljaeger)
Datum:

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

Autor: Wolfgang R. (portside)
Datum:

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

Autor: Gastino G. (gastino)
Datum:

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

Autor: Wolfgang R. (portside)
Datum:
Angehängte Dateien:

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

Autor: Gastino G. (gastino)
Datum:

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

Autor: Wolfgang R. (portside)
Datum:

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

Autor: Gastino G. (gastino)
Datum:

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.