How exactly is the HAL RTOS_AWARE?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Panometric
Level 5
Level 5
100 sign-ins 100 replies posted 10 solutions authored

The HAL Overview page says:

"Some HAL driver's may have slightly different behavior when run in an RTOS environment. This is typically found in operations that need to wait for a significant period of time. In an RTOS aware environment, the function will attempt to wait using the RTOS." .. "To inform the HAL that an RTOS environment is being used the RTOS_AWARE component (COMPONENTS+=RTOS_AWARE) or the CY_RTOS_AWARE define (DEFINES+=CY_RTOS_AWARE) must be set. When set, the HAL will use the RTOS Abstraction APIs to wait."

Wanting to understand this more specifically, I looked for how it was implemented. But I only find a definition of a delay function, and not many usages of it. 

https://github.com/Infineon/mtb-hal-cat1/search?q=CY_RTOS_AWARE

Did the roadmap make it to the documentation before the code?

I am more concerned with freeing the CPU gracefully for I2C, SPI, and I2S operations. But in cyhal_spi.c I see concerning time sinks like 

 

 while (Cy_SCB_SPI_IsTxComplete(obj->base) == false) { }

 

Is it even advisable to use HAL functions with an RTOS and tickless idle if we are concerned about power consumption?

 

 

0 Likes
1 Solution
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

Hi @Panometric ,

For the function you specifically pointed out, the time it takes to unload/load one word from the SPI FIFO is extremely small, specially if you are clocking your SPI at higher frequencies. 

The time it takes to simply switch the context on the RTOS will be higher than simply wait for a few cycles to get the FIFO cleared. So it justifies to use the while loop there.

If you use the cyhal_spi_transfer_async, that's another story. In this case you can see it uses the internal interrupt to manage the transfer, without any while loops.

UPDATED:

The cyhal_spi_transfer() function is indeed not using RTOS abstraction. We will file an internal ticket to get this fixed. 

View solution in original post

3 Replies
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi @Panometric

RTOS Abstraction layer in the context of peripherals mainly deals with resource allocation and delays. It just calls the RTOS delay function when the HAL delay function is called instead of blocking the CPU. It should not have an impact on the power consumption as long as you ensure that the device is successfully entering the low power mode. 

Thanks and Regards,
Rakshith M B
0 Likes
Panometric
Level 5
Level 5
100 sign-ins 100 replies posted 10 solutions authored

@Rakshith  you said"It just calls the RTOS delay function when the HAL delay function is called instead of blocking the CPU." But in https://github.com/Infineon/mtb-hal-cat1/blob/f468ebe53b8df9485e32ac8cd18d9225280ae415/COMPONENT_PSO... it is blocking the CPU. This leads me to think the HAL is not well adapted to being used with an RTOS yet.  Is there an ongoing effort to improve this?

0 Likes
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

Hi @Panometric ,

For the function you specifically pointed out, the time it takes to unload/load one word from the SPI FIFO is extremely small, specially if you are clocking your SPI at higher frequencies. 

The time it takes to simply switch the context on the RTOS will be higher than simply wait for a few cycles to get the FIFO cleared. So it justifies to use the while loop there.

If you use the cyhal_spi_transfer_async, that's another story. In this case you can see it uses the internal interrupt to manage the transfer, without any while loops.

UPDATED:

The cyhal_spi_transfer() function is indeed not using RTOS abstraction. We will file an internal ticket to get this fixed.