ESP32S3 support for cores scheduler

[hamstah]

Hi,

I've been using tinygo on an esp32s3 (cardputer adv) and wanted to use the 2 cores to handle time sensitive operation away from UI and IO management. I noticed that only the unicore scheduler seemed to be supported so I tried to prepare a patch for adding it.

DISCLAIMER: I'm new to tinygo, and don't have much experience with ASM etc. I've used AI tools to help me to generate the patch so I'm not expecting my changes to be accepted as is.

I'm looking for guidance on what to implement, and on how to test the implementation for correctness.

I have a patch that seem to work when I manually tested it on real hardware but I can't assess the quality of it due to my limited knowledge of the internals of tinygo.

--

Here is the test code I've used to validate the behaviour

package main

import (
        "machine"
        "runtime"
        "time"
)

func busy(count int) {
        for i := 0; i < count; i++ {
                runtime.KeepAlive(i)
        }
}
func main() {
        busy(60000000)
        n := runtime.NumCPU()

        println("boot")
        println("NumCPU", n)

        go func() {
                for {
                        println("worker tick")
                        time.Sleep(500 * time.Millisecond)
                }
        }()

        for {
                println("main tick")
                time.Sleep(500 * time.Millisecond)
        }
}

The goal is to show that

• it boots correctly
• the right number of CPU is detected (2 for the s3)
• the go routines run and print their output

Checking with the serial console was tricky with timing, so I made it wait before outputing to have a chance to catch it with the reset.
Using a timer.Sleep() hangs for some reason, hence the busy loops, this will need investigating still.

I built it with

tinygo build \
  -scheduler=cores \
  -target=esp32s3-generic \
  -serial=usb \
  -o coretest.bin \
  coretest.go

and flashed with

python3 ~/.platformio/packages/tool-esptoolpy/esptool.py \
  --chip esp32s3 \
  --port /dev/ttyACM0 \
  --baud 460800 \
  write_flash 0x0 coretest.bin

Then validated the output with

$ pio device monitor --baud 115200 --port /dev/ttyACM0
--- Terminal on /dev/ttyACM0 | 115200 8-N-1
--- Available filters and text transformations: debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
boot delayed busy
NumCPU 2
main tick
main tick
worker tick
main tick
...

Before opening a proper PR I wanted to check whether

• this is something someone had some capacity to help me validate/polish
• given it was heavily written with an LLM (with my guiding and a lot of manual testing) I wanted to check if there was a policy around this (I didn't see one in guidelines, but I might have missed it), again I don't expect the code to be merged as is but want to be very clear that the implementation is beyond my ability to document and will need help from someone more knowledgeable.

Here is the code, I had initially created a PR which I've closed pending the points above, I'm happy to re-open one with the context for review,

Thanks!

[dimajolkin]

Don't worry, do the MR, we'll test and check)
PS:
This is wonderful, this is what I wanted to do)

[hamstah]

@dimajolkin Great thanks, I've opened the PR #5358 now