I’m working on a project that uses Renesas RA6M5 MCU. The FreeRTOS is 10.4.3.
I’m trying to figure out the difference between vTaskDelay() vs R_BSP_SoftwareDelay() (fsp/ra/fsp/src/bsp/mcu/all/bsp_delay.c at master · renesas/fsp · GitHub). The vTaskDelay() is a function from FreeRTOS. Do these two functions do the same thing? I need to delay a period of time in one task. But I prefer to give the CPU time to other tasks during the delay. Which one will do what I need?
Namely, which one should I use?
vTaskDelay(pdMS_TO_TICKS(1000));
Or
R_BSP_SoftwareDelay(1000, BSP_DELAY_UNITS_MILLISECONDS);
Most likely you want to use vTaskDelay which gives up the CPU to other tasks ready to run. The non-OS delay functions are busy waits i.e. don’t yield the CPU.
Thanks Hartmut! I appreciate it.
Yes, I changed the code to use vTaskDelay() instead of the R_BSP_SoftwareDelay() because I found that function could get the firmware stuck.
One question is, is it okay if I just delay 2ms like “vTaskDelay(pdMS_TO_TICKS(2))”? Will that cause the system “jittering”? I thought the 2ms won’t give much CPU time to other tasks. Instead, it could cause the small pieces of the CPU time?
Thanks.
vTaskDelay will yield time to other tasks to run for at least as many ticks as desired.
With the default FreeRTOS frequency of 1000 Hz, 2ms translates to 2 ticks of blocking before being scheduled again. However, if a higher-priority task unblocks, it may block the delayed task for longer than desired.
If the delay needs to occur on a regular interval, say waking up every 10ms to perform an operation which takes a single tick, then vTaskDelayUntil gives feedback when the delay lasts longer than desired, and it will also adjust the next delay to fall on the next interval.
R_BSP_SoftwareDelay appears to be non-blocking and may be preempted by the FreeRTOS scheduler if configUSE_PREEMPTION is 1 in FreeRTOSConfig.h. This probably results in the lockup you’re observing.
You should use vTaskDelay for better task management, as it allows other tasks to run by yielding the CPU, unlike non-OS delay functions that simply keep the CPU busy.