Hello all,
I’ve spend some times to get accustomed to platformio and now I try to create an efficient CubeMX framework.
I tried different way to use code generated with MX but had some compilation errors due to outdated includes and I didn’t wanted to blindly replace the files in the pio cube framework. There may be other solutions that what I did.
I am using a Nucleo H743 board but transposing these infos for other STM32 boards should be easy.
First, here is what I did to create the framework:
- Create a framework-stm32cubemx folder in .platformio/packages/
- Copy the platformio folder and the package.json file from framework-stm32cube/ to framework-stm32cubemx/
- Create an xx/ folder (xx being your stm32 mcu architechture. f0, f1, f7 etc…)
- Modify package.json and change stm32cube to stm32cubemx
The latest ST files for the mcu and board are downloaded in a local repo by MX when initialising a project. I copied them into the hacked up mx framework folder:
- Copy %User%/STM32Cube/Repository/STM32Cube_FW_H7_V1.4.0/Drivers/ and Utilities/ folder in h7/. It could be interesting to add Middleware/ also, more later. Your ST folder may be any STM32Cube_FW_XX_Vx.x.x depending on what MX have downloaded.
So now the framework_cubemx folder has the latest STM32 drivers sources and includes for the board.
I made some changes in .platformio/platform/ststm32 for pio to find this mx framework.
- in boards/myboard.json (replace my board with your board), add stm32cubemx in the framework list
- in builder/frameworks copy stm32cube.py and rename it stm32cubemx.py
- in platform.json/frameworks add:
“stm32cubemx”: {
“package”: “framework-stm32cubemx”,
“script”: “builder/frameworks/stm32cubemx.py”
}
Next I modified stm32cubemx.py. It was a little bit of work but I love python when it almost reads like haikus. Nice work Pio Team. After some fiddling around I got something to work well.
- All drivers includes and sources are taken from the project_dir where MX generates its code. This is to avoid pio compilling all the drivers if only somes are generated. More on that later.
- All CMSIS includes and sources are taken from the framework folder because MX doesn’t copy everything needed in the project folder, so it needed to be the full CMSIS folder.
- xx_hal_conf.h is copied in project_dir/driver/Inc at every compilation from the project_dir/Inc folder, and not copied from the template.
- script still search for linker script in the framework/platformio folder
Here is the full stm32cubemx.py file content:
Next, to start working with this, create a new project with platformio using the stm32cube framework (not stm32cubemx yet as pio doesn’t know how to initialise this framework (yet)). Once the project is created you can change the framework to stm32cubemx in platformio.ini and add
build_flags =
-D CORE_M7
-I Inc
In MX, create a new project and save the project in the same folder. I like to have as few files as possible and my main clean. So:
Also, choose Other Toolchains (GPDSC) as your Toolchain/IDE option.
In my case, it compiles, runs and debugs fine with these options.
Now to go further:
The option “Copy all used library…” in MX makes compilation fails.
This is surely due to the py script adding all .c files from the drivers/src dir to the libs-to-build cue, but hal_conf.h does not include all the headers as the periph is not ENABLED.
What’s next ? Well we could add the Middleware folder in the compilation list. Should be relatively easy to do, will try this next. (EDIT: It’s not, CubeMX doesn’t remove Middleware generated files like the drivers files, it also doesn’t remove the #includes hen you disable a Middlware… it’s a mess I’m going to cry…)
The py script could exclude the .c drivers that are not enabled by MX in the conf file.
It may also be possible to directly download the repo from ST.
Please tell me what you think, I would love to see this come to life in a pio update, and if you have hints about how to modify the python script further, please tell.
