Its been one hell of a while since I posted a tutorial so I thought I’d throw one of up for this. I’ve not had much time to do much electronics as of late (it is now my job…) but hopefully once I move into a new area, I’ll have a little more free time and motivation to do electronics outside of work.
ST have recently acquired Atollic, an IDE developer who have designed an embedded IDE based on Eclipse. I’ve previously been a massive fan of CooCox and the ST Peripheral library but unfortunately, this is swiftly becoming antiquated and unless I move with the times, I’m going to be left behind with the retro STM32s.
I’ve therefore decided to find the best way to move forward. There are a couple of options available to developers on STM32 platforms, I could use STM32CubeMX with SW4STM32 though this is my least favourite option. Although SW4STM32 is based on Eclipse, it seems a little buggy (I can’t get main.c variables to work in debug mode…) and I truly despise STM32CubeMX so this wasn’t a particularly nice option. Once I found out that ST offered Atollic for free, I jumped on the opportunity to get involved with this new IDE. After a bit more reading, I found out that ST offered a low level peripheral library, similar to the standard peripheral library so given my distaste for the HAL, I decided to give this a shot.
One thing I like about the LL library is that it is essentially the STDPeriph library with a few different names and definitions so its not particularly hard to adjust to.
This tutorial assumes Atollic has been installed and a workspace has been generated!
Sadly, generating an LL project isn’t quite as simple as a STDPeriph project was in CooCox but this seems to have worked fine. The first requirement is to download the drivers for your chip. As this is for the STM32F0, I will be downloading the STM32F0Cube Drivers.
Download chip driver
It is best to then unzip this folder to a location it won’t be moved or deleted. I chose my workspace location for this.
Unzip cube folder to a constant location
Once the drivers have been unzipped to a specific location, a new project can now be generated within Atollic!
Within Atollic, create a new C project
Menu option to create a new C project
The next few steps involve following the process. All that is required is selecting the STM32 microcontroller you’ll be using – in this case, I’ve chosen the STM32F051R8, the chip used on my STM32F0 Discovery board. It’s also important to select the debug probe which should be the standard ST Link.
Once the project has been created, a main file should open and this entire project should compile just fine. This can be clarified by building the project.
Building the project
If no other libraries are going to be used (i.e. Std peripheral, HAL or LL), this is all that is required for a basic project.
Including the LL files
To include the LL files, the project source and include paths need to be set. This is a relatively easy process to do and can be done in the project properties. Right click the project and navigate to “Properties”, this should cause a new window to popup.
Navigate to project properties
Within this new window, you will want to navigate to “C/C++ General” then “Paths and Symbols”
Navigate to Paths and Symbols
Within here, you will then want to add the path to your LL library files. Click “Add” then “File System…” and navigate to the location of your LL driver inc folder. Finally, click OK on both windows.
Add inc folder location
You should now see that the include location has been added.
Adding include location
Now that the include folder has been added, the location of the source folders will need to be added. For this, navigate to the “Source Location” tab. In this tab, click “Link Folder”. Once the Link Folder window opens, click the check box “Link to folder in file system”. After this has been checked, you should be able to browse for your LL source folder.
Add source folder location
You will also need to give this folder a name other than “Src” once you’ve selected it. I normally call it “SrcLL”. Click OK to return to the Paths and Symbols window.
The final step of project properties is to add the “USE_FULL_LL_DRIVER” definition. Navigate to “Symbols” and click “Add”. Paste in the above define and click “Ok”.
Add LL definition
Exit the settings by clicking “Ok”. A message will popup saying something about rebuilding. Clicking “Yes” to this is fine.
You will now find that it no longer compiles (wahoo)! It seems to flag up a few errors with type names on the HAL.
I don’t really know the best way to handle this so I took the lazy option of going into my firmware folder and deleting all of the HAL files leaving only the LL files. This probably isn’t the best way to handle it but hey, it works. After deleting the HAL files, this should compile fine.
Using the LL library
As much as I love ST, I don’t seem to have much luck with their libraries. I’m probably going to blame it on my inexperience as you wouldn’t expect a multibillion dollar company to release dodgy libraries right?
Unfortunately, once you try and include the GPIO LL library, a couple of errors get flagged. It seems to have issue with the definition of “GPIO_AFRL_AFSEL0”. I’ve checked the header file for this chip and this file doesn’t seem to exist so I decided to modify the “stm32f0xx_ll_gpio.h” file to allow for the correct definition. Firstly, the file needs to have its read only attribute cleared. Right click on the file, go to “Properties” and untick Read Only.
Clear read only attribute
Once this has been done, the file can be edited. Inside your favourite editor, replace “GPIO_AFRL_AFSEL0” with “GPIO_AFRL_AFRL0”, next replace “GPIO_AFRH_AFSEL8” for “GPIO_AFRH_AFRH0”. I don’t know if this is a type or what but this fixes the issue. From what I gather, this could potentially only be an issue for version 1.9.0 of the HAL library. Other versions may differ. I also found issue with “stm32f0xx_ll_rtc.h” where “RTC_CR_BKP” needed to be replaced by “RTC_CR_BCK”.
After these minor changes, including “stm32f0xx_ll_gpio.h” and “stm32f0xx_ll_rtc.h” should allow for successful compilation. A simple program can then be written to ensure the GPIO is working successfully.
GPIO Test program
Using the above program should cause the blue LED on board the STM32F0 Discovery to flash at a rate of 1Hz! Obviously this requires a bit more code than the standard peripheral library but if you compare this to a standard peripheral example, the code is pretty similar.
And voila! Those are the steps required to create a new project with Atollic TrueSTUDIO for an STM32 processor using the LL library offered by ST. I don’t know of any other potentially errors present in their library so if anyone comes across any further ones, please comment here.