HAL vs LL

[Lukasz Przenioslo]

Posted on November 13, 2016 at 17:00

Hello there,

I was getting quite used to HAL for about a year now. Then I was trying to find out something about modbus mode in STMF0 and I find this ''Low Level API''. I cant seem to find any of its functionality in my current CubeMx generated code for F0 (CubeMx version 4.16.0). I see that I can download a new package for F4 and a new version of CubeMx 4.17.0. Would that bring the LL functionality? Also, if yes, would it affect my project that are written in HAL so far?

I would appreciate all hel regarding this issue.

[Walid FTITI_O]

Posted on November 14, 2016 at 11:17

Hi Bremen,

The Low Layer (LL) drivers are designed to offer a fast light-weight expert-oriented layer which is closer to the hardware than the HAL. Contrary to the HAL, LL APIs are not provided for peripherals where optimized access is not a key feature, or those requiring heavy software configuration and/or complex upper-level stack (such USB).

The HAL and LL drivers are complementary and cover a wide range of applications requirements:

• The HAL offers high-level and feature-oriented APIs, with a high-portability level. They hide the MCU and peripheral complexity to end-user.

• The LL offers low-level APIs at registers level, with better optimization but less portability. They require deep knowledge of the MCU and peripherals specifications

The LL drivers feature:

• A set of functions to initialize peripheral main features according to the parameters specified in data structures

• A set of functions used to fill initialization data structures with the reset values of each field

• Functions to perform peripheral de-initialization (peripheral registers restored to their default values)

• A set of inline functions for direct and atomic register access

• Full independence from HAL since LL drivers can be used either in standalone mode (without HAL drivers) or in mixed mode (with HAL drivers)

·

Full coverage of the supported peripheral features.

The Low Layer drivers provide hardware services based on the available features of the STM32 peripherals. These services reflect exactly the hardware capabilities and provide one-shot operations that must be called following the programming model described in the microcontroller line reference manual. As a result, the LL services do not implement any processing and do not require any additional memory resources to save their states, counter or data pointers: all the operations are performed by changing the associated peripheral registers content.

So, as a response to your question, the LL drivers can be added by user when he want to in order to perform particular direct register access that can’t be done by HAL library. Otherwise, you HAL code and STM32CubeMX generated code still always working .

The STM32CubeMX tool,

starting from 4.17.0 STM32L4 series

, become capable to generate peripheral initialization code based either on the peripheral HAL driver or on the peripheral Low Layer (LL) driver. Now. 

Other STM32 devices will be supported in coming CubeMx version including the STM32F0.

To see more about Low layer drivers on STM32F0 , refer to the User Manual

http://www.st.com/content/ccc/resource/technical/document/user_manual/2f/77/25/0f/5c/38/48/80/DM00122015.pdf/files/DM00122015.pdf/jcr:content/translations/en.DM00122015.pdf

'' Description of STM32F0xx HAL and Low-layer drivers''

-Hannibal-

[Lukasz Przenioslo]

Posted on November 14, 2016 at 11:36

Thank you for the in depth explanation. So If I understand corretly only L4 devices are supported by LL for now? How about this situation- I have a CubeMx generated project for F4 device that is under development for a while now. If one day LL support will come for F4, what will happen if I update the CubeMx and it will generate LL supported code in the place of my HAL only old code. What will happen, the code would have to be rewritten?

[Jaroslav BECKA]

Posted on December 20, 2016 at 16:05

At the moment the CubeMX supports project generation only for STM32L4 devices, but the LL drivers are available for more devices such as L0, L1, F0...  The drivers can be found in corresponding STM32Cube FW package. This means you can create a project for STM32L0 device based on LL layers, but you would have to do it from scratch without the CubeMX support. 

[Alan Chambers]

Posted on November 15, 2016 at 10:35

If I've understood this correctly, the HAL and LL libraries are not related, but completely independent, and each resting directly on the hardware. It's just that the HAL implements a bunch of useful driver abstractions to make common applications more accessible, and the LL doesn't. Is that the case? But of course you can use the LL to implement drivers, as with the Standard Peripheral Library, but you have to know what you are doing.

[Lukasz Przenioslo]

Posted on November 15, 2016 at 10:44

This is the case: I got some code written in HAL (a lot). Now I can update MXcube for my core to a version supporting LL. I regenerate the code using mxCube. Will my code stop working because the new version of HAL/LL is not compatible with the old only HAL version? For example, some functionalities were moved from HAL to LL and etc?

[Bogdan Golab]

Posted on January 08, 2018 at 09:36

I often try to move to LL piece by piece - i.e. I enable for example HAL for GPIO and try to convert some of my app to LL drivers ( I mean this part not automatically generated by CubeMX). Then I enable another part for LL in the Cube.

CybeMX allows to enable drivers for particular pheripheral but often you need add more code e.g. in the HAL code the systick is automatically enabled whereas in LL code you need to enable it manually. Of course you need spend time on dirty details (datasheet).

[Seb]

Posted on December 16, 2016 at 21:39

Without knowing the project, coexisting HAL and LL in a project should be possible as long as both are not used together on the same peripheral...

[Diego Colombo]

I just changed from Hal to LL right now,using LPUART1.In this project i have to take care of code size.

My print routine on LPUART1 is minimal,only for debugging purpose done by myself at register level,so the libraries are for initialization only and the printing function remains unchanged:

void MyPrint(char* str_to_print)

{

while(*str_to_print)

{

LPUART1->TDR=*str_to_print++;

while(!(LPUART1->ISR & USART_ISR_TC_Msk ));

LPUART1->ICR |=USART_ICR_TCCF_Msk;

}

}

The code size reduction using GPIO and LPUART LL instead of HAL is as following:

// 8040  368  1720 10128  2790 //HAL

// 3896  368  1584  5848  16d8 //LL

the main difference is that CubeMx ,with same settings, except HAL or LL selection,in case of LL does not provide the activation of LPUART1 that i had to add by myself turning high LPUART1->CR1 :bit 0

[Tesla DeLorean]

Please wait on TXE before outputting data, don't wait for TC, it is the least efficient method. This will be especially true on STM32 supporting a USART FIFO

[Diego Colombo]

Thanks Clive,i think you are right.

I'm used to wait for the transmission complete because of some microcontrollers SPI,where i have to raise a GPIO used as chip select:in such cases i have to wait for all the bit banged out from the pins,and not only for the buffer empty.

In the case of LPUART1 used as i need i admit that i'm just wasting time, waiting for the hardware doing its job.

Thanks for your hint

Diego

[S.Ma]

Overall, HAL for a start and LL when optimisation becomes important.

LL for USART is for me the first step taken.

[Khalilfayache]

the difference between LL and HAL