_thread module is not supported

Arduino Boards
1

_thread module works in raspberry pi pico: Main thread works on the first core of RP2040, the new thread works in the second core and programming does not allow any other thread. Those threads are real and happens in parallel execution. Uasyncio is not the same it can not make two parallel loops… My question is the following RP2040 on pico, RP2040 on nano what is the difference and _thread module is included in the first and not included in the second?

2

Threading is disabled in our fork.

3

I guess it wouldn’t hurt to enable this module in the rp2 port, but it’s not reliable, there are reports of issues with MicropPython threading in rp2 port, also the IDE can make things worse because it can interrupt the script at any point. Let me know if you want a firmware for testing.

4

I would be glad to use _thread module even as a beta. It is the only way to run two separate while true: loops in parallel. uasyncio is not real parallel execution…
In my application, the first loop is used to run the automation in full speed (under 50mS). The second loop contains blocking stuff which should not affect the first loop. It is already tested in pico. I suppose IDE-debugging will work fine on the main thread (happened in pico, I do not expect more), so I will switch the threads to debug the second one, fare enough…

5

You could maybe run the first loop code in a timer callback, 50ms is a lot time… Threading may or may not be enabled in the next release, but here’s a test firmware with _thread enabled.

firmware.uf2.zip (516.1 KB)

EDIT: Or better if it’s possible to use a SM and PIO for I/O.

6

Wow that was really fast… Thank you, I apreciate that. The problem is not the first loop, the problem is arround blocking operations happening on the second loop, which also halts the other one. May be State Machine whould be better but I’m not verry familiar with it… Thank you in advance

7

Yes SM/PIO is way to do these with RP2, also possible to use a timer callback which will interrupt the blocking code, the only catch is you can’t alloc memory inside any callback, so any memory must be pre-allocated.

8 
#This is a very simple form of two parallel loops.
#Anything can happen in the blockingStuff loop, still mainAuto
#works in full speed without any halt. uasyncio does
#not provide this kind of service an simplicity

from machine import Pin
import _thread, utime

pin = Pin(6, Pin.OUT)

def blockingStuff():
    while True:
	.....


def mainAuto():
    while True:
	if (something non blocking happend):
		pin.toggle()
 
_thread.start_new_thread(blockingStuff, ())
mainAuto()
_thread.exit()
9

That thread will never exit, and if you stop the script from the IDE (or if using terminal with ctrl+c) it will break. Edit: I guess it’s fine if you just deploy this to the board and not plan on using the IDE too much.

10

Actually I use IDE a lot. I use IDE stop button and last line of the script stops the thread… Without the last line thread never stops when I press stop. It works just fine.

11

Last line is never executed because mainAuto is an infinite loop (while True)…Also note that the IDE can interrupt the script at any point, so even if thread.exit() gets called somehow in this script or in another script, the IDE can interrupt before thread.exit() leaving the thread running which I’ve seen firsthand (with micropython from terminal and with our firmware from the IDE or from terminal terminal) and it often results in an uncaught exception possibly memory corruption etc…

12

I also thought so… But somehow if I omit last line thread never stops and IDE stop button never returns in run. Somehow magic happens but it really works fine. I am really as curious as you, about the reason that makes it work but I am happy that it works…

13

Maybe you’re catching exceptions and breaking from the loop on exception ? That’s the only explanation, and it would actually be a good idea to try to catch the IDE exception and call thread.exit() then raise it again.