DEVS: Add the ability to adjust "fiber_sleep(20);" delay in the main loop!

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! :wink:

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.

1 Like

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


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

1 Like

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.

1 Like

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:

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.


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! :wink:

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.

1 Like