L4 LL drivers

[Geoffrey1]

Posted on October 12, 2016 at 19:06

I'm confused about the development strategy.  Ideally, the Hal drivers should be layered on top of the LL drivers.  However, when I look at the code for say  gpio or spi, the Hal drivers duplicate the LL functionality -- but they use inconsistent names and data structures.  For example, each device has an init structure and function.  These are different for the Hal and LL is stupid ways -- like changes in structure order and field names that make no sense.  One gets the impression that these are written by two different teams who don't communicate with each other.

[Amel NASRI]

Posted on November 23, 2016 at 14:34

Hi brown.geoffrey.001,

To make it clear: The LL is a complementary library in the ST low level firmware offers on the STM32 that can be used in standalone mode without any resources from the HAL.The LL drivers are composed basically of two complementary parts when the LL is used in standalone (the elementary APIs in the ll.h files and the Init functions in the ll.c files). The LL - in standalone mode - offers all the features and similar APIs as the legacy Standard Peripheral Library.The LL unitary functions available in the ll.h can be used in standalone mode, and they will be integrated - in a second step - within the HAL taking care of common literals alignment when used by both HAL and LL.So, to conclude: in the current implementation of the Cube packages, the LL and HAL drivers cohabit in a complimentary rather than layered topology. -Mayla-

[Geoffrey1]

Posted on November 24, 2016 at 13:25Thanks for the reply.  Please, when you do the second integration step take care of the unnecessary inconsistencies.   Even when using the HAL code, there is still a need for the LL drivers.  Consider a simple bidirectional gpio pin (direction needs to switch under program control).  This is easy with the LL driver and a substantial pain with the HAL which only supports a complete reconfiguration.