- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Labels:
-
PSoC 6 MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Rakshith M B
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.