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.
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.
2 Likes
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.
1 Like