LED MCU Peripheral Control by Hardware

Abstraction Layer (HAL) using STM32Cube-MX

and IAR Embedded Workbench
Microcontroller Programming Basics

Baynosa, Bruce Alan

Department of Electrical and Electronics Engineering
University of San Carlos – Talamban Campus
Nasipit, Talamban, Cebu City, Cebu, Philippines
bruce.baynosa15@gmail.com

Abstract—The experiment primarily aims to demonstrate the
use of Hardware Abstraction Layer (HAL) approach in
programming microcontroller units (MCU’s) and compare it to
the Cortex Microcontroller Software Interface Standard (CMSIS)
approach. The methodology of the experiment mainly revolves
around blinking the LED peripheral of the MCU using HAL
approach. Blinking rate of the LED was measured with its
corresponding delay time. The relationship between both
parameters was determined through analyzing its graph. It was
observed from the data measured and calculated that blinking
rate is directly proportional to the proportionality constant k and
inversely proportional to the delay time. In addition,
proportionality constant k from both parameters must be
determined in order to predict the behavior of the LED with each
corresponding delay time increment. It was concluded that HAL-
based programming approach provides ease in programming
instructions to the microcontroller as it generally requires lesser
coding compared to that of CMSIS. Furthermore,
STM32CubeMX graphical tool provides a wide-variety of
functions in configure MCU peripherals as well as generating a C
code from the settings which would then be used in the IAR
Embedded Workbench.
Keywords— embedded systems, STM32CubeMX, HAL, CMSIS,
delay time, blinking rate
I. INTRODUCTION
It is the objective of the experiment to: (a) demonstrate the
use of STM32CubeMX, (b) demonstrate the Hardware
Abstraction Layer (HAL) approach to programming, and (c) to
explain analytically the HAL and CMSIS approaches.
Microcontroller (also known as MCU) programming
generally involves writing a set of instructions either in C
language or any other high-level programming language and
having these program code and data compiled into a machine-
level language which is in binary form – ones and zeroes. It is a
necessity that in writing a program on a specific language, the
programmer must have sufficient knowledge on the hardware to
which the program gets uploaded into. The MCU component
that is responsible for interpreting the instructions uploaded is
the Central Processing Unit (CPU).
A microcontroller’s CPU reads the program code from
memory one at a time and each instruction gets decoded. These
binary codes would tell the CPU on what to do, as it performs
operations on the data values. The CPU reads instruction codes
from a memory sequentially, which are from sequential memory
addresses, unless instructed to jump or skip a code. For example,
if the instruction memory starts at address 0000, then the CPU
would read and execute the instruction stored at this specific
address [1]. It would be assumed that the processing will
continue to execute codes from addresses 0001, 0002, 0003, and
so on, unless instructed otherwise. It is then generalized that
there is a sequence of operations being strictly followed when
programming a series of machine-language instructions. As
numerous complex instructions from programs already gets
relayed to the MCU, the emergence of embedded systems would
come into use.
An embedded system is a combination of both hardware and
software, which is programmable and designed to perform a
specific function or specific functions within a larger system [2].
Embedded software systems primarily use operating systems or
language platforms that are adapted for real-time operation in
environments that require higher levels of chip capability. While
CMSIS (Cortex Microcontroller Software Interface Standard) is
commonly used as software system for embedded applications,
another approach used in programming embedded systems is the
Hardware Abstraction Layer (HAL).
Hardware Abstraction Layer is a programming approach that
interacts a microcontroller hardware at a level that is general and
abstract rather than detailed through the use of a computer’s
operating system [3]. Long before this approach was introduced,
MCU programmers need to know the physical interface of each
microcontroller hardware before assigning instructions to it.
This would lend them extensive time to write a compatible
software to the specific MCU. Through the use of HAL
approach, programmers would use functions to make a hardware
do something without having to know the detailed knowledge of
how the hardware is doing it. Figure 1 below shows the
schematic of microcontroller programming through the aid of
HAL.
Fig. 1. Microcontroller programming using HAL. Image taken from [4].

Switching to other microcontrollers or operating systems

