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
