www.mikrocontroller.net

Forum: Compiler & IDEs GCC 64bit->32bit Umstellung


Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Rolf Magnus (Gast)
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist eine man-Page? Bzw. wo kann ich diese finden?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Shell eingeben:

man gcc

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok Danke ,ich werde das man durch sehen

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Rolf Magnus (Gast)
Datum:

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

Autor: Εrnst B✶ (ernst)
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Rolf Magnus (Gast)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Torsten Kraus (Gast)
Datum:

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

Autor: Rolf Magnus (Gast)
Datum:

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

Autor: Torsten Kraus (Gast)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Torsten Kraus (Gast)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Kristallkugel ist gerade zur Reparatur: ohne Fehlermeldungen
leider keine Hilfe.

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Rolf Magnus (Gast)
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du mir sagen wie und was ich einstellen muss ich habe da 
überhaupt keine Ahnung.

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK Libary ist drin! Momentan kommen auch keine Fehler.

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, du hast keinen Sourcecode für die libftdi und willst es
nun mit der libusb machen?  Was denn nun?

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

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

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.