Hallo Comunity,
Meine Aufgabe ist es ein Gerät mit integrierten FTDI-Chip an ein
Linux(CentOS) System(64bit) zu integrieren.
Für den Datenaustaucsch zwischen PC(USB) und FDTI will ich den dazu
gehörigen Treiber von FTDI benutzen.
Leider unterstüctzt dieser Treiber nur 32bit Prozessoren und mein
Compiler liefert Fehler(siehe Fehlerbeschreibung unten).
Ich benutze Eclipse als IDE und den GCC Compiler.
Meine Frage:
Wie kann ich meinem GCC-Compiler klar machen das er jetzt 32bit nutzen
soll und nicht mehr 64bit und wo kann ich es einstellen. Bzw. gibt es
moch ander Ideen.
PS:Compiler,FTDI-Treiber und Eclipse sind vollständig installiert.
Weiterhin habe ich den Beispiel Quellcode des FTDI-Treibers
verwendet,
der aber den selben Fehler ausgibt.
Hier sind erstmal paar Systemdaten:
% uname -a
Linux linpcm133.ipms.fraunhofer.de 2.6.9-42.0.10.EL #1 Tue Feb 27
09:18:57 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
% cat /etc/redhat-release
CentOS release 4.4 (Final)
% rpm -qa|grep gcc
libgcc-3.4.6-3.1
gcc-c++-3.4.6-3.1
compat-gcc-32-c++-3.2.3-47.3
gcc-3.4.6-3.1
gcc4-gfortran-4.1.0-18.EL4.3
compat-libgcc-296-2.96-132.7.2
compat-gcc-32-3.2.3-47.3
gcc4-c++-4.1.0-18.EL4.3
gcc-java-3.4.6-3.1
gcc4-4.1.0-18.EL4.3
gcc-objc-3.4.6-3.1
gcc-g77-3.4.6-3.1
libgcc-3.4.6-3.1
gcc-gnat-3.4.6-3.1
Hier ist die Fehlerangabe bzw. Daten des Makefiles:
% make
starte gcc...
gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
gcc -o libusbadc.so.0.1.0 src/adc.c -lftd2xx -lusb -B /usr/lib
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../libftd2xx.so when
searching for -lftd2xx
/usr/bin/ld: skipping incompatible /usr/local/lib/libftd2xx.so when
searching for -lftd2xx
/usr/bin/ld: skipping incompatible /usr/lib/libftd2xx.so when searching
for -lftd2xx
/usr/bin/ld: cannot find -lftd2xx
collect2: ld returned 1 exit status
make: *** [compile] Error 1
linpcm133.ipms.fraunhofer.de{kraus}50:
Ich hoffe das ich genügend Daten angegeben habe.
> Wie kann ich meinem GCC-Compiler klar machen das er jetzt 32bit nutzen > soll und nicht mehr 64bit und wo kann ich es einstellen. Das läßt sich dem Kapitel "i386 and x86-64 options" der man-Page entnehmen.
Gut ich habe es gefunden und es wurde das Bestädigt was mir gesagt wurden ist(müsste also passen). Der Eintrag "m32" dürfte veranlassen,das jetzt mit 32bit gearbeitet werden. Leider weis ich nicht wo ich den Eintrag machen muss.
Ohne das Manual jetzt gelesen zu haben würde ich vermuten, dass du dem GCC auf der Kommandozeile ein »-m32« mit geben musst. Da du den GCC sicher über make aufrufst, musst du das irgendwie (typischerweise in den CFLAGS) im Makefile unterbringen.
Den GCC führe ich überhaupt nicht manuel aus. Er ist in meinem Projektkt fertig eingebunden. Ich verwende ein fertiges Eclips mit GCC-Compiler, das im Normalfall(64bit) ordentlich funktioniert. Leider eben nicht beim D2xx-Treiber(32bit) von FTDI.
> Ich verwende ein fertiges Eclips mit GCC-Compiler
Dann wirst du dich wohl oder übel damit auseinandersetzen müssen,
wie dein Eclipes das Makefile zusammennagelt, und wie du ihm
beibringen kannst, dort deine eigene Option mit aufzunehmen.
Wenn deine Bibliothek als Sourcecode erhältlich ist, wäre das
natürlich einfacher, dann compilierst du sie stattdessen selbst
neu.
> Er ist in meinem Projektkt fertig eingebunden. Ich verwende ein > fertiges Eclips mit GCC-Compiler, das im Normalfall(64bit) ordentlich > funktioniert. Dann mußt du es eben irgendwo in der Projektkonfiguration in Eclipse einstellen. Wie das geht, weiß ich nicht, weil ich Eclipse nicht benutze.
Oder du lässt dein Projekt 64Bittig, und installierst einfach auch 64Bit-Libraries für deinen FTDI, z.B.: http://www.intra2net.com/de/produkte/opensource/ftdi/
Vielen Dank für die Hinweise! An die Opensource habe ich auch schon gedacht, aber das wäre der zweite Versuch! Ich hatte auch ein Probleme diese zu installieren. Eigentlich muss ich das auf einen 32bit ARM-Board laufen lassen wo Linuk darauf ist. Dazu habe ich noch einen zweiten Compiler für ein ARM-Board(32bit) auf dem Linux läuft. Dort tritt der folgende Fehler beim USB auf: Fehler ld: cannot find -lftd2xx ld: skipping incompatible /usr/local/lib/libftd2xx.so when searching for -lftd2xx ld: warning: library search path "/usr/local/lib" is unsafe for cross-compilation Ich denke mal das es auch wieder an 64bit Libarys hängt
> Ich denke mal das es auch wieder an 64bit Libarys hängt
Nein. Bibliotheken enthalten Binärcode, die kannst du nicht einfach
zwischen x-beliebigen Prozessoren hin- und herschieben. Steht doch
da:
1 | ld: skipping incompatible /usr/local/lib/libftd2xx.so when searching for -lftd2xx |
Du wirst also einfach mal nicht umhin kommen, dir die Bibliothek selbst zu compilieren.
Du wirst Recht haben. Bei einem dritten Bsp. das unter Suse(32bit) läuft. Kommt mit paar Veränderungen am makefile. Das hat jemand gemacht der das Programm geschrieben hat. Diese Fehler: % make starte gcc... gcc --version gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc -o libusbadc.so.0.1.0 src/adc.c -m32 -lftd2xx -lusb -B /usr/lib /usr/bin/ld: skipping incompatible /usr/lib64/libusb.so when searching for -lusb /usr/bin/ld: skipping incompatible /usr/lib64/libusb.a when searching for -lusb /usr/bin/ld: cannot find -lusb collect2: ld returned 1 exit status make: *** [compile] Error 1 Wenn ich deine Aussage richtig verstanden habe, tritt hier das selbe Problem auf. Es wird die libusb(32bit) Variante benutzt und ich habe aber nur die 64bit Variante. Richtig?
> Du wirst Recht haben. Hat er. Wie auch schon der Linker sagt: > ld: warning: library search path "/usr/local/lib" is unsafe for > cross-compilation Die lokalen libs auf dem PC kannst du nicht für einen ARM einsetzen. Der braucht seine eigene Version davon. > gcc -o libusbadc.so.0.1.0 src/adc.c -m32 -lftd2xx -lusb -B /usr/lib Was soll das -B /usr/lib da? > Es wird die libusb(32bit) Variante benutzt und ich habe aber nur die > 64bit Variante. > Richtig? So sieht es wohl aus. Ich würde auf den ganzen 64-bit-Kram komplett verzicheten. In den meisten Fälen hat man damit nur jede Menge Scherereien, braucht mehr Speicher und hat keinerlei Vorteil.
Er wird auch komplett andere Tools brauchen... Stichwort: cross compiler. Also letztlich das, was jeder Benutzer eines AVR-GCC zwangsläufig macht, da der GCC nicht selbst auf einem AVR-Host läuft. Dinge wie libusb sind außerdem noch an das Betriebssystem gebunden, d. h. auf der Zielplattform muss dann auch das zur Bibliothek passende System laufen (Linux, NetBSD, was auch immer auf einem ARM läuft).
Auf meinem Target läuft Linux(mit Kernle 2.6)! > > gcc -o libusbadc.so.0.1.0 src/adc.c -m32 -lftd2xx -lusb -B /usr/lib > Was soll das -B /usr/lib da? Davon habe ich auch keine Ahnung,ich hatte das nur zum testen genommen. Ich habe erst seit Anfang des Monats mit Linux-Programmierung angefangen. Den Cross-Compiler könnte ich natürlich nochmal versuchen. Ich werde auch das mit den Opensource FTDI-Treiber ausprobieren,
Torsten Kraus wrote:
> Auf meinem Target läuft Linux(mit Kernle 2.6)!
Wenn das Target es zulässt: compiliere gleich alles dort.
Wenn nicht: dein cross compilation environment brauch alle notwendigen
Bibliotheken für das Target.
Ich habe schon versucht den FTDI-Treibr mit den Target-Compiler zu benutzen, aber da ist das selbe Problem. Weil es ein 32bit Compiler ist und es USB Libary Fehler gibt die ja für 64bit gedacht sind. Aber dazu in einer Woche. Ich fahre erstmal 1 Woche in den Urlaub aber vielen Dank für euere Hilfe. Ich werde euch auf den laufenden halten und vielen Dank für die Idenn und Hilfen.
> Ich habe schon versucht den FTDI-Treibr mit den Target-Compiler zu > benutzen, aber da ist das selbe Problem. Was meinst du damit? Du hast eine Version des Treibers für das Target-System? Oder hast du versucht, ihn mit dem Target-Compiler selbst zu übersetzen?
Mein Taget ist ein DIMM-RM9200 mit Linux(hat 32bit ARM Controler) http://www.garz-fricke.com/render.php?sess_pid=267 Um auf diesen Board ein Programe zum laufen zubringen, benutze ich eine GNU-Toolchain(http://www.codesourcery.com/gnu_toolchains/arm/download.html) Ich schreibe also ein Quelltext compiliere diesen mit der Toolchain und dann kopiere ich die Datein auf das Board(Kopiervorgang mit Mount-Befehlen).Dann öffne ich ganz normal per Terminal das Programm. Jetzt hatte ich gedacht das ich die Toolchain die ein 32bit Programm compiliert den 32bit FDTI-Treiber benutzen kann. @ Rolf Magnus Nun zur Beantwortung der Frage: Ich habe versucht, den FTDI-Treiber mit dem Target-Compiler zu übersetzen? Hier nun die Fehlermeldungen der einzelnen Compiler: --------------GCC-Compiler in 32bit Modus---------------------- Fehler: ./main.o(.text+0x93): In function `main': ../main.c:74: undefined reference to `FT_ListDevices' ./main.o(.text+0x1af):../main.c:91: undefined reference to `FT_OpenEx' ./main.o(.text+0x1f2):../main.c:105: undefined reference to `FT_SetBaudRate' ./main.o(.text+0x277):../main.c:114: undefined reference to `FT_Write' ./main.o(.text+0x2d2):../main.c:123: undefined reference to `FT_GetQueueStatus' ./main.o(.text+0x394):../main.c:131: undefined reference to `FT_Read' ./main.o(.text+0x433):../main.c:149: undefined reference to `FT_Close' Warnings(): ../main.c:15:20: warning: ftd2xx.h: No such file or directory ../main.c: In function `main': ../main.c:78: warning: int format, FT_STATUS arg (arg 2) ../main.c:118: warning: implicit declaration of function `sleep' ../main.c:126: warning: implicit declaration of function `realloc' ../main.c:127: warning: implicit declaration of function `memset' ../main.c:154: warning: implicit declaration of function `free' -------------------------GCC-Compiler in 64bit Modus----------------- Fehler: ./main.o(.text+0x84): In function `main': ../main.c:74: undefined reference to `FT_ListDevices' ./main.o(.text+0x1a6):../main.c:91: undefined reference to `FT_OpenEx' ./main.o(.text+0x1e9):../main.c:105: undefined reference to `FT_SetBaudRate' ./main.o(.text+0x264):../main.c:114: undefined reference to `FT_Write' ./main.o(.text+0x2c4):../main.c:123: undefined reference to `FT_GetQueueStatus' ./main.o(.text+0x37e):../main.c:131: undefined reference to `FT_Read' ./main.o(.text+0x424):../main.c:149: undefined reference to `FT_Close' -------------------------GNU-Toolchain-Compiler(32bit)----------------- Fehler: library search path "/usr/local/lib" is unsafe for cross-compilation skipping incompatible /usr/local/lib/libftd2xx.so when searching for -lftd2xx cannot find -lftd2xx Fazit: -zu GCC-Compiler in 64bit Modus: Die UP des FTDI-Treibers sind nicht ausreichend definiert,da der Treiber die USB-Libarys verwendet.Da mein System aber 64bit Libarys hat, wird wohl die unterschiedlichen USB-Libarys zwischen 64bit und 32bit dafür verantwortlich sein. -zu GCC-Compiler in 32bit Modus: Hier treten wohl die selben Problem wie beim GCC-Compiler in 64Bit Modus auf.Was darauf schließen lässt das auch im 32bit Modus des Compilers die 64bit Libarys verwendet werden -zu GNU-Toolchain(32bit): In diesem Fall wird versucht die 64bit Libarys zubenutzen. Da aber wie gesagt der FTDI nur 32bit Libarys hat kann deswegen keine Compilierung erfolgen. Liege ich mit meinen Erklärungen(Fazit) richtig? Wie sieht ein möglicher Lösungweg aus? - Eigenen 64bit FTDI-Treiber schreiben? - den Opensource FTDI-Treiber benutzen und diesen in 64bit Version umwandeln(USB Libarys anpassen)? - FTDI-Treiber verwenden und die USB auf meinem System verändern? - weitere Ideen????
Du hast es immer noch nicht begriffen: dein Problem sind nicht 32-bit vs. 64-bit-Bibliotheken, dein Problem besteht darin, dass du nicht eine Bibliothek für einen IA32 oder AMD64 einfach nehmen kannst und sie auf einem ARM benutzen. Du musst also den Sourcecode der FTDI-Bibliotheken für dein Zielsystem compilieren. Das impliziert, dass die Objektmodule dann 64-bittig sein werden.
Nochmal vielen Dank für diese Erläuterung. Wenn ich dich also richtig verstanden habe, muss ich mir einen eigenen FTDI-Treiber(Sourcecode) basteln!? Mein Zielsystem ist ein AMD64 oder/und ARM, das würde ja dann zu 2 verschiedenen Treibern führen. Habe ich jetzt alles richtig verstanden???
Torsten Kraus wrote: > Wenn ich dich also richtig verstanden habe, muss ich mir einen eigenen > FTDI-Treiber(Sourcecode) basteln!? Oder zusehen, dass du von FTDI den Sourcecode erhälst für deren Treiber. > Mein Zielsystem ist ein AMD64 oder/und ARM, das würde ja dann zu 2 > verschiedenen Treibern führen. Objektcode: ja. Sourcecode könnte (und sollte normalerweise) natürlich für beide gleich sein.
p.s.: Kannst du denn nicht einfach die libusb benutzen und den Rest in der Applikation erledigen? Ich weiß ja nicht, was deine Applikation genau macht.
Die Applikation soll Daten zu den FTDI-Chip senden und empfangen. Das mit der libusb probiere ich nochmal aus(da gab es ein anders Problem)
Ich habe die libusb 0.1.08 ausprobiert(musste nichts installiern), diese ist standartmäßig installiert. Verwendet habe ich ein Beispielprogramm aus der libusb-0.1.12, was nicht einmal im Ansatz funktioniert(Ich habe den Quellcode in mein Arbeitsverzeichnis kopiert und versucht zu compelieren) Wenn ich hierbei Fehler gemacht habe, wäre ein Aufklärung sehr net. Die neuste Libusb kann ich erst Morgen ausprobieren wenn meine IT soweit Zeit hat. Aber vielen Dank für die große Hilfe.
Meine Kristallkugel ist gerade zur Reparatur: ohne Fehlermeldungen leider keine Hilfe.
Das habe ich natürlich vergessen, aber jetzt kommt alls. Verwendet habe ich nur die "testlibusb.c" und den GCC-Compiler. Weiterhin habe ich keine Header mit in mein Arbeitsverzeichnis hinein kopiert. Hier die Fehlerbeschreibung: In function `main': In function `print_device': undefined reference to `usb_busses' undefined reference to `usb_close' undefined reference to `usb_find_busses' undefined reference to `usb_find_devices' undefined reference to `usb_get_string_simple' undefined reference to `usb_get_string_simple' undefined reference to `usb_get_string_simple' undefined reference to `usb_init' undefined reference to `usb_open' Wenn ich mir die USB.h von meinem System anschaue, sehe ich das die API's nicht definirt sind. Hier mal ein Bsp aus dem Quellcode: usb_close(udev); //undefined reference to `usb_close'
Das sieht mir aus wie eine Meldung vom Linker, nur daß irgendwie ein Teil fehlt. So wie es aussieht, hast du vergessen, das Programm gegen die libusb zu linken.
Kannst du mir sagen wie und was ich einstellen muss ich habe da überhaupt keine Ahnung.
Muss ich die libfdti installiern? Und wie gliedere ich sie in mein System ein? Ich habe ein Bsp(simpel.c) aus der libfdti in mein Arbeitsverzeichnis kopiert und es geht nur wenn ich den Headrer(<ftdi.h>) in "src/ftdi.h" um schreibe. Es scheint das alles funktioniert, aber ich werde das jetzt mal weiter untersuchen.
Ich denke, du hast keinen Sourcecode für die libftdi und willst es nun mit der libusb machen? Was denn nun?
Den Sourcecode gibt es für den "orginalen" FTFI-Treiber nicht. Die Libfdti wollte ich bzw. habe ich ausprobiert und das Testprogramm erkennt meine FTDI-Gerät. Ein weiteres Testprogramm gibt mir sogar die richtigen Werte von meinem Gerät aus, damit kann ich sagen das es funktioniert Die libusb ist bei mir standartmäßig installiert! Und bei Veränderung der zu wählenden Header(muss den Header aus der libftdi nehmen, den ich in mein Arbeitsverzeichnis kopiert habe) funktioniert es. FAZIT: Da jetzt die FTDI-PC Komunikation funktioniert und ich den Rest allein schaffe bzw, mir keiner helfen kann wollte ich mich für die vielen und guten Hilfen/Ratschläge bedanken!
Zusammenfassung: - Meine Systemdaten kann man im ersten Post nachlesen - Das Problem war das der FTDI-Treiber von FTDI für Linux auf meinem System nicht funktioniert, da er in aller Wahrscheinlichkeit nicht für die 64bit Architektur geschrieben wurden ist. - Dadruch bringt ein Umstellung des Compilers auf 32bit nichts (Dafür muss man -m32 bei Properties->Build->Miscellaneous ergänzen(am Ende)) - Die Lösung: Man benutzt die libftdi(Opensource) und die dazu gehörige libusb(bei mir im System schon vorhanden), dazu muss aber die Libary eingebunden werden(Properties->Build->Linker->Libarys->(unter Linux)usb editieren) - Nun müsste man den Bsp-Quellcode der libftdi nehmen und es sollte funktionieren
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.