multicore access on Raspberry Pi Pico

[mlewus]

The Pi Pico has 2 physical cores, but only one core is usable in CircuitPython. Micropython has limited multicore functionality when used with the pico, allowing the user to start a separate task while passing variables in the task call, like this:

def mytask(pin, delay):
# bang away at a pin or whatever, call with
import _thread
_thread.start_new_thread(mytask, (GP2, 0.2))

mytask runs independently of the main mcu core, and runs until it returns or mcu reset.

Is this planned for inclusion in Circuitpython?

[tannewt]

It isn't a short-term goal. We have many other APIs to implement before we do multi-core.

I'm considering an API to facilitate running native code on the second core instead of additional Python. What are you using it to do?

[mlewus]

Not sure how relevant this is to CircuitPython, but I did some multicore testing with MicroPython on a Pico back in February. I found that global variables require about 1mSec to get updated between cores. The only element that updates faster is a lock. These must be interrupt driven as they update very fast, on the order of a few microseconds.

[Red-M]

I'd really like this for a project I'm building to allow the 2nd core to handle a bunch of additional IO tasks while the first core is on input detection.

[mlewus]

My limited understanding is that Circuitpython is, or started out as, a fork of Micropython. Micropython supports multitasking, locks, and inter-task globals on the Pico. Can a Circuitpython developer comment as to the difficulty of implementing this on Circuitpython?

[tannewt]

My limited understanding is that Circuitpython is, or started out as, a fork of Micropython. Micropython supports multitasking, locks, and inter-task globals on the Pico. Can a Circuitpython developer comment as to the difficulty of implementing this on Circuitpython?

It's really hard to say because none of us have looked into it.

Right now we're based on MicroPython ~1.9.4 (micropython@25ae98f) which is a year or two old. I think upstream has made some concurrency improvements since then so the first step I'd take is to merge in newer MicroPython. There is an outstanding PR to do that here: #4280

Once that is done, I'd try enabling the settings in CircuitPython to see if they work. You'd also need to look at the MP changes for the RP2040's second core. That'll likely expose many areas where there are concurrency issues that need to be fixed.

[Red-M]

Personally, I'd prefer if CircuitPython offered "more difficult" to use features such as _thread because I really just want to get this done and I know how to handle myself with concurrency and memory access.

I'd really want Python on the 2nd core because frankly all my IO tasks are laid out with CircuitPython libraries, so if I had to write C for it I might instead just move to MicroPython instead and re-implement the libraries I'm currently using in MicroPython.

[mlewus]

The problem for me is that using circuitpython on the Pico means throwing away half of the machine. I don't really see C++ on the 2nd core as a solution. Most people who use circuitpython do so for the advantages that it offers over C++. I'm not sure how the decision making works as to which features get to the top of the list but it would be great to see this get prioritized. I've been using micropython, but that means rewriting a lot of the hardware drivers that already exist in Circuitpython. So that is not ideal.

[Red-M]

Would this then be better suited to being tracked along/after 7.x has a release so that there is more control around concurrency?

[ladyada]

@Red-M if its just for keymatrix management, it would probably be better to adapt _gamepad to be a matrix scanning helper...? then it isnt multi-core dependant and could run on other chips :)

[Red-M]

@ladyada Thanks for the reply, but I've gotten the keymatrix poll/scan down to just interrupt pin polling which is way faster.
I'm making a full sized keyboard with RGB and other features so I'm really wanting access to the other core with all the IO libraries.

[ladyada]

if the keymatrix was handled in the background - what other IO would you need?

[Red-M]

dotstar and displayio.