# Replacing vTaskDelay(); in Renesas RZ/A1H MCU

**URL:** <https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202>\
**Category:** Kernel\
**Tags:** tutorial\
**Created:** [August 14, 2024, 12:03pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202 "2024-08-14T12:03:59Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![rakYkashyap](https://avatars.discourse-cdn.com/v4/letter/r/e79b87/32.png) [@rakYkashyap](https://forums.freertos.org/u/rakYkashyap)\
**Post date:** [August 14, 2024, 12:03pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/1 "2024-08-14T12:03:59Z")

</div>

Hi RTOSians,

Could anyone suggest replacing the use of vTaskDelay(); in effective manner.  
And how to handle those with new one.  
I’m currently using APIs for Renesas RZ/A1H.

I really appreciate your help.

Thanks,  
Rakshith

---

<div class="post-metadata">

**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\
**Post date:** [August 14, 2024, 12:05pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/2 "2024-08-14T12:05:48Z")

</div>

your question does not make any sense whatsover. Why would you want to replace the call and for what purpose?

---

<div class="post-metadata">

**Author:** ![rakYkashyap](https://avatars.discourse-cdn.com/v4/letter/r/e79b87/32.png) [@rakYkashyap](https://forums.freertos.org/u/rakYkashyap)\
**Post date:** [August 14, 2024, 12:41pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/3 "2024-08-14T12:41:59Z")

</div>

> [@rakYkashyap](#):
>
> suggest replacing the use of vTaskDelay()

Thanks for your time in replying.

There are a few potential reasons why I planned replacing vTaskDelay() in FreeRTOS.

1. As vTaskDelay() works in ticks, which may not provide fine-grained enough control for some applications. More precise timing might be needed.
2. In some cases, vTaskDelay() can lead to busy-waiting, which isn’t ideal for CPU utilization.  
There are some other issues could be generated.  
Any recommended alternatives if any please.

Regards,  
Rakshith

---

<div class="post-metadata">

**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\
**Post date:** [August 14, 2024, 1:31pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/4 "2024-08-14T13:31:42Z")

</div>

FreeRTOS and thus the scheduler works in ticks. You can not achieve finer granularity than ticks.

Also, in which cases do you think vTaskDelay ends up in busy waiting?

---

<div class="post-metadata">

**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\
**Post date:** [August 14, 2024, 3:04pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/5 "2024-08-14T15:04:40Z")

</div>

It may be possible to come up with something that uses an isr and the portYieldFromISR mechanism to force the scheduler to schedule your task in between timer ticks, but I would think that these techniques are rather error prone and not guaranteed to always meeting strict timing requirements.

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [August 14, 2024, 3:10pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/6 "2024-08-14T15:10:32Z")

</div>

It is quite easy to get the scheduler to change tasks between timer ticks. That is the whole purpose of the “wasWoken” flag in the FromISR functions.

Sub-tick delays (or delays more accurate then up to -1 tick) can easily use a hardware time that sends a notification or gives a semaphore.

---

<div class="post-metadata">

**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\
**Post date:** [August 14, 2024, 3:15pm UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/7 "2024-08-14T15:15:51Z")

</div>

That was my point in my latest post, but it is still subject to the scheduling rules; for example, if the task to be woken outside of tick granularity does not have the highest priority, its wake deadline will not be met. That is why the TO should not expect reliable fine granularity scheduling unless his architecture centers around this.

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [August 16, 2024, 6:46am UTC](https://forums.freertos.org/t/replacing-vtaskdelay-in-renesas-rz-a1h-mcu/21202/8 "2024-08-16T06:46:51Z")

</div>

> [@rakYkashyap](#):
>
> In some cases, vTaskDelay() can lead to busy-waiting, which isn’t ideal for CPU utilization.

This is not correct. `vTaskDelay` puts a task in the blocked state and ensures that it is not picked by the scheduler until the time passed to `vTaskDelay` expires.
