Hello,
I was just going through a project of mine and it just struck me that while I have been able to integrate STM32cube and pio into my workflow, there is still something lacking.
STM32cube generates peripheral files and also the requisite CMSIS and HAL libraries in the backend.
Right now, pio is using PIO generated files to compile and link the cubemx generated headers against.
File which are under the .platformio/packages/framework-stm32cube… folders.
Which seems redundant since
- STM32cube already generates these files.
- Any mismatch between the cubemx standalone software and pio version could lead to a lot of hair pulling for someone…
I was wondering if pio can be configured to use the files generated by the cubemx software directly, overriding the default versions…
@ivankravets
Any suggestions ?? Maybe specific build_flags or such for me to experiment and get back with my findings??
How about using bare programming and do all configuration manually? Just omit framework = ... option and put CubeMX to lib/ folder. You can configure build flags from extra script or using build_flags.
We did some progress with the latest version of ST STM32 dev/platform and remove all flags from global scope GitHub - platformio/platform-ststm32: ST STM32: development platform for PlatformIO
and how about the build process??
how will platformio know how to build the binary??
Well, ok… I tried as you suggested and this is what I get from the build output…
[ Deviot 2.3.0.dev3 ] Starting…
Processing disco_f030r8 (platform: ststm32; board: disco_f030r8)
Verbose mode can be enabled via -v, --verbose option
PLATFORM: ST STM32 > ST STM32F0308DISCOVERY
SYSTEM: STM32F030R8T6 48MHz 8KB RAM (64KB Flash)
DEBUG: CURRENT(stlink) ON-BOARD(stlink) EXTERNAL(blackmagic, jlink)
Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation
LDF MODES: FINDER(chain) COMPATIBILITY(soft)
Collected 1 compatible libraries
Scanning dependencies…
No dependencies
Compiling .pioenvs/disco_f030r8/src/main.o
In file included from src/main.cpp:2:0:
Core/Inc/gpio.h:48:10: fatal error: stm32f0xx_hal.h: No such file or directory
- Looking for stm32f0xx_hal.h dependency? Check our library registry!
- CLI > platformio lib search “header:stm32f0xx_hal.h”
- Web > PlatformIO Registry
#include “stm32f0xx_hal.h”
^~~~~~~~~~~~~~~~~
compilation terminated.
*** [.pioenvs/disco_f030r8/src/main.o] Error 1
========================== [ERROR] Took 0.69 seconds ==========================
and this is my directory structure
├── Core
│ └── Inc
│ ├── gpio.h
│ ├── main.h
│ ├── stm32f0xx_hal_conf.h
│ └── stm32f0xx_it.h
├── disco_030_test.gpdsc
├── disco_030_test.ioc
├── lib
│ ├── Drivers
│ │ ├── CMSIS
│ │ └── STM32F0xx_HAL_Driver
│ └── readme.txt
├── platformio.ini
├── platformio.sublime-project
└── src
└── main.cpp
I did move the cubeMX generated directory under to lib. and these are pretty much the same directories existing even in “.platformio” folder. My guess is that I must not be placing the directories right. It is not able to find the stm32f0xx_hal.h file which is under the STM32F0xx_HAL_Driver/Inc .
Moving the directories “CMSIS” and “STM32F0xx_HAL_Driver” directly under “/lib” instead of under “lib/Drivers” made no difference. The same error persists.
Any specific directory structure or path that pio requires ??
- Please switch to dev/version
platform = https://github.com/platformio/platform-ststm32.git
- You can split CMSIS and CubeMX into sub-libraries and place them to
project/lib folder.
- Please create library.json for each library and specify “name”, “version” fields. For example,
"name": "cubemx", "version": "1.0.0"… Then, you can extend build process of the library with your own build options and flags Redirecting...
Of course, framework = ... should be removed from platformio.ini. You now can control whole build process and flags.
As for the “uploading”, it should work. See platform-ststm32/main.py at develop · platformio/platform-ststm32 · GitHub
Ok.
My apologies for the delay in getting back.
It turns out there is a much much simpler way to work with the STM32cubeMX software
As per these instructions
https://hackadaycom.files.wordpress.com/2017/07/tutorial.pdf
making the necessary changes to the settings tab and regenerating the project.
All I had to do was to run "make GCC_PATH=“Platformio ARM toolchain path” " to generate the binaries.
The makefile did the rest for compiling and generating the binaries… with the cubemx generated libraries…
TL:DR, select the “Toolchain/IDE” as “makefile” and run "make GCC_PATH=(path to platformio arm toolchain) in the project directory root. The makefile does the rest…
Interesting… Of course, the directory structure generated is quite different from pio structure… maybe I ll send sometime making a pre_script to shoehorn the necessary changes to the cubemx generated files into platformio structure…
To be honest, I really don’t understand what do you need. We have built-in support for STM32Cube, could point us what is wrong with that integration?
@ivankravets actually nothing.
Pio bundles along stm32cube package which might or might not be the latest available version.
The standalone cubemx package regularly updates itself. I wanted to know if there was a way of integrating the cubemx software generated source and header files with the user code.
Turns out cubemx also has an option to generate a makefile based project which just needs a environment variable “GCC_PATH” to point to the toolchain bin folder.
All I did was that, export the said variable to point to platformio toolchain location and was able to compile and generate binaries successfully.
@valeros could you provide instruction how to update STM32Cube manually?
There is no an official way to bypass our update routine, but I think, you can just replace the content in the package or create a symlink to your folder with the updated Cube and everything should be OK.
Thank you @valeros. What you are suggesting is to replace the contents of “Drivers” folders under .platformio/packages/framework-stm32cube/(specific_family)/Drivers with the STM32cube version…
Is it an acceptable strategy to make it a pre_script??
I think this feature could help in this situation Custom platform packages per build environment · Issue #1367 · platformio/platformio-core · GitHub
Nevertheless, yes, you can replace our package with your version as you described above.
