Hi. I have a program where one microbit board is blinking (dim up / down) some neopixel led’s. It should leave the “while” loop when its radio module receives a certain message, thus setting the “Rx_side_valg” to eigher “1” or “2”. The “while” loop condition should no longer be present and the program should leave the loop.
However the program stays in the loop and completely ignores the radio input,and just keeps on fading the led’s up and down.
But if it receives the message BEFORE the “while” loop, it jumps over the loop and continues on.
So BEFORE the loop it listens to the incoming radio signals, but completely ignores them in the loop. I have tried changing the delays to 1000us, but still it gets stuck in the loop.
How can I force it to listen to the radio even when it is in the loop?
Try using a basic.pause instead of a wait. The pause allows the micro:bit scheduler to check for any events whereas I believe the waitMicros will only check if you sleep longer than 50000 us. You can see this in scheduler.cpp:
There you see that when you use the basic.pause( which calls sleep_ms), it will call the scheduler. If you use waitMicros, it calls the sleep_us and will internally call the sleep_ms if us >50000.
So in short, try using basic.pause instead to allow the scheduler to check for radio events.
I am using a second board as a “remote” that sends messages to this first board.
However it remembers if button “A” (example) has been pressed twice, perhaps by mistake.
Is there a way to make the board ignore any buttons pressed for a period of a second or two? I have not been able to find any information on disabling and re-enabling the buttons on the board itself.
Your code would be where the hearts are. Every time the button A is pressed, it first checks to see if at least 2000mS have passed since the last time it was pressed.
I am having exactly the same problem - no radio messages are processed while in a loop.
However, it doesn’t change behaviour when I increase wait time or change the wait function.
Neither waiting for > 50000 us works
control.waitMicros(500001)
nor pausing for 5 seconds
basic.pause(5000)
is working.
Before the loop - messages get through. After I end the loop with a press on A button on the device itself, all messages pop in that have been received but not processed during the loop.
Do you have any idea?
I am using a BBC:micro V2 as sender and receiver.
Maybe @richard can confirm…but Neopixels may not be very compatible with certain uses of radio. The radio reception may be unreliable in cases like this.
The underlying ws2812 library uses some tight loops in assembly language and disables interrupts (needed to detect the incoming radio messages). It’s possible that there will be few chances to “catch” a radio message in any loop that repeatedly does neopixel operations.
Thanks @richard and @bsiever for your thoughts.
I removed all neopixel components from a copy of the file to give it a try.
Unfortunately, there is still the same behavior.
I am thinking of breaking up the loops to be part of the “forever” block or part of a “each xxx ms” block.
@Karsten Can you provide a little more detail on the specific behavior you’re seeing with those last two links? Is it that you never change modes as a result of a radio message (on radio received doesn’t appear to be working?)
I noticed that you still have Neopixel operations occurring every 100ms and 500ms. That may still disable the radio for substantial time periods. (The radio is being disabled for a moderate amount of time about 12 times per second). Can you try the code without any Neopixel operations at all, like: https://makecode.microbit.org/S68524-93668-13686-66273 ?
Hi @bsiever, sorry for the confusion. I think my posts got approved in the wrong order. Now it looks like the issue is still not resolved.
I am happy to summarize, should anybody else stumble upon the behaviour in the future:
Problem
When looping within one of my functions; no radio messaged were handled (radio.on_received blocks).
Details
When ending the loop with one of the physical buttons on the BBC:micro, all the queued received messages got processed.
No matter which kind of sleep/pause (control.waitMicros, basic.pause) and which amount of delay (up to 5 secs) I used, while being inside my custom function loop no radio interaction was possible.
Potential influence of neopixel libraries could be precluded by removing all neopixel code from the project. Still the same bahaviour.
Solution
I refactored the code in my custom functions to be part of the standard on_forever() loop and radio messages are being processed at all times, also with neopixel running at the same time.
Thanks for your different thoughts along the process!
