Skip to main content
migmel
migmel
Associate III
October 4, 2022
Solved

How to avoid HAL_Init() when using a timer other than Systick

  • October 4, 2022
  • 4 replies
  • 3601 views

Hello guys,

First of all I want to say that I don't like and don't use HAL library. Use LL_Library instead as long as possible.

Now what brings me here is that currently I am manually porting FreeRTOS to an STM32469NI MCU. This force me to use a different time base other than the Systick. I have realized that when using another timebase source ( example TIM1), STM32Cube MX autogenerated code always includes and initialize the HAL library in main

My question: is there a workaround to get rid of the HAL library in this case and work exclusively with LL?

Any help or suggestion would be greatly appreciated

This topic has been closed for replies.
Best answer by Pavel A.

>  I am manually porting FreeRTOS to an STM32469NI MCU

A bit late? ST already offers the FreeRTOS adapted for STM32F4 in their "Cube MCU" package and as a separate repo on their github.

> My question: is there a workaround to get rid of the HAL library in this case and work exclusively with LL?

Of course, yes. Throw away the generated code and roll your own. It's all available in source.

By the way some people here dislike LL as well, saying that it does not provide enough value compared to pure register accesses, and adds yet another layer of obscurity. Up to your taste.

4 replies

Pavel A.
Pavel A.Answer
Super User
October 4, 2022

>  I am manually porting FreeRTOS to an STM32469NI MCU

A bit late? ST already offers the FreeRTOS adapted for STM32F4 in their "Cube MCU" package and as a separate repo on their github.

> My question: is there a workaround to get rid of the HAL library in this case and work exclusively with LL?

Of course, yes. Throw away the generated code and roll your own. It's all available in source.

By the way some people here dislike LL as well, saying that it does not provide enough value compared to pure register accesses, and adds yet another layer of obscurity. Up to your taste.

Jaroslav JANOS
Jaroslav JANOS
ST Employee
October 4, 2022

Hello migmel,

just to add, in the CubeMX->Project Manager->Advanced Settings tab you can choose which libraries you want to use. If you choose LL for all peripherals as well as TIM1, HAL won't be included

BR,

Jaroslav

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
migmel
migmelAuthor
Associate III
October 4, 2022

Right, that is how it is done. However, when you choose TIM1 as timebase source, then TIM1 option is not available to choose the library in advanced settings tab

Jaroslav JANOS
Jaroslav JANOS
ST Employee
October 4, 2022

Yeah, I can see it now, you are right. Sorry for the confusion. Still, you can rewrite it as Pavel A. suggested...

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
Piranha
Piranha
Principal III
October 5, 2022

FreeRTOS is already ported to all Cortex-M cores for the popular compilers. What are you porting there? Just take it and use it!

And why SysTick timer cannot be used for system ticks?

migmel
migmelAuthor
Associate III
October 5, 2022

Probably it was not clear. I talked about FreeRTOS just to give a context but its actually irrelevant.

The question was about CubeIDE and how to make it generate pure LL code.

I know CMSIS FreeRTOS is already ported to most of MCUs and is available. Yes, I have taken it, but out of my curiosity I want to do it specially because native FreeRTOS is not provided with Cube.

About the Systick, is a high recommendation from STMCube to use a different timebase source

Piranha
Piranha
Principal III
October 5, 2022

> I know CMSIS FreeRTOS is already ported to most of MCUs and is available.

FreeRTOS is ported by it's developers to Cortex-M4 CPU core and it doesn't need any porting to specific MCUs. Now, you are actually talking about CMSIS-RTOS wrapper for it, which you didn't mention initially.

> native FreeRTOS is not provided with Cube

The fact that CubeMX adds CMSIS-RTOS wrapper doesn't forbid using FreeRTOS native API. So you don't use HAL because you want to write your own code, but you still need CubeMX. For what? For adding a useless RTOS wrapper that just adds another layer of bloat and limits the possibilities?

> About the Systick, is a high recommendation from STMCube to use a different timebase source

0690X00000AQoKNQA1.png"When RTOS is used, it is strongly recommended to use a HAL timebase source other than the Systick. The HAL timebase source can be changed from the Pinout tab under SYS"

Did you even read what it says? It recommends using other timer for HAL timebase, not for FreeRTOS. They do this because their flawed HAL junk uses timeouts in functions, which can be called from ISRs. Because of that HAL timebase interrupt must be set to the highest priority, but FreeRTOS's tick interrupt must not be higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY and is recommended to be set to the lowest priority. If one doesn't use HAL junk, then all of that idiocracy is not relevant.

migmel
migmelAuthor
Associate III
October 6, 2022

I don't use HAL because I don't like it. I'm just a learner not an expert, otherwise wouldn't be using CubeMX. Can't initialize all peripherals by heart using LL

Now I realize that using the Systick as usual works normal with FreeRTOS at least as long as no low power modes are used. Have to test what would happen if using low power modes

Terms & ConditionsAccessibility statement