Hi,

I have a Pico (RP2040) project which uses both cores, one to manage a web server type interface and the other to manage sensors and sums. The software has evolved over two years has run 24/7 for the past 18 months. The processes are managed with the _thread module. The software works fine with V1.20.0, but becomes unstable under later versions. I now need to add a Bluetooth interface as an alternative to the WiFi one.

The Bluetooth module is not supported by the version of V1.20.0 which I have installed. I've written some stubs for the Bluetooth code which work OK with v1.26.0. I would appreciate some some help, two questions:

1) In which versions of the firmware is the _thread module stable.

2) Should I not be using the _thread module, and doing something else.

All suggestions gratefully appreciated.

Regards

David Mortimer

SolarBucket wrote: ↑

Sat Sep 20, 2025 7:54 am

1) In which versions of the firmware is the _thread module stable.

None. The official documentation still describes threading as "This module is highly experimental and its API is not yet fully settled and not yet described in this documentation".

Threading has historically been flaky, unreliable and unpredictable, when using MicroPython for the RP2 and I am rather surprised and impressed you have something which has held up for 18 months. I guess you luckily hit some sweet spot where everything worked, but recent refactorings of MicroPython have broken that; there have been quite a few since the 1.20 version.

Though things have got worse for you, threading has become better in general, but still isn't without its problems, needs care taking, and techniques used which aren't well documented. How easy it would be to make your code work with the latest version will likely depend on how you are implementing what you have, controlling access to shared data.

SolarBucket wrote: ↑

Sat Sep 20, 2025 7:54 am

2) Should I not be using the _thread module, and doing something else.

Yes, but I am not sure what you should be using; possibly asyncio or maybe a Zephyr build, or something other than MicroPython.

Trying to get a large body of non-working code working can be a challenge. One option might be to put that to one side and start again from the ground up. Developing incrementally and testing as you go that you haven't hit any issues.

How large or complicated is your existing code ?

Thanks for the comment, the documentation has clearly not changed much in the past 18 months. I'm contemplating a "demo" release and want to avoid major changes to code that is reasonably well tested. I will spend some time testing against versions of MicroPython greater than 1.20, if that does not go well, I will look at alternatives, including async.

MicroPython has exceeded expectations, the original code was intended to be a prototype for a C implementation, but other than threads, there have no significant issues.

Regards

David Mortimer