What is the relationship between HAL_ and MX_ APIs?

[CCarb.1]

CubeMX provides a host of MX_ functions for which I'm unable to find any documentation.

I can instea find extensive HAL and LL API documentation.

And these APIs overlap like MX_TIMxx_EnablePWM and HAL_TIM_PWM_Init

There is also a lot of MX_init code but there is also a lot of HAL_MSP_Init code.

What's the rationale here to choose one or the other?

[YSN]

As per my understanding, 

MX_TIMXx Functions are generated by CubeMX based on your peripheral 

configurations.

Whereas HAL_TIMxx API is low lever peripheral driver which is static across 

code generations irrespective of your peripheral configuration.

Now, the MX function will fill the structure attributes with peripheral configurations

and pass on to HAL Function. 

[TDK]

> What's the rationale here to choose one or the other?

They are not independent. MX_ functions are generated by CubeMX and are specific to your project. HAL_ functions are general drivers and will not change between projects with the exception of weakly defined functions like HAL_MSPInit calls which are specific to your project (and generated by CubeMX).

[Pavel A.]

Hi,

To understand the rationale of HAL_MSP APIs one should be familiar with concept of "pin multiplexing" on ARM and similar SoCs.

Pins in these chips are "overbooked". That's, a chip may have not enough pins to enable all its IP modules (aka "peripherals") at once.

Also some "peripherals" have several alternative pin assignments.

In embedded Linux, "pinmux" and "device tree" components deal with this.

Small systems do the separation of IP modules drivers from the "pinmux" in a much simpler way.

The ST Cube HAL drivers call a "MSP" routine from every HAL_***_Init() function for a peripheral instance.

This routine does the job of the pinmux layer for the instance: it allocates and configures pins and does other low level configuration needed to enable the instance in desired mode.

Actually there's no allocation, because the CubeMX/CubeiDE GUI ensures that there are no pin conflicts before generating all these functions that go into the msp files.

As an alternative, developer can do all the pinmux stuff themselves, before initialization of HAL drivers, and omit the "MSP" functions and files.

For this case the "HAL" library provides empty weak "MSP" functions so there won't be unresolved calls.

OTOH the "LL" library modules do not call the "MSP" layer, leaving the pinmux entirely on the developer.

--pa

[Piranha]

As for pin configuration - there is a much simpler and more efficient way than writing a code for each pin. Read my answer here:

https://community.st.com/s/question/0D53W00000pRw6xSAC/stm32cubemx-incorrect-code-generation-for-exti-on-stm32h7-with-ll-driver