which hardware timers are occupied by freertos?
Thanks!
ESP32: which hardware timers are occupied by freertos
-
- Posts: 75
- Joined: Fri Dec 04, 2020 9:56 pm
Re: ESP32: which hardware timers are occupied by freertos
None of them is "occupied" by FreeRTOS. Why would they need to take them from "users"?
Re: ESP32: which hardware timers are occupied by freertos
Generally, most operating systems have a "system tick" which requires an interrupt be generated at a regular interval. This usually requires some form of hardware timer be used to generate this system tick for the operating system.Victoria Nope wrote: None of them is "occupied" by FreeRTOS. Why would they need to take them from "users"?
On the ESP32, none of the hardware timers are occupied. This is because the Xtensa CPU core has an internal timer to generate an interrupt at regular intervals based on CCOUNT (the CPU's clock count). Therefore, no external timer is required to generate the system tick.kendo55 wrote: which hardware timers are occupied by freertos?
Thanks!
Re: ESP32: which hardware timers are occupied by freertos
Dear friends
many thanks for that good explanation
many thanks for that good explanation
Re: ESP32: which hardware timers are occupied by freertos
I am trying to familiarise myself with the FreeRTOS config via the 'idf.py menuconfig' tool.
When I navigate to "Component config > FreeRTOS > Port > Tick timer source (Xtensa Only)", I am presented with two options:
(X) Timer 0 (int 6, level 1)
( ) Timer 1 (int 15, level 3)
Apparently, I must have one or the other selected.
This gives the impression that indeed a hardware timer is reserved by the FreeRTOS. This seems to be in contradiction with the above replies.
If it is indeed possible to configure FreeRTOS so as not to occupy any hardware timers, please could you help me understand how to achieve this (ie. by only relying on the interrupt triggered by CCOUNT).
When I navigate to "Component config > FreeRTOS > Port > Tick timer source (Xtensa Only)", I am presented with two options:
(X) Timer 0 (int 6, level 1)
( ) Timer 1 (int 15, level 3)
Apparently, I must have one or the other selected.
This gives the impression that indeed a hardware timer is reserved by the FreeRTOS. This seems to be in contradiction with the above replies.
If it is indeed possible to configure FreeRTOS so as not to occupy any hardware timers, please could you help me understand how to achieve this (ie. by only relying on the interrupt triggered by CCOUNT).
-
- Posts: 1699
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: ESP32: which hardware timers are occupied by freertos
The SoC contains several timer components.
The TRM indicates that there are three CPU-internal timers (Timer.0-Timer.2), intended to be used for OSs' systicks & the like. These are separate from the "Timer Group" hardware timers (IDF: "General Purpose Timers"), which are external to the CPU, and are free for application code to use. Plus, there are watchdog timers and timers in other peripherals (LEDC, MCPWM,...)
AFAIK, the CPU-internal timers are not exposed to applications via IDF-API, and one of them must be selected for FreeRTOS's systick.
P.S.: You may want to look into the High Resolution Timer.
The TRM indicates that there are three CPU-internal timers (Timer.0-Timer.2), intended to be used for OSs' systicks & the like. These are separate from the "Timer Group" hardware timers (IDF: "General Purpose Timers"), which are external to the CPU, and are free for application code to use. Plus, there are watchdog timers and timers in other peripherals (LEDC, MCPWM,...)
AFAIK, the CPU-internal timers are not exposed to applications via IDF-API, and one of them must be selected for FreeRTOS's systick.
How would FreeRTOS provide vTaskDelay(...) or any other time-based functionality without underlying timer hardware?If it is indeed possible to configure FreeRTOS so as not to occupy any hardware timers...
P.S.: You may want to look into the High Resolution Timer.
Who is online
Users browsing this forum: Bing [Bot] and 130 guests