@maxgerhardt thanks for example! I found the root of problem. All those packages are restricted to mbed framework in manifest, but i use stm32cube. So, libraries were silently excluded from build.
Hmm even if you add -I $PIOHOME_DIR/packages/framework-stm32cube/f4/Drivers/BSP/STM32F429I-Discovery the #include <stm32f429i_discovery.h> is found but it doesn’t compile the objects file in that library. The STM32Cube builder script doesn’t seem to process the Drivers/BSP/<board_variant> files? (@ivankravets) Only everything in Drivers\BSP\Components.
Note that there is a lib_compat_mode = off possibility (Redirecting...) but sadly the BSP_DISCO_F429ZI has an mbed-os specific include so it won’t work in this case.
The easiest way to get it working is to copy .platformio\packages\framework-stm32cube\f4\Drivers\BSP\STM32F429I-Discovery into lib/STM32F429I-Discovery and rewrite the include paths in the code
Also if you look at the LCD libraries, every function just forwards the execution into the BSP_XXX functitons so the examples should actually be really easy to port to STM32Cube by calling the wrapped functions directly instead of the C++ object functions. LCD_DISCO_F429ZI - This class drives the LCD display present on the … | Mbed
Thanks for detailed explanations. I’m familiar with hacks via lib/ and use it often, when have no time to investigate details. But scope if this thread was to understand how to do things “right and beautiful” .
I’m not sure if this should be posted to tracker or it’s my mistake because something is done wrong.
Note that to get a working firmware you must initialize the HAL and setup handlers as in
Sure. Sample repo is just a minimal cut to demonstrate problem. It skips a lot of thing from real project.
Okay this has a second part. There is code that attempts to do that
However the path that it constructs here in my case is C:\Users\Maxi\.platformio\packages\framework-stm32cube\f4\Drivers\BSP\DISCO_F429ZI and not C:\Users\Maxi\.platformio\packages\framework-stm32cube\f4\Drivers\BSP\STM32F429I-Discovery. In general variant may not correspond to the folder names inside that directory.
Yes, otherwise the ILI9341 driver (framework-stm32cube\f4\Drivers\BSP\Components\ili9341) won’t be compiled and you will get an undefinded reference to .. error when calling BSP_LCD_XXX functions. The needed name is comprised of BSP- plus the folder name inside Components/, see the Python code at
Hm… do i understand right, this code dynamically register ghost BSP-* libs as “available for use”?
Seems this feature is not documented anywhere in stm32cube platform docs. Probably worth to add - even with correct variant_remap.json i could not resolve this without your help.