C - Ansteuern eines FTDIs über libMPSSE

[accelerate that with 9,81m/s² (Gast)]

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.

/******************************************************************************/
/*                Include files                       */
/******************************************************************************/
/* Standard C libraries */

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
/* OS specific libraries */
//#define _WIN32
#ifdef _WIN32
#include<windows.h>
#endif

/* Include D2XX header*/
#include "ftd2xx.h"

/* Include libMPSSE header */
#include "libMPSSE_spi.h"

/******************************************************************************/
/*                Macro and type defines                 */
/******************************************************************************/
/* Helper macros */

#define APP_CHECK_STATUS(exp) {if(exp!=FT_OK){printf("%s:%d:%s(): status(0x%x) \
!= FT_OK\n",__FILE__, __LINE__, __FUNCTION__,exp);exit(1);}else{;}};
#define CHECK_NULL(exp){if(exp==NULL){printf("%s:%d:%s():  NULL expression \
encountered \n",__FILE__, __LINE__, __FUNCTION__);exit(1);}else{;}};

/* Application specific macro definations */
#define SPI_DEVICE_BUFFER_SIZE  256
#define SPI_WRITE_COMPLETION_RETRY  10
#define START_ADDRESS_EEPROM  0x00 /*read/write start address inside the EEPROM*/
#define END_ADDRESS_EEPROM  0x10
#define RETRY_COUNT_EEPROM  10 /* number of retries if read/write fails */
#define CHANNEL_TO_OPEN   0 /*0 for first available channel, 1 for next... */
#define SPI_SLAVE_0    0
#define SPI_SLAVE_1    1
#define SPI_SLAVE_2    2
#define DATA_OFFSET    4
#define USE_WRITEREAD   0

/******************************************************************************/
/*                Global variables                      */
/******************************************************************************/
static FT_HANDLE ftHandle;
static uint8 buffer[SPI_DEVICE_BUFFER_SIZE] = {0};

int main() {
    FT_STATUS status = FT_OK;
    FT_DEVICE_LIST_INFO_NODE devList = {0};
    ChannelConfig channelConf = {0};
    uint8 address = 0;
    uint32 channels = 0;
    uint16 data = 0;
    uint8 i = 0;
    uint8 latency = 255;

    channelConf.ClockRate = 5000;
    channelConf.LatencyTimer = latency;
    channelConf.configOptions = SPI_CONFIG_OPTION_MODE0 | SPI_CONFIG_OPTION_CS_DBUS3; // | SPI_CONFIG_OPTION_CS_ACTIVELOW;
    channelConf.Pin = 0x00000000; /*FinalVal-FinalDir-InitVal-InitDir (for dir 0=in, 1=out)*/

    /* init library */
#ifdef _MSC_VER
    Init_libMPSSE();
#endif
    status = SPI_GetNumChannels(&channels);

    printf("Es sind %u Gerät(e) angeschlossen", channels);

    return (EXIT_SUCCESS);
}

Kann mir irgendjemand sagen, wie ich das reparieren kann? Ich arbeite 
mit MinGW unter Netbeans.

[Dr. Sommer (Gast)]

Prüfe mal, ob "FT_STATUS" und "WINAPI" korrekt definiert sind. 
Kompiliere z.B. mal mit "-E" um die Ausgabe des Präprozessors zu sehen.

[Rufus Τ. F. (rufus)]

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?

[accelerate that with 9,81m/s² (Gast)]

Hm...

In ftd2xx.h steht in Zeile 60:

typedef ULONG  FT_STATUS;

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.

[Dr. Sommer (Gast)]

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...

[accelerate that with 9,81m/s² (Gast)]

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.

[accelerate that with 9,81m/s² (Gast)]

Ach ja, hier ist noch die Ausgabe, wenn ich mit -E kompiliere:

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: 23s)

[Allen (Gast)]

Ist denn die Lib ft2dxx.lib bzw. libMPSSE.lib im Linker Deiner
Entwicklungsumgebung mit eingebunden?

[accelerate that with 9,81m/s² (Gast)]

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.

[accelerate that with 9,81m/s² (Gast)]

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.

[Dr. Sommer (Gast)]

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.

[Allen (Gast)]

die ftd2xx.lib ist bei den d2xx-Dateien mit dabei:
http://www.ftdichip.com/Drivers/D2XX.htm

[accelerate that with 9,81m/s² (Gast)]

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)

[Dr. Sommer (Gast)]

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 (Gast)]

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.

[accelerate that with 9,81m/s² (Gast)]

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?

[Dr. Sommer (Gast)]

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:

 __attribute__((dllimport))
  FT_STATUS WINAPI FT_Open(
  int deviceNumber,
  FT_HANDLE *pHandle
  );

Das WINAPI muss noch aufgelöst werden. Das ist eigentlich in der 
windows.h definiert. Schieb das "#include <windows.h>" mal ganz nach 
oben

[accelerate that with 9,81m/s² (Gast)]

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.

/* Standard C libraries */
#include<windows.h>
#include<stdio.h>
#include<stdlib.h>
#include<string.h>

/* OS specific libraries */
#define _WIN32
#ifdef _WIN32
#include "WinTypes.h"
#endif

/* Include D2XX header*/
#include "ftd2xx.h"

/* Include libMPSSE header */
#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.

[Dr. Sommer (Gast)]

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...

[accelerate that with 9,81m/s² (Gast)]

Visual Studio...gut, das probier ich mal.

[accelerate that with 9,81m/s² (Gast)]

Danke an dich (und die anderen) für eure Hilfe bisher.
Ich berichte, ob es mit VS besser klappt.

[accelerate that with 9,81m/s² (Gast)]

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

#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... :(

[Dr. Sommer (Gast)]

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 :-)

[Rufus Τ. F. (rufus)]

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.

[accelerate that with 9,81m/s² (Gast)]

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:

/* OS specific libraries */
#define _WIN32
#ifdef _WIN32
//#include "WinTypes.h"
#include<windows.h>
#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.

[Dr. Sommer (Gast)]

accelerate that with 9,81m/s² schrieb:
> gcc -m32 -E

accelerate 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?

[accelerate that with 9,81m/s² (Gast)]

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:

int main() {
  FT_STATUS status = FT_OK;
  FT_DEVICE_LIST_INFO_NODE devList = { 0 };
  ChannelConfig channelConf = { 0 };
  uint8 address = 0;
  uint32 channels = 0;
  uint16 data = 0;
  uint8 i = 0;
  uint8 latency = 255;

  channelConf.ClockRate = 5000;
  channelConf.LatencyTimer = latency;
  channelConf.configOptions = SPI_CONFIG_OPTION_MODE0 | SPI_CONFIG_OPTION_CS_DBUS3; // | SPI_CONFIG_OPTION_CS_ACTIVELOW;
  channelConf.Pin = 0x00000000; /*FinalVal-FinalDir-InitVal-InitDir (for dir 0=in, 1=out)*/

                  /* init library */
#ifdef _MSC_VER
  Init_libMPSSE();
#endif
  status = SPI_GetNumChannels(&channels);

  //printf("Es sind %u Gerät(e) angeschlossen", channels);

  //return (EXIT_SUCCESS);
    return 0;
}

Wenn ich allerdings die printf-Anweisung wieder entkommentiere

status = SPI_GetNumChannels(&channels);

  printf("Es sind %u Gerät(e) angeschlossen", channels);

  //return (EXIT_SUCCESS);

läuft das Programm. Warum? Ich hätte im ersten Fall einfach nur eine 
leere Konsole erwartet.

[Dr. Sommer (Gast)]

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.

[accelerate that with 9,81m/s² (Gast)]

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.