Stm32 SPL or Registers?

Question

Microcontrollers

Good afternoon, after lpc, I wanted to get acquainted with stm32, and then the question arose, in lpc for everything to work, I used the register setting through explicit access to them, in stm32 there is a convenient SPL wrapper, so which way would be more correct to write as before, or use a convenient lib, which some sin on?

Answer 1

SPL
pluses:
1. An acceptable level of abstraction between different stones and families, there are manuals on how to transfer software from one to another stm32 family and ONLY SPL
2 is described in them. It is more understandable than writing to registers, especially if you need to use developments later in a couple of years or another person.
3. The manufacturer itself tested the chips specifically on the SPL, which means that the procedure for working with peripherals that is included in the SPL will give significantly fewer glitches than any other.
4. The SPL is intuitive and you can write "in the village of grandfather", i.e. DAC_deinit(), for example, knowing that ADC_DeInit() exists, it means that there is something else
5. There are still a lot of developments in SPL - in many functions there are very subtle moments and nuances that have already been done and when working with registers you will definitely run into them and spend more than one week.
MINUSES:
1. SPL is slow, especially leg jerking - but it is not intended for this at all, and it is stupid to expect speeds of a couple of cycles from it. And for 99% of tasks, SPL is fast enough. As a solution to the problem, use bit-by-bit access for leg jerking, or once set up what you need through SPL, save all the register values ​​\u200b\u200binto temporary variables and simply copy everything into the register block with one memmove - as quickly as possible, especially for DMA which needs to do a lot of everything.
2. SPL is thick - eats a lot of flash, this problem is solved by turning some of the functions into an inline version, then all checks for all peripheral blocks disappear and the code is reduced by 3-5 times, but only if it is used once. You can run into the features of inline functions and other shortcomings. But for 99% of tasks, the size of the flush is enough and it is not necessary to put SPL on a diet or it is simply stupid.
3. SPL code is cumbersome... well, you haven't seen WinAPI and other high-level languages.
4. SPL is written taking into account that a professional C will code on it and such blunders as forgetting to clear the structure of stack garbage means that a professional will not do it, but if a beginner allows them, then he himself is a fool and you can stink on the forums for a long time that SPL is shit - hands from this won't straighten up.

Answer 2

For initialization and non-demanding sections - opencm3, for critical things - registers. Nothing else is given.
HAL/Qube should never be used.

Answer 3

On SPL, ST itself is already sinning, so they came up with HAL. But sometimes, neither there nor there is the necessary functions. Therefore, you have to make a garden from the library and your functions of working with registers.

Answer 4

I myself write on some wild mixture of clippings from HAL and self-written register calls. The second is dominant.
In some places, the architecture of the HAL itself is quite strange and literally baffles. For example, ETH_HAL_ReceivePacket could not be made to work due to the fact that it is simply poorly described.
I had to sculpt my nimble bicycles.
It was easier with sending, but I am also switching to my more lightweight functions.