- This topic has 3 replies, 3 voices, and was last updated 6 years ago by
.
-
Posts
-
Hi
More of a ST software ecosystem question but is it possible to combine the functionality STM32CubeMX with the mbed SDK, or are they mutually exclusive? This would be assuming a MCU that is supported by mbed. How would this be setup/work using VisualGDB?
I see that you can set up/use the two separately:
But is it possible to have the STM32CubeMX as a base project and still use the high-level APIs provided by mbed (like DigitalOut, SPI)? Or, have an mbed project as a base and use STm32CubeMX to replace/add new code at the HAL?
Hi,
The mbed project actually includes a copy of the STM32 HAL framework (in libraries\mbed\targets\cmsis\TARGET_STM\TARGET_STM32xx), so you can theoretically replace it with the one that came with STM32CubeMX and use the code generated by it.
In practice this may trigger compatibility problems between the mbed code that expects an older version of the HAL and the newer HAL take from STM32CubeMX. It should not be anything too complex, but it may not work out-of-the-box.
On the VisualGDB side you can convert an mbed project to a stand-alone one and then switch the files to avoid affecting other projects.
The STM32CubeMX uses the STM32 HAL and it is not mutually exclusive with the mbedOS, though there are a few important points you must pay attention to when using them together. The most straightforward way to set up a dual project is to create two projects: one in mbed and one in CubeMX. Use the mbed project for your code and the CubeMX as a reference.
Setup peripherals:
Setup your CubeMX project with all the system resources you’ll need (peripherals, clock sources, etc) and generate the code. Take a look at the files generated and the functions contained within them. What you’ll want to look for is HAL_PPP_MspInit() and HAL_PPP_MspDeInit() (where PPP is the peripheral) and any Init() functions generated. You’ll want to add these to your mbed project. Take a look at the HAL documentation for the peripheral you’re using to figure out how to use its functionality (the configuration of the peripheral can all be handled within CubeMX) – the HAL is very well documented. Do this for all the peripherals you want to use.
Setup clocks:
The CubeMX generated code also creates a function called SystemClock_Config(). This function is already called by mbed, but mbed’s function won’t contain what you’ll need from the CubeMX. Take a look at the CubeMX code’s SystemClock_Config() and mbed’s system_clock.c:SystemClock_Config() to see what you’ll need to add (this all depends on which resources you’re using, but it will most likely just be the RCC_PeriphCLKInitTypeDef object). mbed’s SystemClock_Config() will be setup for your specific target, so you don’t really want to modify much else outside the peripheral clocks. It’s a good idea to duplicate the contents of system_clock.c and remove it from your mbed project, then modify your local copy.
Using IRQHandlers:
If you want to use IRQHandlers or callbacks in the HAL, enable that option in your CubeMX project. The generated code will create the IRQHandler and the HAL_PPP_MspInit() function will contain calls to HAL_NVIC_SetPriority() and HAL_NVIC_EnableIRQ() for that particular peripheral. WHAT WILL BE MISSING is the call to NVIC_SetVector( PPP_IRQn, (uint32_t)&PPP_IRQHandler). You must add this before enabling the IRQ. The CMSIS documentation states that the vector table must be relocated to RAM in order to call NVIC_SetVector(), but you don’t have to do this. This is already handled by mbed.
This should be enough to get anyone started if they try to use mbed with the STM32 HAL. Good luck!
- You must be logged in to reply to this topic.