# DEVS: Add the ability to adjust "fiber\_sleep(20);" delay in the main loop!

**URL:** <https://forum.makecode.com/t/devs-add-the-ability-to-adjust-fiber-sleep-20-delay-in-the-main-loop/22111>\
**Category:** micro:bit\
**Created:** [August 28, 2023, 4:36pm UTC](https://forum.makecode.com/t/devs-add-the-ability-to-adjust-fiber-sleep-20-delay-in-the-main-loop/22111 "2023-08-28T16:36:58Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![MCbubba77](https://avatars.discourse-cdn.com/v4/letter/m/c68b51/32.png) [@MCbubba77](https://forum.makecode.com/u/MCbubba77)\
**Post date:** [August 28, 2023, 4:36pm UTC](https://forum.makecode.com/t/devs-add-the-ability-to-adjust-fiber-sleep-20-delay-in-the-main-loop/22111/1 "2023-08-28T16:36:58Z")

</div>

A very helpful member pointed out that there is an intentional 20ms delay in the execution of **every** iteration of the Forever loop in MakeCode micro:bit. (fiber\_sleep(20); in: pxt-microbit/libs/core/codal.cpp)

This operation is completely arbitrary and in most cases is ridiculous overkill for a 64MHz 32 bit ARM 'processor to do a few background tasks! Archaic16MHz 8-bit AVR and PIC MCUs have been doing very advanced (read: fast) university-level robotics and sensing for literally decades! 😉

Anyhoo, a simple addition to the “Control:More…” menu that added a system variable that sets the amount of delay, or maybe even just a delta above a baseline, like 3ms, would help tremendously in making a micro:bit capable of tasks that need a significantly higher sampling and execution frequency than 50Hz!

Currently, experiments like line following and anything else that relies on even modestly high frequency sampling (say, 250Hz) will fail, or act inconsistently, which is extremely frustrating for the students working with the micro:bit.

---

<div class="post-metadata">

**Author:** ![richard](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.makecode.com/richard/32/5417_2.png) [@richard](https://forum.makecode.com/u/richard)\
**Post date:** [August 28, 2023, 4:44pm UTC](https://forum.makecode.com/t/devs-add-the-ability-to-adjust-fiber-sleep-20-delay-in-the-main-loop/22111/2 "2023-08-28T16:44:41Z")

</div>

@MCbubba77 you can do this yourself with the run in background block:

![image](https://us1.discourse-cdn.com/flex020/uploads/makecode/original/2X/f/f4a5cec3d5f704a58f093b9f022dfe8031709505.png)

Just make sure you have a pause in the loop or you’ll prevent any other code from running. Threads on the m:bit are non-preemptive so you need to yield every once in a while

---

<div class="post-metadata">

**Author:** ![bsiever](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.makecode.com/bsiever/32/1032_2.png) [@bsiever](https://forum.makecode.com/u/bsiever)\
**Post date:** [August 28, 2023, 5:40pm UTC](https://forum.makecode.com/t/devs-add-the-ability-to-adjust-fiber-sleep-20-delay-in-the-main-loop/22111/3 "2023-08-28T17:40:23Z")

</div>

I don’t think this runtime was meant for high frequency control loops (cooperative multitasking system with user provided tasks — just not a good fit).

One other reason some throttling may make sense: Throttling reserves some CPU time for other tasks, like the bluetooth stack or, possibly, for extensions. I think the bluetooth stack, when present, has priority and could undermine timing expectations.

---

<div class="post-metadata">

**Author:** ![jwunderl](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.makecode.com/jwunderl/32/5308_2.png) [@jwunderl](https://forum.makecode.com/u/jwunderl)\
**Post date:** [August 28, 2023, 5:54pm UTC](https://forum.makecode.com/t/devs-add-the-ability-to-adjust-fiber-sleep-20-delay-in-the-main-loop/22111/4 "2023-08-28T17:54:24Z")

</div>

There’s also the `every {num} ms` block for purposes like this, though it’ll fail to keep up when you’re getting super low values just from other services taking over momentarily in between calls as you mentioned:  
 ![image](https://us1.discourse-cdn.com/flex020/uploads/makecode/original/2X/9/92a8bc99a5b344cfd4e00c3b3dd533c2b9826f9f.png)

If you really want to control it, a while loop with no pause as has been discussed will always be ‘optimal’, just nothing else will get a chance to run until it exits. This sort of thing can be incredibly confusing for new users who won’t understand why things don’t “mesh”, though – and many / most of the default blocks are intended so new users can at least make sense of them – so anything along these lines tends to fall closer to the “throw it in an extension if you want full control” sort of bucket.

---

<div class="post-metadata">

**Author:** ![MCbubba77](https://avatars.discourse-cdn.com/v4/letter/m/c68b51/32.png) [@MCbubba77](https://forum.makecode.com/u/MCbubba77)\
**Post date:** [August 28, 2023, 9:02pm UTC](https://forum.makecode.com/t/devs-add-the-ability-to-adjust-fiber-sleep-20-delay-in-the-main-loop/22111/5 "2023-08-28T21:02:30Z")

</div>

This is certainly helpful, but kind of a kludge if your entire program loop is what needs to run at a higher frequency than 50Hz! 😉

In linefollowing or similar speed-sensitive tasks (“speed” being a _very_ relative term here!), you need to sample reflective sensors and make decisions based on that input, so the “Run in Background” really doesn’t fit that need.

To make it easier, maybe the simple addition of 250Hz and 500Hz Forever blocks would be more intuitive. I can’t see any need to go “faster” than that, and I suspect that even at 500Hz, you would be hard-pressed to ever have a situation where the background processes do not have enough time to complete.