There is an unending dispute about which library should you use when writing an application for STM32 microcontroller. Actually, there are at least three choices which you should consider. In this post I will highlight the advantages and disadvantages of each approach which can be considered when writing software for ST microcontrollers.
CMSIS stands for Cortex Microcontroller Software Interface Standard. CMSIS is a hardware abstraction layer for Cortex-M devices. It is common interface across different vendors which is good because it is a standard when Cortex-M devices are being considered. It means that you don’t have to worry about the compatibility issues. However, talking to the peripherals like SPI is completely different case because CMSIS handles only the basics, excluding mentioned peripherals. Communication with MCU peripherals requires a direct registry manipulation. This solution is error prone if you don’t know what you are doing. For example you can misunderstand the documentation in some cases and wonder why something is not working, it happens very rarely but still. If you get it right you will probably get the best code and the most efficient piece of software. This is not recommended for beginners who just started their adventure with microcontrollers programming.
The compatibility across different microcontrollers is, however, different issue. The code which you have written will only work on a specific target device. Sometimes it can be ported to a different device but from the same family line. Using this approach you won’t avoid adjustments.
SPL stands for Standard Peripheral Library. It is a set of libraries created by ST company which in theory should make programmers life easier. In practice you end up with two things. First of all, you have to learn how to use the library. Fortunately, the company published a lot of examples on which you can learn but close to zero useful documentation. The other thing, however, is that you also need to learn a bit about the ST microcontrollers; there is no shortcut. In the end you don’t only have to teach yourself how to use the library itself but also you have to know the architecture of the MCU which you are going to use. In conclusion, you have to do the same work twice which is terribly inefficient.
Where is the advantage of this approach? It’s quite obvious. Using SPL makes life easier. Your code is, more or less, portable and you don’t have to know the nuances. In either case, it is better to know them. The biggest disadvantages is the library itself because of two reasons. You don’t know if it is buggy. There is plenty of talk about this and it is not in favour of the SPL. Also let’s say that you want to make something more complex, like two or three peripherals depending on each other, if the SPL wasn’t prepared for this you end up exactly where you were before. You have to write your own code which operates on MCU registers. Going this way, it gets the job done but if you were dreaming about any kind of portability of your code, now you can forget about it completely.
Also, it is very recent situation which has cover in real life, the ST company decided to discontinue the development of this piece of software. This is the case, ST decided to make a new library called HAL. It is described below.
HAL is an abbreviation for Hardware Abstraction Layer. In comparison to the SPL it has a lot of new features. Not only it was rebuild from the ground up but also there is a new tool which should make your life easier – STM32CubeMX.
Let’s focus on the library itself. When analysing the library and its code you can be under impression that the names of functions, variables etc. were changed and everything else stayed the same. Actually, a lot has been changed and improved. One big advantage is that you can reuse your code between different chip families based on Cortex-M core from this vendor. ST delivers a set of libraries which have identical API (in majority of cases), and the only thing that you have to do, to run the code on a different MCU, is to switch a set of libraries which shouldn’t be painful; and recompile your code. Sounds fantastic but, like with everything else, only to a certain point.
At the beginning, I mentioned the STM32CubeMx. It is an outstanding piece of software, only it has been introduced to the market a few years too late. If you are familiar with Code Expert from Motorola, now Freescale, the STM32CubeMx is more or less the same. The STM32CubeMx is a tool which allows you to:
- Select a chip in which you are interested in by many different criteria,
- Select peripherals which you would like to use and configure them,
- Configure clocks by filling up gaps/changing values in diagram,
- Configure internal peripherals,
- Do some profiling for power consumption based on designed chip activity,
- And the last but not the lest, to automatically generate C code for your project.
Still this tool requires a lot of work and there is still room for some improvement.
So why not to use HAL along with STM32CubeMx if it is so versatile. There is still a risk when ST becomes bored with the HAL, however unlikely it may seem, it can happen and then they simply discontinue this project. The HAL library can meet the same fate as SPL did.
The HAL library is not only library for the internal peripherals. It also allows you to configure FreeRTOS, FatFS and along with it SD card support. Let’s look more closely on the FreeRTOS support. ST created a set of wrappers and called it a new OS which actually runs FreeRTOS under the hood. But still you can use native FreeRTOS 🙂
Also there are some other libraries dedicated to the specific core or even a family of devices. One of them is a set of libraries created by Tilen Majerle. It was build upon the HAL library. Furthermore, it is not only a set of libraries with wrappers but also a set of drivers for external devices like LCD, DS18B20, and a few others. It is definitely worth to have a look on this one.
Also there are proprietary libraries which come with a whole IDE like CrossWorks for ARM from Rowley.
To sum, there is a whole variety of IDEs and libraries. Some have more pros then others. What is the most important factor which you have to keep in mind, however, is if the library you are going to use suddenly could be discontinued. But still, it is not a very big problem if you separate hardware layer from your logic layer. Then you can relatively easily switch from one to another.
There was published a second part about SPL, HAL, and LL frameworks.