Interdependence of LL and HAL => annoying => wish list

Nikita91 · ‎2020-04-12

I cannot use HAL because this library is not authorized by the company for the type of development I am doing. But I can use CMSIS and LL.

When I compile ***_ ll_.c files some include stm32h7_hal.c, which itself includes stm32h7xx_hal_conf.h. These files do not concern LL.

Could ST clearly separate LL and HAL, and not have LL dependence on HAL?

In addition stm32h7xx_hal_conf.h includes main.h. It is an application file which has nothing to do with LL or HAL, and which I do not need (RTOS with several tasks, no main). I am obliged to have a file with a single comment indicating that we do not need it ...

I'm not sure this is the right place to make this request, but I didn't find a 2020 wish list.

Thanks to ST.

MMAST.1 · ‎2020-04-22

Hello,

the LL layer is composed of two categories : LL standalone drivers (ADC, TIM, etc..) with primitive services and core drivers that are the common part or some complex "Functional" drivers like SDRAM, NAND, NOR respectively above the PCD, HCD, FSMC, FMC, USB peripherals, these core drivers, historically, came before the introduction of the LL primitive services. At the beginning, those core drivers were not supposed to be used directly by the end user but called internally by th functional drivers (PCD, HCD, NAND, NOR, SDRAM..etc) . Today through the different feedbacks pipes including this Forum, some users had expressed to use those core drivers without the HAL driver, thus we will remove the dependency of the core drivers with the HAL.

Keep tuned.

Rds

Maher

Nikita91 · ‎2020-04-23

Hello,

If the LL must evolve towards higher level services, I hope that the realization will be better done than for the HAL. See the lock / unlock which does nothing in the HAL, and which in reality prevents it from being used with an RTOS: This is a warning in the HAL files!

It is good news that the LL continues to exist and evolves (too bad for H7 the LL was available long after the HAL ...)

Pavel A. · ‎2020-04-23

> If the LL must evolve towards higher level services

This would defeat the purpose of LL. Especially,throwing locks there.

-- pa

Nikita91 · ‎2020-04-24

You are right. But I do not know the intentions of ST.

Pavel A. · ‎2020-04-24

> But I do not know the intentions of ST.

Try to guess... Sell more chips, with least expenses on software development and support ;)

-- pa

MMAST.1 · ‎2020-04-24

Hello,

I did not say that the LL will change the scope compared to today. only some core drivers (ll_***.c/h) that are used as common part for functional drivers will be updated to remove the dependency with the HAL to be used without the upper layer (HAL) as requested by some customers. the LL will remain the low layer tied to the hardware feature with primitive services.

Rds

Maher

berendi · ‎2020-04-24

What is the purpose of LL anyway?

Most functions are one-liners that set a single bit or a bitfield in a register. Compared with setting the register directly, the only difference is that looking up what a LL function does involves an extra step or two before one arrives at the description in the reference manual.

Piranha · ‎2020-04-25

Fewer but smart and competent software developers will be less expensive and will make usable software libraries, which will increase the sales of chips. The current big team of useless code monkeys cost them much more and have not been able to produce a useful and decent software libraries since the launch of STM32 back in a year 2007.

Nikita91 · ‎2020-04-26

Do not kill the profession of independent developers! It is easier to demonstrate to our boss that this code is dangerous and that we will do better and with better maintainability ourselves.

For us HAL are only examples, but too complicated.