ähmm
wie kann man HAL h-files zB xxx_hal_tim.h nachträglich so einbinden,
dass der Compiler die auch findet?
Irgendwie funktioniert das nicht im Keil uVision 5.
Und komisch ist auch, dass ich nichts einbinden muss zB auch #include
"stm32f0xx_hal.h" nicht benötige, damit alle Funktionen und
HandlerTypeDefs gefunden werden.
Was macht STM32CubeMx anders als ich bzw. was muss ich machen, damit ich
auch nicht immer extra alles zusätzlich includen muss?
sepp schrieb:> Und komisch ist auch, dass ich nichts einbinden muss zB auch #include> "stm32f0xx_hal.h" nicht benötige, damit alle Funktionen und> HandlerTypeDefs gefunden werden.
Sicher dass das nicht indirekt über einen zentralen Header passiert? Man
kann zwar über "-i" auf der Kommandozeile Header einbinden, das ist aber
ziemlich unsauber.
Dr. Sommer schrieb:> sepp schrieb:>> Und komisch ist auch, dass ich nichts einbinden muss zB auch #include>> "stm32f0xx_hal.h" nicht benötige, damit alle Funktionen und>> HandlerTypeDefs gefunden werden.>> Sicher dass das nicht indirekt über einen zentralen Header passiert? Man> kann zwar über "-i" auf der Kommandozeile Header einbinden, das ist aber> ziemlich unsauber.
Was ich meine ist, dass wenn ich den Code automatisch von STMCubeMX
generieren lasse, dass ich dann fast nichts includen muss, ausser
meistens der stmxxx_hal.h library. Die steht dann aber automatisch auch
im main.c drin.
Und wenn ich das mal gemacht habe und zB den xxx_hal_tim.h oder
xxx_hal_tim.c nachträglich einfügen möchte unter drivers, findet er die
header datei dazu nicht.
Was macht daher CubeMX anders, dass es funktioniert.
Ich weiß nicht wie Keil das macht, aber warum rufst du CubeMX nicht
einfach noch mal auf?
Ein Blick in die .uvproj zeigt, dass einfaches in die Verzeichnisse
kopieren wohl nicht genügt.
Es muss also eine Art "zum Projekt hinzufügen" geben.
Meine Güte das ist ja traurig! Klicke hier und dann dort, dann sollte es
gehen. Beim nächsten Update oder IDE Wechsel gehts dann wieder nicht /
anders.. und man muss wieder nachfragen.
Schade, dass die Programmierung von µC/C/C++ genauso Klickibunti wird,
wie vieles anderes. Versuche dir zu liebe komplett auf HAL zu verzichten
- es ist wirklich leicht.
Nörgler schrieb:> Schade, dass die Programmierung von µC/C/C++ genauso Klickibunti wird,> wie vieles anderes. Versuche dir zu liebe komplett auf HAL zu verzichten> - es ist wirklich leicht.
Einfach alles mit Simulink machen, dann wird alles besser.
pegel schrieb:> Ich weiß nicht wie Keil das macht, aber warum rufst du CubeMX> nicht> einfach noch mal auf?>> Ein Blick in die .uvproj zeigt, dass einfaches in die Verzeichnisse> kopieren wohl nicht genügt.> Es muss also eine Art "zum Projekt hinzufügen" geben.
Weil ich einfach wissen möchte, warum das nicht funktioniert.
Irgendeinen Grund muss es doch haben..
Dr. Sommer schrieb:> sepp schrieb:>> Was macht daher CubeMX anders, dass es funktioniert.>> Include Pfade per -I Option an den Compiler setzen?
Ich frage mich gerade, wo mein Commandofenster ist??
Wie kann ich das einblenden? (Siehe Bild)
Ja mei, was soll ma do no sogn?
Dr. Sommer schrieb:> Include Pfade per -I Option an den Compiler setzen?
Glaube ich nicht. Ich glaube auch nicht, dass das kompiliert wenn man
sämtliche Includes weglässt und trotzdem irgendwelche HAL-Funktionen
nutzt.
stm32f0xx_hal.h zieht stm32f0xx_hal_conf.h und da wird dann etwa über
ein
1
#define HAL_GPIO_MODULE_ENABLED
gesagt, dass der sich den Header für GPIO automagisch ziehen soll, was
dann später über
1
#ifdef HAL_GPIO_MODULE_ENABLED
2
#include"stm32f0xx_hal_gpio.h"
3
#endif /* HAL_GPIO_MODULE_ENABLED */
abgefrühstückt wird. Deshalb reicht es diesen einen Header zu includen.
Das finde ich übrigens auch nicht viel besser als die Benutzung von
-I, weil hier der Präprozessor als Build-System missbraucht wird und das
ist meiner Meinung nach viel zu oft einfach nur Käse.
Christopher J. schrieb:> Das finde ich übrigens auch nicht viel besser als die Benutzung von> -I, weil hier der Präprozessor als Build-System missbraucht wird und das> ist meiner Meinung nach viel zu oft einfach nur Käse.
Das ist Unfug!
Die HAL-Includes liegen in einem eigenen Verz. und genau das wird im
Include-Suchpfad hinzugefügt, nur, daß man das nicht manuell machen muß,
sondern im von CubeMX generierten Projekt-File bereits enthalten ist.
Der hier gewählte Ansatz ist bereits grundverkehrt!
Wie bereits oben geschrieben:
Projekt mit CubeMX generieren, und das gesamte Projekt als Projekt in
der IDE importieren!
Danach ist alles bereit und so, wie es sein soll.
Manuelle Eingriffe sind absolut nicht erforderlich.
Harry L. schrieb:> Das ist Unfug!
Was ist Unfug? Den CPP als Build-System zu missbrauchen oder was?
Um das mal klarzustellen: Meine Aussage oben bezog sich auf das hier:
sepp schrieb:> Was ich meine ist, dass wenn ich den Code automatisch von STMCubeMX> generieren lasse, dass ich dann fast nichts includen muss, ausser> meistens der stmxxx_hal.h library. Die steht dann aber automatisch auch> im main.c drin.>> Und wenn ich das mal gemacht habe und zB den xxx_hal_tim.h oder> xxx_hal_tim.c nachträglich einfügen möchte unter drivers, findet er die> header datei dazu nicht.> Was macht daher CubeMX anders, dass es funktioniert.
und die Antwort darauf ist, dass CubeMX die richtigen #defines in der
stm32yyxx_hal_conf.h setzt und dadurch alle HAL-Header automagisch
eingebunden werden, wenn man denn die Peripherie entsprechend in CubeMX
konfiguriert hat.
Christopher J. schrieb:> und die Antwort darauf ist, dass CubeMX die richtigen #defines in der> stm32yyxx_hal_conf.h setzt und dadurch alle HAL-Header automagisch> eingebunden werden, wenn man denn die Peripherie entsprechend in CubeMX> konfiguriert hat.
Ja, sorry, hatte ich wohl falsch verstanden....die Hitze....
Ist natürlich korrekt so!
Eine eigene Frage?
Dieser Thread ist über 8 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
