Hallo,
ich nutze EMbitz V 1.0 und MXCube. Ziel ist ein STM32F437.
Jetzt kommt das Interessante/traurige:
Wenn ich mir das Projekt erstellen lasse mit MXCube (nutze ADC, SPI,
UART) dann ist soweit erstmal alles da und ok.
ABER: Die ganzen Funktionen wie bspw: HAL_ADC_Init, HAL_SPI_Init werden
bei mir als undefined reference to HAL_ADC_Init als Fehler ausgebeben.
Warum ist das so? Also alle Funktionen die ich nutzen möchte, bzw.
aufrufe wie:
HAL_ADC_Init(&hadc1);
funktionieren nicht? Ich habe sogar nochmal extra in meiner adc.h die
hal_adc.h eingebunden.
In der adc.c wird das dann verwendet.
Wo liegt mein Fehler?!
holger schrieb:> undefined reference bedeutet eigentlich fast immer> dass eine *.c Datei im Projekt fehlt.
Ja genau, aber die Sache ist die, die sind ja da, auch eingebunden.
Bzw. in der .c ist die entsprechende .h eingebunden. Bzw. in der
hal_adc.c war nur die _hal.h eingebunden. Ich habe nochmal die hal_adc.h
dort eingebunden, aber das hat keinen Effekt.
Hat das mit meinen Linkereinstellungen zu tun? -lc, -lgcc, -lm?
C-Programme werden modular übersetzt. Jedes C-Sourcefile einzeln, und
das Ergebnis wird vom Linker zusammengesetzt. Du bindest Headerdateien
(*.h) ein, damit sind die Deklarationen der Funktionen etc. verfügbar,
aber das instruiert nicht den Compiler, das zugehörige C-Sourcefile zu
übersetzen und nicht den Linker, das Ergebnis davon zum Endergebnis
dazuzupacken.
Mit anderen Worten: Du solltest Dir genau ansehen, wie man weitere
C-Sourcefiles in die Projektverwaltung Deiner IDE einfügt, so daß sie
übersetzt und das Resultat gelinkt werden.
Sollten die Funktionen, die Du verwendest, bereits in compilierter Form
als Library vorliegen (nein, das ist nicht eine *.h-Datei, auch wenn
hier immer mehr Leute unterwegs sind, die das glauben), also einer Datei
namens *.lib oder *.a (je nach Compiler), dann, und nur dann musst Du
Deinen Linker dazu instruieren, diese Library zu verarbeiten. Bei gcc
gibt es die Angewohnheit, nicht den Dateinamen der Library, sondern nur
einen Teil davon anzugeben; heißt die Datei beispielsweise libfusel.a,
wird als Linkeroption nur -lfusel angegeben. Andere Compiler mit anderen
Linkern handhaben das anders, da musst Du in die Dokumentation Deines
Entwicklungssystems gucken.
Rufus Τ. F. schrieb:> C-Programme werden modular übersetzt. Jedes C-Sourcefile einzeln, und> das Ergebnis wird vom Linker zusammengesetzt. Du bindest Headerdateien> (*.h) ein, damit sind die Deklarationen der Funktionen etc. verfügbar,> aber das instruiert nicht den Compiler, das zugehörige C-Sourcefile zu> übersetzen und nicht den Linker, das Ergebnis davon zum Endergebnis> dazuzupacken.>> Mit anderen Worten: Du solltest Dir genau ansehen, wie man weitere> C-Sourcefiles in die Projektverwaltung Deiner IDE einfügt, so daß sie> übersetzt und das Resultat gelinkt werden.>> Sollten die Funktionen, die Du verwendest, bereits in compilierter Form> als Library vorliegen (nein, das ist nicht eine *.h-Datei, auch wenn> hier immer mehr Leute unterwegs sind, die das glauben), also einer Datei> namens *.lib oder *.a (je nach Compiler), dann, und nur dann musst Du> Deinen Linker dazu instruieren, diese Library zu verarbeiten. Bei gcc> gibt es die Angewohnheit, nicht den Dateinamen der Library, sondern nur> einen Teil davon anzugeben; heißt die Datei beispielsweise libfusel.a,> wird als Linkeroption nur -lfusel angegeben. Andere Compiler mit anderen> Linkern handhaben das anders, da musst Du in die Dokumentation Deines> Entwicklungssystems gucken.
Ja das habe ich alles schon, dass ist klar.
Das Problem liegt wo anders. Eigene Dateien (.c/.h) können nicht in
Unterordner gepackt werden, wenn in diesen verlinkungen zu weiteren
Headers stattfindet. Die müssen im Hauptverzeichnis unter Scr/Inc
liegen. Jetzt geht alles; tricky der "Fehler" und für mich nicht ganz
nachvollziehbar.
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
