Do I need to yield in the main loop?

[tb4450]

Hello

I have a XIAO BLE and tried the firmware "MicroPython v1.20.0 on 2023-04-26; XIAO nRF52840 Sense with NRF52840" and then "MicroPython v1.21.0 on 2023-10-06; XIAO nRF52840 Sense with NRF52840". Both behaved the same.

I am running this simple endless loop that is counting and printing to an OLED display. The problem is that Windows cannot connect to the board via USB any longer.

Only after adding e.g. time.sleep_ms(1) in the for loop USB comes up and connects.

What is the supposed way to run loops on a nRF52 kind of board? Do I have to yield somehow to the Softdevice and if how?

while True: for i in range(0, 9999): oled.fill(0) oled.large_text(f"{i}", 0, 0, 4, 1) oled.show()

Thanks
Thomas

[andrewleech]

Interesting find! On most ports there are some background tasks that are only run when the application is "idle", eg waiting for a UART read or running time.sleep, it seems servicing the USB is one of these background tasks on the nrf port.

I know some other ports have the USB triggered by interrupts so don't have this restriction, however the nrf port doesn't get a lot of users here so I'm not too surprised it's a little more difficult to use.

There was also some recent work to restructure how the TinyUSB stack is serviced on a few ports, though this hasn't been extended to nrf yet: #12846

Reading the description on that PR, it leads me to think these background tasks should still be run occasionally even without the sleep, so perhaps there's a separate issue here too.

Longer term there's been talk of migrating the nrf port to use zephyr by default, as nordic themselves have deprecated the softdevice in favour of that platform. I believe more work is still needed to get the zephyr port up to feature parity and simplify board definitions though so it's a slow process. This plan does increase reluctance on putting much work into the existing nrf port though...

[projectgus]

There was also some recent work to restructure how the TinyUSB stack is serviced on a few ports, though this hasn't been extended to nrf

I actually have a patch here to extend the "new" TinyUSB servicing approach to nrf port, but it's not working with SoftDevice yet. Hoping to submit it as a PR soon.

The nrf port doesn't call the "hook" for TinyUSB in as many places as other ports did, which seems like it's actually a bug. However, replacing it with the new approach for servicing TinyUSB will probably be the best fix.

In the meantime, I think the least impactful workaround would be to call machine.idle() in your loop. There may still be some slowdown, but probably not as much as machine.sleep_ms(1).

[tb4450]

Thanks. So I will be using machine.idle().

[MattPeddlesden]

Hmm this looks like it might solve a problem i'm having - has there been an update on this? I'm using 1.24.1 and while(1) loops completely lock the device out from being accessible again to reconnect to thonny. Thought i'd bricked it last night until I managed a trick with CircuitPython that seemed to clear the storage and let me back in.

[projectgus]

The "new" USB implementation mentioned above has been added on nrf. If you're able to, please open an issue on the MicroPython repo with some more details (board, softdevice or not, etc.)

The machine.idle() workaround mentioned above should still work in the meantime, though.