Hallo
Ich möchte einen FTDI-Chip mit der libMPSSE-Bibliothek ansteuern.
http://www.ftdichip.com/Support/SoftwareExamples/MPSSE/LibMPSSE-SPI/LibMPSSE-SPI.zip
Nun bekomme ich allerdings eine Menge Fehlermeldungen, die ich nicht
verstehe:
> i:/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/ftd2xx.h:259:20: error:> expected '=', ',', ';', 'asm' or '__attribute__' before 'FT_Open'> FT_STATUS WINAPI FT_Open(> ^~~~~~~> i:/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/ftd2xx.h:265:20: error:> expected '=', ',', ';', 'asm' or '__attribute__' before 'FT_OpenEx'> FT_STATUS WINAPI FT_OpenEx(> ^~~~~~~~~
Die Fehlermeldung weist dann auf die eingebundene ftd2xx.h hin. Die
Links in der Fehlermeldung führen dann zu folgenden Zeilen:
> FTD2XX_API> FT_STATUS WINAPI FT_Open( <- rot markiert, Zeile 257> int deviceNumber,> FT_HANDLE *pHandle> );>> FTD2XX_API> FT_STATUS WINAPI FT_OpenEx( <- rot markiert, Zeile 265> PVOID pArg1,> DWORD Flags,> FT_HANDLE *pHandle> );
Was soll mir die Fehlermeldung jetzt sagen? Soweit ich weiß wolte der
Compiler ein '=' oder ',' sehen, allerdings glaub ich nicht daß FTDI so
eine Bibliothek mit solchen und so vielen Syntaxfehlern ausliefert.
Diese beiden Zeilen sind bloß exemplarisch, es betrifft aber praktisch
alle-was ist das eigentlich, ein Klassenaufruf in C++? Das kenne ich
jedenfalls nicht, nur 'normales' C.
Mein Programm sieht wie folgt aus, ich hab es praktisch 1:1 aus dem
sample-code geborgt.
accelerate that with 9,81m/s² schrieb:> Was soll mir die Fehlermeldung jetzt sagen?
Daß FT_STATUS nicht oder nicht richtig definiert ist.
> Diese beiden Zeilen sind bloß exemplarisch, es betrifft aber praktisch> alle-was ist das eigentlich, ein Klassenaufruf in C++?
Das sind ganz banale Funktionsprototypen; wie kommst Du auf
"Klassenaufruf"?
Wenn Du in ftd2xx.h nachsiehst, findest Du darin das typedef für
FT_STATUS. Könnte es sein, daß Dein Compiler nicht weiß, was ULONG ist?
und in Zeile 52:
[c]#ifdef FTD2XX_EXPORTS
#define FTD2XX_API __declspec(dllexport)
#else
#define FTD2XX_API __declspec(dllimport)
#endif[/]
Wobei die Zeile mit (dllexport) ausgegraut ist und die mit (dllimport)
farlich wie alle anderen.
Rufus Τ. F. schrieb:> Wenn Du in ftd2xx.h nachsiehst, findest Du darin das typedef für> FT_STATUS. Könnte es sein, daß Dein Compiler nicht weiß, was ULONG ist?
Dann würd aber der Fehler beim typedef stehen, nicht bei der
Funktionsdeklaration. typedef ist schließlich keine dumme Textersetzung
wie ein Makro...
ULONG wird in WinTypes.h deklariert. Diese ist im Sample von FTDI
enthalten, ich hab alle Dateien, die im Sample drin sind, inkludiert
bzw. den Pfad dahin in die Directory-Liste eingetragen.
Wenn ich die WinTypes.h mit inkludiere ändert sich nichts.
Hm...ich hab dem Pfad im Sample, wo FTDI alle .h und .lib usw.
zusammengekloppt hat, dem Linker hinzugefügt.
Ich sehe aber grad, daß eine ftd2xx.lib nicht dabei ist. Die
libMPSSE.lib und libMPSSE.dll ja, aber die andere eben nicht. Ich
probiere die fehlende Datei mal mit reinzukopieren.
So...eine Datei ftd2xx.lib ist im Download von FTDI überhaupt nicht
enthalten.
Ich werd mal schauen ob sowas in den Treiberdaten von FTDI drin ist.
Könnte das passen? Mit Treiberprogrammierung usw. kenne ich mich nun gar
nicht aus. Allerdings ist der D2XX-Treiber von FTDI bereits installiert.
accelerate that with 9,81m/s² schrieb:> Ach ja, hier ist noch die Ausgabe, wenn ich mit -E kompiliere:
Die Ausgabe in der produzierten main.o wäre dann interessant.
Die main.o hab ich hinten angehanten. (Bzw. ist es die vom letzten
Build, siehe unten.)
Ansonsten hab ich den Compiler nochmal drüberlaufen lassen, diesmal hab
ich alle Dateien aus dem Treiber (Unterordner amd64) in den Ordner
kopiert, wo die anderen .h und .lib usw. liegen
(...\LibMPSSE-SPI\samples\SPI\SPI\).
Die vielen Fehlermeldungen sind nun tatsächlich weg (Hurra, und vielen
Dank), zufrieden ist der aber immer noch nicht. Stattdessen sagt er
jetzt:
---------------------------------------------------------------------
cd 'I:\Documents\NetBeansProjects\GettingStartedMPSSE2'
C:\MinGW\msys\1.0\bin\make.exe -f Makefile CONF=Debug
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE=
SUBPROJECTS= .build-conf
make.exe[1]: Entering directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk
dist/Debug/MinGW-Windows/gettingstartedmpsse2.exe
make.exe[2]: Entering directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
mkdir -p dist/Debug/MinGW-Windows
gcc -o dist/Debug/MinGW-Windows/gettingstartedmpsse2
build/Debug/MinGW-Windows/main.o
-L/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI
build/Debug/MinGW-Windows/main.o: file not recognized: File format not
recognized
collect2: error: ld returned 1 exit status
make.exe[2]: *** [dist/Debug/MinGW-Windows/gettingstartedmpsse2.exe]
Error 1
make.exe[2]: Leaving directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
make.exe[1]: *** [.build-conf] Error 2
make.exe[1]: Leaving directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
make.exe": *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 25s)
---------------------------------------------------------------------
Was meint der mit 'File not recognized'? Eine neue main.o hat er doch
erstellt. (Siehe Anhang)
accelerate that with 9,81m/s² schrieb:> Die main.o hab ich hinten angehanten. (Bzw. ist es die vom letzten> Build, siehe unten.)
Du hättest natürlich die posten müssen, die direkt nach dem Aufruf mit
"-E" erzeugt wurde. Denn dann kommt da kein Object Code rein, sondern
nur die Ausgabe des Präprozessors. Die kann man dann natürlich nicht
linken, weshalb du die 'File not recognized' Meldung erhältst. Nehm die
"-E" Option wieder raus, lösche die main.o Datei, und lasse es neu
kompilieren & linken.
Dr. Sommer schrieb:> Du hättest natürlich die posten müssen, die direkt nach dem Aufruf mit> "-E" erzeugt wurde.
Achso, hast du ja sogar... Naja, da sich das ja erledigt hat: "-E" raus
und Datei löschen.
Oh nein...jetzt kommen wieder die gleichen Fehler, die er am Anfang in
der ftd2xx.h angemeckert hat:
---------------------------------------------------------------
cd 'I:\Documents\NetBeansProjects\GettingStartedMPSSE2'
C:\MinGW\msys\1.0\bin\make.exe -f Makefile CONF=Debug
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE=
SUBPROJECTS= .build-conf
make.exe[1]: Entering directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk
dist/Debug/MinGW-Windows/gettingstartedmpsse2.exe
make.exe[2]: Entering directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
mkdir -p build/Debug/MinGW-Windows
rm -f "build/Debug/MinGW-Windows/main.o.d"
gcc -m32 -c -g -Wall -I/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI
-include /I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/WinTypes.h
-include /I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/ftd2xx.h
-include /I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/libMPSSE_spi.h
-MMD -MP -MF "build/Debug/MinGW-Windows/main.o.d" -o
build/Debug/MinGW-Windows/main.o main.c
In file included from <command-line>:32:0:
i:/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/ftd2xx.h:259:20: error:
expected '=', ',', ';', 'asm' or '__attribute__' before 'FT_Open'
FT_STATUS WINAPI FT_Open(
^~~~~~~
i:/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/ftd2xx.h:265:20: error:
expected '=', ',', ';', 'asm' or '__attribute__' before 'FT_OpenEx'
FT_STATUS WINAPI FT_OpenEx(
^~~~~~~~~
...
---------------------------------------------------------------
Ich versteh das nicht, er hat doch jetzt alles was er braucht: Header,
Libraries, ...was könnte da noch fehlen?
accelerate that with 9,81m/s² schrieb:> Ich versteh das nicht, er hat doch jetzt alles was er braucht: Header,> Libraries, ...was könnte da noch fehlen?
Die Definition von WINAPI. Nach dem Präprozessor-Aufruf sieht die
Funktionsdeklaration so aus:
1
__attribute__((dllimport))
2
FT_STATUSWINAPIFT_Open(
3
intdeviceNumber,
4
FT_HANDLE*pHandle
5
);
Das WINAPI muss noch aufgelöst werden. Das ist eigentlich in der
windows.h definiert. Schieb das "#include <windows.h>" mal ganz nach
oben
Ich hab das #include<windows.h> mal ganz an den Anfang gestellt-aber das
hat nichts gebracht. Ich habs auch an anderen Stellen zwischendrin
versucht-ohne Erfolg.
1
/* Standard C libraries */
2
#include<windows.h>
3
#include<stdio.h>
4
#include<stdlib.h>
5
#include<string.h>
6
7
/* OS specific libraries */
8
#define _WIN32
9
#ifdef _WIN32
10
#include"WinTypes.h"
11
#endif
12
13
/* Include D2XX header*/
14
#include"ftd2xx.h"
15
16
/* Include libMPSSE header */
17
#include"libMPSSE_spi.h"
Wenn ich mir die main.o so ansehe und deren Bedeutung richiig verstehe
(ich hab der main.o-Datei noch nie größere Beachtung geschenkt), so
scheinen manche Dateien mehrfach eingebunden zu werden, z.B. time.h
(Zeile 11, 12, 32) oder config.h, die kommt gleich sechs mal vor.
Ist das für den Linker ein Problem, oder wird der damit fertig?
Mehrfaches Einbinden möchte man doch eigentlich nicht.
accelerate that with 9,81m/s² schrieb:> so> scheinen manche Dateien mehrfach eingebunden zu werden, z.B. time.h> (Zeile 11, 12, 32) oder config.h, die kommt gleich sechs mal vor.
Das macht überhaupt nichts, das passiert ständig. Die Include Guards
verhindern hier weitere Probleme. Vermutlich stimmt mit deiner windows.h
etwas nicht. Benutz unter Windows doch mal Visual Studio, das ist
mittlerweile gratis...
Da bin ich wieder...
Ich hab mal versucht das Ganze in VS aufzuziehen, wie mir von Dr. Sommer
geraten.
Das Ergebnis ist, das VS mit dem Befehl
1
#include<sys/time.h>
in der Datei WinTypes.h (Zeile 5) nichts anzufangen weiß: "Die Datei
Quelle kann nicht geöffnet werden: sys/time.h".
Ich werd dem Support von FTDI nochmal eine Mail schreiben und die
bitten, mir mal zu sagen was die da für Tools verwenden.
Und das in Zeiten, wo Maven bereits erfunden wurde... :(
Wozu wird die WinTypes.h denn gebraucht?
accelerate that with 9,81m/s² schrieb:> Und das in Zeiten, wo Maven bereits erfunden wurde... :(
Das ist Java-Teufelszeug, davon möchte der gute alte C-Programmierer
nichts wissen :-)
accelerate that with 9,81m/s² schrieb:> Das Ergebnis ist, das VS mit dem Befehl#include <sys/time.h>> in der Datei WinTypes.h (Zeile 5) nichts anzufangen weiß
Die Datei "wintypes.h" ist nur für das Übersetzen unter Linux nötig,
unter Windows wird die nicht eingebunden.
Sieh Dir doch mal die Verzeichnisstruktur im Zip-Archiv
"libmpsse-spi.zip" genauer an - Dich interessiert, was im Verzeichnis
"windows" liegt, nicht das, was im Verzeichnis "linux" liegt.
Potzblitz-stimmt, die WinTypes.h ist im Linux-Ordner. Wie kam die dann
zu den anderen Dateien? Ah, weil sie von Anfang an im Ordner mit dem
Sample-Projekt drin war. Irgendwo hatte ich die versehentlich
inkludiert-keine Ahnung wie das passiert ist. Der Fehler ist aber schon
in einem Post weiter oben.
Ich hab die Stelle jetzt wie folgt geändert:
1
/* OS specific libraries */
2
#define _WIN32
3
#ifdef _WIN32
4
//#include "WinTypes.h"
5
#include<windows.h>
6
#endif
Ansonsten (alle Kompiliervorgänge mit Re-Build):
MinGW unter Netbeans meldet:
------------------------------------------------------------
cd 'I:\Documents\NetBeansProjects\GettingStartedMPSSE2'
C:\MinGW\msys\1.0\bin\make.exe -f Makefile CONF=Debug
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE=
SUBPROJECTS= .build-conf
make.exe[1]: Entering directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk
dist/Debug/MinGW-Windows/gettingstartedmpsse2.exe
make.exe[2]: Entering directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
mkdir -p build/Debug/MinGW-Windows
rm -f "build/Debug/MinGW-Windows/main.o.d"
gcc -m32 -E -c -g -Wall
-I/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI -include
/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/ftd2xx.h -include
/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/libMPSSE_spi.h -MMD -MP
-MF "build/Debug/MinGW-Windows/main.o.d" -o
build/Debug/MinGW-Windows/main.o main.c
mkdir -p dist/Debug/MinGW-Windows
gcc -o dist/Debug/MinGW-Windows/gettingstartedmpsse2
build/Debug/MinGW-Windows/main.o
-L/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI -lftbusui -lftcserco
-lftd2xx -lftd2xx64 -lftlang -lftserui2 -lMPSSE -lMPSSE -lMPSSE
build/Debug/MinGW-Windows/main.o: file not recognized: File format not
recognized
collect2: error: ld returned 1 exit status
make.exe[2]: *** [dist/Debug/MinGW-Windows/gettingstartedmpsse2.exe]
Error 1
make.exe[2]: Leaving directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
make.exe[1]: *** [.build-conf] Error 2
make.exe[1]: Leaving directory
`/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
make.exe": *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 25s)
------------------------------------------------------------
Cygwin sagt:
------------------------------------------------------------
cd 'I:\Documents\NetBeansProjects\GettingStartedMPSSE2'
C:\cygwin\bin\make.exe -f Makefile CONF=Debug
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS=
.build-conf
make[1]: Entering directory
'/cygdrive/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
"/usr/bin/make" -f nbproject/Makefile-Debug.mk
dist/Debug/Cygwin-Windows/gettingstartedmpsse2.exe
make[2]: Entering directory
'/cygdrive/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
mkdir -p build/Debug/Cygwin-Windows
rm -f "build/Debug/Cygwin-Windows/main.o.d"
gcc -m32 -E -c -g -Wall
-I/cygdrive/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI -include
/cygdrive/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/ftd2xx.h
-include
/cygdrive/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI/libMPSSE_spi.h
-MMD -MP -MF "build/Debug/Cygwin-Windows/main.o.d" -o
build/Debug/Cygwin-Windows/main.o main.c
mkdir -p dist/Debug/Cygwin-Windows
gcc -o dist/Debug/Cygwin-Windows/gettingstartedmpsse2
build/Debug/Cygwin-Windows/main.o
-L/cygdrive/I/C-Bibliotheken/LibMPSSE-SPI/samples/SPI/SPI -lftbusui
-lftcserco -lftd2xx -lftd2xx64 -lftlang -lftserui2 -lMPSSE -lMPSSE
-lMPSSE
build/Debug/Cygwin-Windows/main.o: file not recognized: File format not
recognized
collect2: error: ld returned 1 exit status
make[2]: *** [nbproject/Makefile-Debug.mk:63:
dist/Debug/Cygwin-Windows/gettingstartedmpsse2.exe] Error 1
make[2]: Leaving directory
'/cygdrive/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
make[1]: *** [nbproject/Makefile-Debug.mk:59: .build-conf] Error 2
make[1]: Leaving directory
'/cygdrive/i/Documents/NetBeansProjects/GettingStartedMPSSE2'
make: *** [nbproject/Makefile-impl.mk:40: .build-impl] Error 2
BUILD FAILED (exit value 2, total time: 5s)
------------------------------------------------------------
Und Visual Studio beschwert sich über eine fehlende stdafx.h-Datei, die
es in einem neuen C++-Projekt automatisch einhängt. (Irgendwie kann das
VS2017 kein natives C-Projekt mehr erstellen, es markiert aber Dateien
mit einem passenden C-Icon, wenn man eine Datei gewaltsam mit .c
benennt).
Wenn ich die fehlende Datei dort einhänge, mißfällt ihm etwas anderes,
ich meine es war der Return-Wert. Ob einfach 0 oder EXIT_SUCCESS, beides
passt ihm nicht. Warum kann ich aktuell nicht sagen, da VS das Projekt
nun gar nich mehr öffnen will. Ich werd das nochmal neu erstellen
müssen.
accelerate that with 9,81m/s² schrieb:> gcc -m32 -Eaccelerate that with 9,81m/s² schrieb:> build/Debug/MinGW-Windows/main.o: file not recognized: File format not> recognized
Siehe
Dr. Sommer schrieb:> Achso, hast du ja sogar... Naja, da sich das ja erledigt hat: "-E" raus> und Datei löschen.accelerate that with 9,81m/s² schrieb:> Und Visual Studio beschwert sich über eine fehlende stdafx.h-Datei, die> es in einem neuen C++-Projekt automatisch einhängt.
Kann man irgendwo in den Projektoptionen abschalten.
accelerate that with 9,81m/s² schrieb:> Irgendwie kann das> VS2017 kein natives C-Projekt mehr erstellen, es markiert aber Dateien> mit einem passenden C-Icon, wenn man eine Datei gewaltsam mit .c> benennt
Geht auch. C konnte Visual Studio noch nie so richtig. C++ ist auch
"nativ".
accelerate that with 9,81m/s² schrieb:> Wenn ich die fehlende Datei dort einhänge, mißfällt ihm etwas anderes,> ich meine es war der Return-Wert.
main-Funktion mit "void" definiert?
Nein, die main ist vom Typ int. Wie es sein soll.
Ich hab die Einstellung bei VS gefunden, um das Benutzen vorkompilierter
Header zu unterlassen.
Jetzt meldet er noch zwei Fehler:
Visual Studio meckert:
> Fehler LNK2019 Verweis auf nicht aufgelöstes externes> Symbol"_printf" in Funktion "_SPI_GetNumChannels".> StartWithMPSSE I:\Documents\Visual Studio Projekte\> StartWithMPSSE\StartWithMPSSE\libMPSSE.a(ftdi_spi.o) 1
Visual Studio meckert:
> Fehler LNK2001 Nicht aufgelöstes externes Symbol "_printf".> StartWithMPSSE I:\Documents\Visual Studio Projekte\> StartWithMPSSE\StartWithMPSSE\libMPSSE.a(ftdi_infra.o) 1
Kleiner Nachtrag:
Nachdem ich noch den Projektpfad (der alle möglichen mittlerweile
eingebundenen Dateien enthält) in ein oder zwei Einstellungen
eingetragen habe funktioniert es jetzt.
Habt recht vielen Dank für eure Ausdauer hier, vor allem du, Dr. Sommer.
Eine Merkwürdigkeit hab ich allerdings noch, weiß jemand warum?
Das hier ist meine Mainfunktion. So, wie sie jetzt ist, bekomme ich die
beiden Fehlermeldungen oben:
Vermutlich linkt der Linker die C Standardbibliothek mit "printf" nur
dazu, wenn "printf" auch tatsächlich im Code des Hauptprogramms genutzt
wird. Wenn das aber ausschließlich aus einer statischen Lib aufgerufen
wird, wird das nicht erkannt. Beim GNU Linker kann man das mit
--whole-archive abschalten, bei Visual Studio weiß ichs nicht.
Danke. Dann hab ich vielleicht noch einen Ansatzpunkt, mit dem ich das
mit dem gcc zum Laufen bekomme (das wäre mir lieber als VS).
Vielen Dank nochmal für die Hilfe und Geduld.