I want to learn a real microcontroller with STM32F4. Which library should I use (HAL, SPL, or CMSIS)? [duplicate]

Question

From what I know, ST will stop to develop Standard Peripheral Libraries (SPL) for the next generations of STM32. And HAL is not ideal for people who want to understand well about STM32 and microcontrollers. Can you suggest me which one is the best to use (for learning and working in the future)?

Answer 1

If you really want to learn a specific microcontroller, ditch the vendor provided libraries (which are often bug ridden anyway), and work from the datasheet to set registers up yourself.

You're best to structure your code so the libraries aren't integrated into your application. Keep hardware access to a thin interface layer which you can easily swap out if you change silicon vendor without having to make changes throughout your code base.

Answer 2

If your goal is to understand in detail how the microcontroller works, then just use the register declaration file (stm32fxxx.h) and work directly with the hardware. It is not that difficult, and for some peripherals I would argue it can be much simpler, as the ST libraries add a lot of framework code that few people really need. Once you've learnt how to configure and use each peripheral you will probably want to use a library to do the boiler plate work, but at that point you'll have the knowledge to be able to decide if you want to roll your own, or use one of ST's offerings (and importantly debug those libraries if you end up using them).

Also note that CMSIS is a bit different from the other sort of 'hardware abstraction' libraries you might be looking at. Essentially, it is a very lightweight vendor independent software layer defined by ARM for managing core CPU support functions (interrupts, fpu, memory etc). The reason they created this is that in the early days of ARM microcontrollers, ARM only supplied the core CPU. These were not initially developed for single chip microcontroller work, so they had a very simple interrupt handling scheme - basically just a mechanism for saving CPU state and branching to a single vector on the assertion of the IRQ line. If you wanted to have different interrupt sources, then the chip vendor had to add an interrupt handler peripheral. The problem was that each vendor started developing their own interrupt handling systems, and this meant that code could not be ported so easily between chips.

When ARM released the Cortex-M line - specifically targeted at microcontroller applications - they built in some of these more common support peripherals with the CPU core IP. To provided access to these peripherals they also defined the CMSIS.

In practice you will almost always use the CMSIS libraries in your projects, but you should be able to see from the source code that much of it is really just register definitions, and it is very lightweight.

Answer 3

I agree with most of the others; you should just get the documentation from ST and start using it. It is as easy to program the peripherals directly as it is to use a vendor-provided library. There is no other choice if you want to learn about the microcontroller.

If you just want to learn how to call some APIs then try the libraries.

As far as working in this field now and in the future, try them all. From directly accessing the peripherals, not even using someone else's header files make your own. All the way to and through whatever libraries, soon to be obsolete or brand new, that you can get your hands on. Experience the RTOS approach; take a working FreeRTOS or whatever they have ported or someone has ported and try that.

From one manager to the next or one employer to the next or one project to the next you may have to be switching from truly baremetal to calling APIs and back. You may have to dig into the vendor or other supplied code and examine it side by side with the documentation to find out what it is or isn't doing for you to work through a problem.

But you should be able to go from scratch (granted examining documentation and other folks examples), boot the Cortex-M, configure the GPIO(s) tied to LEDs, burn time in loops, and make the LED(s) blink on and off. From there decide if you want to continue into timers and the UART and then interrupts or SPI or I²C or PWM other paths within what is available on that chip. Or repeat the experiences with libraries.

Answer 4

It is very difficult for you NOT to use CMSIS these days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.

People often talk about how buggy the ST libraries are and my experience with those claims suggest they are more of a user problem than a code problem. At least with thee "very buggy" SPL. The known problem there is the I²C code for some chips, most often unknown to many people, or known as a hardware problem.

Another example was in the unofficial release of SPL 3.5.

Most of user problems with SPL have been due to inability to understand how the code works and linking the code to the hardware.

I used OEM libraries often and have found them to be generally of very high quality, certainly better than most code produced by "experts".

So I would suggest that you plunge into it and see if it works for you. Overhead is fairly minimal. And if you structure your code right switching back to your own code from the library is easy.