Support for wifi

[soypat]

Just a heads up, I made a driver to control the on-board wifi on the Pico W and Pico 2 W! https://github.com/soypat/cyw43439. These leverage the lneto networking stack https://github.com/soypat/lneto

[embeddedgo]

Thanks for report this. As I can see it's intended for TinyGo. Did you tried it with our Embedded Go toolchain?

[embeddedgo]

I checked It slightly deeper and will definitely try to port it to see the blinky example working. The starting point seems to be the code in bus_pico_pio.go to use our hal/pio package.

I'm currently involved mostly in merging go1.26 into Embedded Go. @clktmr have you a time to play with this?

[soypat]

If you don't compile with -tags=tinygo the HAL should be an interface instead of a struct and if I haven't broken the build for non-tinygo you should be able to call cyw43439.New with your own HAL

[soypat]

Also be sure to use lneto and not seqs! seqs in unmaintained but kept in the repo so the examples in Home Automation with Go book are kept working :)

[clktmr]

I gave it a quick shot. There was a minor issue preventing the build: Presumably unintentionally, net.Flags is missing in noos. Maybe this can be addressed when merging go1.26.

Execution failed in initBus trying to read the test pattern from SPI, which is definitely caused by my broken PIO config/code. I will need some more time to debug this. Right now, I can only take shots in the dark, since I'm still waiting for my logic analyzer.

Otherwise looks very promising!

[soypat]

Is noos already part of the Go standard library?

On the matter of the PIO code- I'd be delighted if we could find a way for https://github.com/tinygo-org/pio/ to be usable by embeddedgo.

[clktmr]

noos is the GOOS introduced by EmbeddedGo. The type definition of net.Flags is currently excluded by the noos build tag. Generally noos doesn't remove exported symbols from packages, rather replaces them with no-ops or errors if they can't be supported.

piolib seems to build directly on tiny-go. I think we would need the same approach you introduced here (building against a hal interface for !tinygo), but the interface would be much bigger.