Giving core 0 work from core 1 via a interrupt or lock

[GM-Script-Writer-62850]

Here is a demo script (tested on my PICO H)

uasyncio can only be used on a single core... some things only work on core 0 (eg use the network on a pico W)

But how can we have core 0 do work on behalf of core 1? Here is my solution, maybe there is a better way but this works

#!/usr/bin/python3
from threadsafe import Message
from time import sleep
from machine import Pin
import _thread
import uasyncio

class cross_thread:
	pin=Pin(25, Pin.OUT,value=0)# any unused pin works, onboard led used for sake of demo
	#_thread_lock=_thread.allocate_lock()
	uasync_lock=uasyncio.Lock()
	data={}
	def set_data(msg,fn,*args,**kwargs):
		cross_thread.data={
			"msg":msg,
			"fn":fn,
			"args":args,
			"kwargs":kwargs
		}

def core_0_does_this(txt):
	print(txt)
	return "bar"

async def main():
	while True:
		await cross_thread.uasync_lock.acquire()
		msg = Message()
		cross_thread.set_data(msg,core_0_does_this,"foo")
		cross_thread.pin.on()# trigger interrupt
		reply=await msg
		cross_thread.pin.off()# reset interrupt
		cross_thread.uasync_lock.release()
		print(reply)
		await uasyncio.sleep(1)

def do_the_thing(pin):
	cross_thread.data["msg"].set(cross_thread.data["fn"](*cross_thread.data["args"], **cross_thread.data["kwargs"]))
cross_thread.pin.irq(trigger=Pin.IRQ_RISING, handler=do_the_thing)
# This could be done with a .toggle() in main() on the pin and trigger on rising and falling, but this is better for the sake of a demo

def _main():
	uasyncio.run(main())
_thread.start_new_thread(_main,())

while True:
	# core 0 has no real work, just waiting to be interrupted...
	sleep(1)

Alternate version using a lock instead of a interrupt, seems less useful since you are going to get anything else done on core 0, but if you need to debug it and thing it is cause it is a interrupt making it not work it is useful

#!/usr/bin/python3
from threadsafe import Message
import _thread
import uasyncio

class cross_thread:
	thread_lock=_thread.allocate_lock()
	uasync_lock=uasyncio.Lock()
	data={}
	def reply():
		cross_thread.data["msg"].set(cross_thread.data["fn"](*cross_thread.data["args"], **cross_thread.data["kwargs"]))
		cross_thread.thread_lock.acquire()
	async def unblock(fn,*args, **kwargs):
		msg = Message()
		await cross_thread.uasync_lock.acquire()
		cross_thread.data={
			"msg":msg,
			"fn":fn,
			"args":args,
			"kwargs":kwargs
		}
		cross_thread.thread_lock.release()
		msg=await msg
		cross_thread.uasync_lock.release()
		return msg

async def main():
	i=0
	while 1:
		await uasyncio.sleep(3)
		await cross_thread.unblock(print,"hello world x",i)
		i+=1

cross_thread.thread_lock.acquire()

def _main():
	uasyncio.run(main())
_thread.start_new_thread(_main,())

while True:
	cross_thread.thread_lock.acquire()
	cross_thread.reply()

[bidrohini]

Core 1 sets up the data in cross_thread.data by calling cross_thread.set_data(msg, core_0_does_this, "foo"). This function sets the msg, fn, args, and kwargs in cross_thread.data.

Core 1 triggers an interrupt on a specific pin (Pin 25 in this case), which calls the do_the_thing(pin) function on Core 0.

Core 0 reads the data from cross_thread.data in the do_the_thing(pin) function and executes the function specified in cross_thread.data["fn"] with the provided arguments (cross_thread.data["args"] and cross_thread.data["kwargs"]). The result of the function call is then passed back to Core 1 via the message object (msg).

Core 1 waits for the message object to be set and retrieves the result from it using reply = await msg.

Core 1 prints the result obtained from Core 0 and repeats the process in a loop.

Core 0 runs the uasyncio event loop with the main() coroutine.

A separate thread (_main()) is started on Core 0 to execute the uasyncio event loop.

In the main loop (while True) on Core 1, a delay of 1 second is added to allow Core 0 to handle the tasks and execute the uasyncio event loop.

This approach allows you to achieve collaborative multitasking on the Raspberry Pi Pico H using both cores. Core 1 offloads tasks to Core 0, which efficiently handles them through uasyncio.

[GM-Script-Writer-62850]

added a second version that uses a lock instead if a interrupt

[peterhinch]

A couple of thoughts. Have you considered using micropython.schedule rather than an IRQ? Note I haven't tested this.

Secondly, while this is an interesting exercise and useful information, I'm unclear about practical use-cases. My approach is to run asyncio on core 0, only using core 1 for tasks which would block asyncio or cause performance problems. This is because core 0 has access to all hardware including stream devices such as sockets and UARTs. Further, asyncio does a great job of sharing resources. So core 0 seems a natural for the main program. Or am I missing something?

A random idea (this is the ideas thread). Damien once mentioned that it would be good if an instance of asyncio could run on each core. Failing that, a simple scheduler could be written to run on the subsidiary (non-asyncio) core. In the days before MicroPython had a usable scheduler I wrote one - it comprises just over 300LOC. Such a sceduler, equipped with threadsafe message-passing to asyncio, might be fun to write.

[GM-Script-Writer-62850]

The oddity was meant as a workaround another issue, following the logic of if i can't do X on core 1 then i will use core 1 and offload to core 0

the PICO W can only use the network on core 0

i have switched using this lib for networking request: https://github.com/Carglglz/asyncmd/blob/main/async_modules/async_urequests/async_urequests.py

now my biggest issue is using core 1 on a W5500-EVB-Pico

• the bug i reported DHT measure() locks up (core0) when _thread is running (core1) if WIZNET5K networking is enabled #10448 i am am now thinking this is some kind of clock de sink

even if i disable the network while using core 1 it will still crash, as soon as core 0 read a DHT22 a single time it is possible for it to crash seconds, minutes or hours in the future

everything i have done with my PICOs so far is using them for basic IO stuff like reading switch states, reading photocell analog values, using PWM on a transistor, or controlling LEDs or relays, DHT22s and D18B20s are the only sensors i have used