vTaskDelay issue bit me

[fly135]

I call vTaskDelay for various reasons. One is to wait for a period after resetting a chip (BME280). I had an issue with the chip delivering bad calibration data. The sdk for the chip needed 2msec. Turned out that vTaskDelay(2/portTICK_PERIOD_MS) wasn't waiting long enough. After looking in the IDF I see that portTICK_PERIOD_MS is 10. So that means any msec delay < 10 is zero.

I posting this in case I got something wrong in my analysis. But also in case anyone uses vTaskDelay and doesn't realize that is won't work with lower than 10 msec delays unless you test for a result of zero in the division and make sure you at least pass a 1 to vTaskDelay.

John A

[urbanze]

Delay with RTOS methods is limited to FreeRTOS frequency, if freq. is 100Hz, minimum delay is 10ms and if 1000Hz (maximum freq), minimum delay is 1ms.

Check in menuconfig if rtos frequency is >=500Hz to get 2ms delay

[chegewara]

vTaskDelay is delaying by ticks number, not by ms. Like urbaze said, portTICK_PERIOD_MS is a macro to convert ms to ticks depend on Tick rate set in menuconfig.

[fly135]

Yes, I see now that you can change the tick rate. I don't need delay resolution below 10msec and suspect that upping the rate will have some impact on overall performance. I'm also try to make sense of the information returned by vTaskGetRunTimeStats. I'm printing the task scheduler uptime from TaskGetTickCount() against the total time for each task. It's appears that the percentages for each task are divided in half so that each idle task is 50%, but when looking at the code I'm not seeing how that is happening.

ulStatsAsPercentage = pxTaskStatusArray[ x ].ulRunTimeCounter / ulTotalTime

The ulRunTimeCounter for the idle task is close to equal to the uptime from TaskGetTickCount, but prints as approx 50%.

sprintf( pcWriteBuffer, "\t%lu\t\t%lu%%\r\n", pxTaskStatusArray[ x ].ulRunTimeCounter, ulStatsAsPercentage );

[chegewara]

With higher tick rate value you will have bigger overhead because of more often task switching by scheduler.

[chegewara]

EDIT i think i messed something between app flashes

[fly135]

That's weird. I'm using V3.1 Release. Was under the impression that delay was in ticks. Maybe I should check that.

[fly135]

I'm using v3.1 release. I put a loop in the beginning of my program calling vTaskDelay(100) and printing the time. I am getting the correct delay of 1000msec (1 sec).

Code: Select all

t:1 msec
t:1000 msec
t:2000 msec
t:3000 msec
t:4000 msec
t:5000 msec
t:6000 msec
t:7000 msec
t:8000 msec
t:9000 msec

Time is straight from "esp_timer_get_time()/1000;" Funny how it comes out exactly on the 1 sec marks.

[urbanze]

I'm using v3.1 release. I put a loop in the beginning of my program calling vTaskDelay(100) and printing the time. I am getting the correct delay of 1000msec (1 sec).

Code: Select all

t:1 msec
t:1000 msec
t:2000 msec
t:3000 msec
t:4000 msec
t:5000 msec
t:6000 msec
t:7000 msec
t:8000 msec
t:9000 msec

Time is straight from "esp_timer_get_time()/1000;" Funny how it comes out exactly on the 1 sec marks.

if your RTOS frequency is at 100Hz, it is correct. vTaskDelay(100) is 100 ticks and 1 tick is 10ms. Try vTaskDelay(pdMS_TO_TICKS(50)) this will delay 50ms.

[fly135]

if your RTOS frequency is at 100Hz, it is correct. vTaskDelay(100) is 100 ticks and 1 tick is 10ms. Try vTaskDelay(pdMS_TO_TICKS(50)) this will delay 50ms.

Chegewara edited his post. So now mine doesn't really make any sense.