Hallo, ich mache eine FFT auf einem ARM STM32L4 und F4. Dazu habe ich die arm_math.h eingebunden. Das Problem ist, bei Zeile 5757 *pOut = __builtin_sqrtf(in); sagt er mir, dass _builtin_sqrtf unbekannt (undefined refernece) ist. Interessanterweise zeigt er erst Hex-File generation an, dann, während der Hex file generation kommt der Fehler. Ich habe das Projekt mit MXCube erzeugt, also die ganzen HAL-Treiber und Dateien sind davon. Außerdem nutze ich EMBitz V 1.0. Wenn ich die Line ausklammer, kann es erstellt werden, aber das bringt mir ja nichts. Habe auch schonmal nur __sqrtf oder sqrtf genutzt, geht auch. __FPU_PRESENT und __FPU_USED habe ich als defines im Compiler. Außerdem noch ARM_MATH_CM4. Weiß jmd. da einen Rat?!
Marius D. schrieb: > undefined refernece deutet eigentlich immer darauf hin das die .h zwar da ist, aber die zugehörige .c oder lib fehlt. Lies dazu die Hinweise in der arm_math.h
hp-freund schrieb: > Marius D. schrieb: >> undefined refernece > > deutet eigentlich immer darauf hin das die .h zwar da ist, aber die > zugehörige .c oder lib fehlt. > > Lies dazu die Hinweise in der arm_math.h Ja, da hast du Recht, es fehlen mir merke ich gerade rel. viele .c Eigentlich im Ordner CMSIS sind zig Dateien .h da, aber nur der Ordner Include, da fehlt der zugehörige Ordner Source. Was DSP_Lib, Device und RTOS angeht passt alles wie es aussieht. Anbei mal meine .ioc. Wo bekomme ich die her? Müsste MXCube das nicht auswerfen? ich habe dort angegeben All used librarys.
Marius D. schrieb: > keine einzige .c Kann auch eine lib sein, wenn ST nicht alles offen legen will. Die musst Du dann deinem EMBitz angeben.
hp-freund schrieb: > Marius D. schrieb: >> keine einzige .c > > Kann auch eine lib sein, wenn ST nicht alles offen legen will. > Die musst Du dann deinem EMBitz angeben. Ich habe das auch gerade herausgefunden. Das scheinen wirklich diese .lib bzw. bei mir durch GCC .a zu sein. Die wurden mir aber nicht mit ausgegeben. Ich habe jetzt welche, ich hoffe die passen, aber irgendwie will das tzd. nicht so wirklich. Unter Build Options -> Linker settings habe ich die libarm_cortexM4lf_math.a hinzugefügt, aber ich glaube der nimmt die nicht wirklich. Muss ich da noch was anderes einstellen? Als Linker Script habe ich das aus MXCube (./STM32L476VG_FLASH.ld) genommen.
hp-freund schrieb: > libarm_cortexM4lf_math.a -> -l arm_cortexM4lf_math Verstehe ich jetzt nicht so ganz. Ich habe bei Linker Flags noch das rein gemacht: -lm -lc -lgcc Ist das ok? Damit kann ich es zumindest compilieren, allerdings hängt er sich bei der ausgeklammert Zeile auf, wie kann das sein?
1 | arm_cfft_radix4_init_f32(&fft_S, FFT_SIZE, 0, 1); |
2 | //arm_cfft_radix4_f32(&fft_S, Input);
|
3 | arm_cmplx_mag_f32(Input, Output, FFT_SIZE); |
4 | arm_max_f32(Output, FFT_SIZE, &maxValue, &maxIndex); |
Edit: Die war anscheinend zu groß, mit 512 statt 4096 geht es. Kann mir jmd. vll. kurz sagen, wo der genaue Unterscheid zwischen den FFT mit/ohne radix ist, und was die Zahl bedeutet, ich bin mir unsicher was ich jetzt brauche.
Marius D. schrieb: > Ich habe bei Linker Flags noch das rein gemacht: > -lm > -lc > -lgcc c und gcc müssten eignetlich da gewesen sein. -lm sollte immer als letztes in der Zeile stehen. Warum das //arm_cfft_radix4_f32(&fft_S, Input); nicht funktioniert weiß ich auch nicht. Es gibt aber eine ausführliche Hilfe für die Funktionen, wenn ich mich recht erinnere.
http://web.eece.maine.edu/~hummels/classes/ece486/docs/CMSIS/Documentation/DSP/html/arm__cfft__radix4__f32_8c.html http://web.eece.maine.edu/~hummels/classes/ece486/docs/CMSIS/Documentation/DSP/html/arm__cfft__f32_8c.html mit vielen links und Beispielen.
hp-freund schrieb: > http://web.eece.maine.edu/~hummels/classes/ece486/docs/CMSIS/Documentation/DSP/html/arm__cfft__radix4__f32_8c.html > > http://web.eece.maine.edu/~hummels/classes/ece486/docs/CMSIS/Documentation/DSP/html/arm__cfft__f32_8c.html > > mit vielen links und Beispielen. Danke dir. Mal eine weitere Frage: Ich habe ein weiteres Problem. Das kennt er für Timer und funktioniert TIM_HandleTypeDef htim2; //for system time generating Die werden alle als unknown type name deklariert?! Muss ich da noch was spezielles einbinden? Die wurden von MXCube so angegeben, aber geht leider nicht :( CAN_HandleTypeDef hcan1; SPI_HandleTypeDef hspi3; SPI_HandleTypeDef hspi4; UART_HandleTypeDef huart2;
Was hp-freund sagen will: lass "lib" vorn und ".a" hinten weg, dann klappt es auch mit der Lib.
Marius D. schrieb: > hp-freund schrieb: >> > http://web.eece.maine.edu/~hummels/classes/ece486/docs/CMSIS/Documentation/DSP/html/arm__cfft__radix4__f32_8c.html >> >> > http://web.eece.maine.edu/~hummels/classes/ece486/docs/CMSIS/Documentation/DSP/html/arm__cfft__f32_8c.html >> >> mit vielen links und Beispielen. > > Danke dir. > > Mal eine weitere Frage: > Ich habe ein weiteres Problem. > > Das kennt er für Timer und funktioniert > TIM_HandleTypeDef htim2; //for system time generating > > > Die werden alle als unknown type name deklariert?! > Muss ich da noch was spezielles einbinden? Die wurden von MXCube so > angegeben, aber geht leider nicht :( > > CAN_HandleTypeDef hcan1; > > SPI_HandleTypeDef hspi3; > SPI_HandleTypeDef hspi4; > > UART_HandleTypeDef huart2; Okay anscheinend ein Bug in MXCube, die Unterdateien (STNxx_xxx_can.h) sind nicht eingebunden, sodass er nicht drauf zu greift. Habe die Dateien jetzt einzeln eingebunden, jetzt geht es das er die findet. Komisch aber. Allerdings hat er jetzt das Problem, dass er die Funktionen nicht kennt?! So langsam bin ich am verzweifeln, kann doch nicht sein. HAL_CAN_Init(&can_instance); //Die kennt er nicht, in der hal_can.c ist das auch anders implementiert und zwar so: HAL_StatusTypeDef HAL_CAN_Init(CAN_HandleTypeDef* hcan) Was mache ich nur falsch?!
Marius D. schrieb: > Die wurden von MXCube so > angegeben, aber geht leider nicht :( > > CAN_HandleTypeDef hcan1; ....... In der ico die Du oben angibst aber nicht.
hp-freund schrieb: > Marius D. schrieb: >> Die wurden von MXCube so >> angegeben, aber geht leider nicht :( >> >> CAN_HandleTypeDef hcan1; ....... > > In der ico die Du oben angibst aber nicht. Kann eine alte sein, hier mal die neue. Ich habe mal in die entsprechende xxx_can.c reingeguckt, dort ist die .h gar nicht eingebunden, sondern nur die globale #include "stm32f4xx_hal.h" Was stimmt da denn nicht?! Ich verstehe es nicht, jede Funktion meckert der nur rum das die undefinierte reference hat. Ein Beispiel: Ich nutze Uart und die HAL_UART_RECEIVE, HAL_UART_RECEIVE_IT und HAL_UART_IRQHANDLER (was auch so durch MXCube angegeben). Ich habe jetzt schon in der .c mal einfach nochmal die .h der xxx_hal_uart angegeben, obwohl das ja eigentlich nicht sein müsste. In der .h sind die Funktionen implementiert. In der .c fehlen aber diese o.g. Funktionen?! Kann mir jmd. helfen?
Angehängte Dateien:
Ich habe zum Spaß ein SW4STM32 Projekt aus deiner ioc erstellt. Ohne Änderungen ist alles drin was drin sein soll. Muß also an deinem EmBitz Import liegen...
hp-freund schrieb: > Ich habe zum Spaß ein SW4STM32 Projekt aus deiner ioc erstellt. > Ohne Änderungen ist alles drin was drin sein soll. > > Muß also an deinem EmBitz Import liegen... Ich bin einen Schritt weiter. 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.
Habe noch mal neu gebaut, dieses Mal mit .h/.c für jede Peripherie. Also z.B. adc.h/adc.c wird erzeugt. Darin wird HAL_ADC_Init aufgerufen. Automatisch. Warum musst Du die einzeln aufrufen? Hast Du auch wirklich alle Verzeichnisse in die Ouellverzeichnis-Suche eingebunden?
hp-freund schrieb: > Hast Du auch wirklich alle Verzeichnisse in die Ouellverzeichnis-Suche > eingebunden? Auch das Hauptverzeichnis in dem sich adc.c usw. befinden?
hp-freund schrieb: > hp-freund schrieb: >> Hast Du auch wirklich alle Verzeichnisse in die Ouellverzeichnis-Suche >> eingebunden? > > Auch das Hauptverzeichnis in dem sich adc.c usw. befinden? Ich danke dir erstmal für deine Mühe. Ich habe nochmal geguckt. in der xxx_hal_adc.c ist die entsprechende xxx_hal_adc.h nicht eingebunden. Ich habe das, weil es mich gewundert hat, nochmal gemacht, bzw. die mal da rein geschrieben. Kein Effekt - leider. Es ist bei mir so: main.c ist das Hauptprogramm, dort binde ich die adc.h ein. Darin wird die xxx_hal.h und xxx_hal_adc.h eingebunden. Dort sind div. Funktionen dann deklariert. In der adc.c ist nur die adc.h eingebunden, dort sind die Funktionen dann erstellt. Darin enthalten die Funktionen wie HAL_ADC_init(&adc1); Eigentlich doch ganz normales vorgehen, oder?
hp-freund schrieb: > Habe noch mal neu gebaut, dieses Mal mit .h/.c für jede Peripherie. > Also z.B. adc.h/adc.c wird erzeugt. > Darin wird HAL_ADC_Init aufgerufen. Automatisch. > Warum musst Du die einzeln aufrufen? > Hast Du auch wirklich alle Verzeichnisse in die Ouellverzeichnis-Suche > eingebunden? Achso, Missverständnis wahrscheinlich. Ich habe nicht für jede Peripherie das gemacht, sondern so wie die .ioc hochgeladen ist. Ich habe selbst erstellte adc.h/c erstellt, weil dort noch mehr gemacht wird, bzw. ich das gemacht habe bevor ich das gesehen habe das es die Funktion gibt. Hat damit erstmal nichts zu tun an sich. Quellverzeichnis-Suche? Wo ist die?! Edit: Die Dateien liegen in einem Unterordner im Verzeichnis vom EMbitz Project, also nicht direkt in Inc/Src, das sollte aber ja egal sein, oder?
Marius D. schrieb: > Ich habe selbst erstellte adc.h/c erstellt, weil dort noch mehr gemacht > wird, bzw. ich das gemacht habe bevor ich das gesehen habe das es die > Funktion gibt. Hat damit erstmal nichts zu tun an sich. Oha. Marius D. schrieb: > Quellverzeichnis-Suche? Wo ist die?! In EmBitz? Keine Ahnung :-( Ich weiß schon warum mir SW4STM32 lieber ist das von ST unterstützt wird ;-)
Marius D. schrieb: > Die Dateien liegen in einem Unterordner im Verzeichnis vom EMbitz > Project, also nicht direkt in Inc/Src, das sollte aber ja egal sein, > oder? Und den kennt EmBitz auch? Egal? Na ja...
hp-freund schrieb: > Marius D. schrieb: >> Die Dateien liegen in einem Unterordner im Verzeichnis vom EMbitz >> Project, also nicht direkt in Inc/Src, das sollte aber ja egal sein, >> oder? > > Und den kennt EmBitz auch? > Egal? Na ja... Jap, der ist eingefügt. Ich teste das aber mal wirklich wenn die nicht im Extra-Ordner liegen.
hp-freund schrieb: > Und den kennt EmBitz auch? > Egal? Na ja... Jap, der ist eingefügt. Ich teste das aber mal wirklich wenn die nicht im Extra-Ordner liegen.
hp-freund schrieb: > Marius D. schrieb: >> Ich habe selbst erstellte adc.h/c erstellt, weil dort noch mehr gemacht >> wird, bzw. ich das gemacht habe bevor ich das gesehen habe das es die >> Funktion gibt. Hat damit erstmal nichts zu tun an sich. > > Oha. > > Marius D. schrieb: >> Quellverzeichnis-Suche? Wo ist die?! > > In EmBitz? Keine Ahnung :-( > > Ich weiß schon warum mir SW4STM32 lieber ist das von ST unterstützt wird > ;-) SW4STM32 -> Eclipsebasis, oder? Wenn ich Eclipse höre renne ich so schnell wie ich nur kann. Es gibt, meiner Meinung nach, keine schlechtere Umgebung, außer vll. Xilinx Ise. Da kann man auch direkt im Editor schreiben. Ich bin durch Atmel stark mit AtmelStudio und damit VisualStudio verbunden, und EMbitz kommt dem am nächsten. Markier mal eine Variable und drück '(', bei den meisten ist der Name dann weg und es steht da ein (, bei VisualStuido ist das dann eingeklammert. Einrücken/zurückrücken klappt alles, auch automatisch wenn man { macht unter einander und man hat die Tab-Stops direkt dort hintereinander. Funktionen einklappen, auto-vervollständigung usw. Alles mager bei Eclipse. Man muss dort fast alles ausgeschrieben haben, bis man was angezeigt bekommt.
Marius D. schrieb: > Funktionen einklappen, auto-vervollständigung usw. Alles mager bei > Eclipse. > Man muss dort fast alles ausgeschrieben haben, bis man was angezeigt > bekommt. Sehe ich nicht so, werde mich aber nicht an einer derartigen Diskussion beteiligen...
hp-freund schrieb: > Marius D. schrieb: >> Funktionen einklappen, auto-vervollständigung usw. Alles mager bei >> Eclipse. >> Man muss dort fast alles ausgeschrieben haben, bis man was angezeigt >> bekommt. > > Sehe ich nicht so, werde mich aber nicht an einer derartigen Diskussion > beteiligen... Ist auch das letzte was ich machen wollte :) Jedem das Seine! Finde nur persöhnlich auch imemr doof, wenn ich auf 3. Anbieter wechseln muss
hp-freund schrieb: > Marius D. schrieb: >> Funktionen einklappen, auto-vervollständigung usw. Alles mager bei >> Eclipse. >> Man muss dort fast alles ausgeschrieben haben, bis man was angezeigt >> bekommt. > > Sehe ich nicht so, werde mich aber nicht an einer derartigen Diskussion > beteiligen... Aber, es war tatsächlich dein Einwand/bzw. deine Idee das du das mit seperaten .c/.h gemacht hast. Dadurch habe ich testweise wie beschrieben mal meine Dateien in das Hauptverzeichnis unter Src/Inc gepackt, statt im Ordner, und nun geht es! Zwar absolut blöd, aber es läuft, danke für den Gedankenstupser!
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.