during development is easier with HAL since an independent
code (as shown in the figure) is only required if ever there is an
application or hardware change. In addition to that, integrating
tests and simulations in different MCU’s is more convenient
since program development will speed up [4]. In order to utilize Fig. 2. STM32L0538T6 MCU pin locations. Image from [5].
HAL, a graphical tool is essential to configure MCU’s easily and
an example of this software utility is the STM32 Cube-MX.
STM32 Cube-MX is specifically made for STM32, an
ARM-based family of microcontrollers, allowing ease in
programming as well as generating and initializing its
corresponding C code to different IDE’s. The user would just
select the STM32 microcontroller and configure its peripherals
as essential features are incorporated such as MCU peripheral
utility, pin-out conflict solver, clock-tree setting helper, and a
power consumption calculator [5]. HAL is included as an
embedded software, represented as STM32Cube HAL, that
ensures maximized portability across STM32 portfolios.
II. METHODOLOGY
A new project was created in the STM32CubeMX graphical
software configuration tool and the MCU to be used,
STM32L0538T6, was selected. MCU pins were configured as Fig. 3. STM32L0538T6 MCU clock configuration. Image taken from [5].
PA5 pin was chosen since it is connected to the built-in LED.
GPIO_Output was the function selected in the configured pin
since the methodology of the experiment revolves around
blinking the built-in LED. Figure 2 indicates the pin locations of
the microcontroller unit used.
Clock speed in the MCU was also configured according to
what is shown in Figure 3.
GPIO (General Purpose Input Output) was set after the pin
and MCU clock were configured. The function was set as shown Fig. 4. PA5 (GPIO) configuration. Image taken from [5].
in Figure 4.
It was instructed that a series of lines be inserted into the
After configuring the necessary settings in the MCU, a C main code. Figure 6 shows that lines to be inserted in order to
code was generated which will be used for programming the complete the code.
hardware in IAR Embedded Workbench. The generated code
was located inside the main.c file from the user folder. It was Toggling the PA5 (connected to the built-in LED) is in the
observed from the file that that codes shown were HAL-based first line of the sub-code. The delay time setting (in ms) for the
which were automatically generated by the STM32CubeMX. blinking the LED is located in the second line of the sub-code.
Figure 5 indicates the generated HAL-based code in the IAR The code was compiled after being finalized. As no errors was
Embedded Workbench. shown, the code was debugged and uploaded to the STM32
Nucleo-64 board connected.
 Fig. 7. Plot of relationship between delay time and blinking rate
Fig. 5. Generated HAL-based code in the IAR Embedded Workbench. Image
taken from [5].
The graph based from the values measured and computed in
the experiment was plotted as shown in Figure 7.
It is shown in Figure 7 that blinking rate is directly
proportional to the proportionality constant and inversely
proportional to the delay time. The relationship can be expressed
using the equation as follows:
𝑘
𝑦= (1)
𝑥
Fig. 6. Lines to be inserted in the main code. Image taken from [5].
From (1), the proportionality constant is calculated as
The value for the HAL_delay function was varied. The recorded in Table 1.
blinking rate for each HAL_delay setting was measured and
Although CMSIS and HAL are two different MCU
recorded in a table. Proportionality constant k was determined
programming approaches, it can be generalized that they both
with each data point. Data in the table was plotted for further
yield the same relationship between the delay time and the LED
analysis and the graph was compared to the curve when CMSIS
blinking rate. As both approaches are relatively independent of
was used.
hardware, HAL has more built-in functions compared to that of
III. DATA PRESENTATION, DISCUSSION, AND ANALYSIS CMSIS.
The relationship between the HAL_delay function and the IV. CONCLUSION
blinking rate of the LED was determined. Table 1 below
Through the use of STM32CubeMX, configuring the
indicates the blinking rate measured with each delay setting and
peripherals of the microcontroller unit as well as generating its
its respective proportionality constant k.
corresponding C code from the settings done is much easier.
TABLE I. DELAY TIME SETTING WITH ITS CORRESPONDING LED
Since the graphical tool includes Hardware Abstraction Layer
BLINKING RATE among its libraries, one does input instructions easily to the
hardware without actually knowing how the hardware does the
Delay Time (in ms) LED Blinking Rate Proportionality
(in blinks/min) Constant (k)
command. In addition, HAL approach is a lot similar to CMSIS
250 122 30.50 approach as both methods involves hardware-independent
500 61 30.50 coding, although, HAL has its slight advantage as it has more
750 41 30.75 built-in functions to be utilized compared to that of CMSIS.
1000 31 31.00
1250 23 28.75 REFERENCES
1500 20 30.00 [1] "Tutorial: Microcontrollers-Programming Language/Software
1750 17 29.75 Development Environment, Renesas Engineer School", Renesas
2000 15 30.00 Electronics America, 2017. [Online]. Available:
https://www.renesas.com/en-us/support/technical-resources/engineer-
school/mcu-03-software-development-environment.html. [Accessed: 17-
The average proportionality constant kave was computed as Dec- 2017].
follows: [2] M. Rouse, "What is embedded system? - Definition from
WhatIs.com", IoT Agenda, 2017. [Online]. Available:
∑ 𝑘 241.25 http://internetofthingsagenda.techtarget.com/definition/embedded-
𝑘𝑎𝑣𝑒 = = = 𝟑𝟎. 𝟏𝟔 system. [Accessed: 17- Dec- 2017].
𝑛 8
[3] M. Rouse, "What is hardware abstraction layer (HAL)? - Definition from
The proportionality constant was calculated in order to WhatIs.com", WhatIs.com, 2017. [Online]. Available:
predict the LED blinking rate with each succeeding increment http://whatis.techtarget.com/definition/hardware-abstraction-layer-HAL.
of the delay time. [Accessed: 17- Dec- 2017].
[4] L. Krzak, Hardware abstraction layer for microcontrollers. Krakow, 2017, [5] "STM32Cube", Emcu.it, 2017. [Online]. Available:
pp. 33-35. http://www.emcu.it/STM32Cube/STM32Cube.html. [Accessed: 17-
Dec- 2017].
[6] M. A. Cabilo, “Blinking the LED … Again,” unpublished.