[FoamyGuy]

A new core module _nina implements transport and framing for communication with ESP32 co-processor. If used the core owns the ESP32 pins including the reset pin, which on the Fruit Jam is PERIPH_RESET and also resets the TLV320.

If this change is accepted ESP32SPI library needs updated to use the new APIs when the core owns the co-processor. I will submit a PR there with that functionality.

Python code continues to use ESP32SPI library for WIFI access.

Web workflow uses _nina internally to serve the workflow server. It does not currently support mDNS so it is available by IP only, not circuitpython.local or the UUID .local address.

I have tested the file browser and websocket serial connection fairly extensively over the last few days. Have not tested local or code.circuitpython.org code editor pages.

[dhalbert]

Let's called this airlift and AIRLIFT everywhere instead of nina and NINA. That's what I was doing in #10786, which I stopped working on. Yes, it's our fork of NINA, but it might not be some day.

Is there room for this to fit on, say, a PyPortal? Might we eventually have another version of ESP32SPI that uses _airlift?

[FoamyGuy]

I will rename to airlift

I haven't looked at anything outside the Fruit Jam yet, I'll check into pyportal to see if this could work on there.

The existing ESP32SPI will need to get updated to make it use the new _airlift API when the core owns the co-processor. Otherwise it would try to use the pins and find that they are occupied.

When the core doesn't own the co-processor (web_workflow not enabled) the existing ESP32SPI works as-is. Only the case where web workflow is enabled and the core owns the ESP32 needs updating to use the new API.

[dhalbert]

When the core doesn't own the co-processor (web_workflow not enabled) the existing ESP32SPI works as-is. Only the case where web workflow is enabled and the core owns the ESP32 needs updating to use the new API.

Could we use _airlift in all cases, even when the core doesn't own the co-processor? Would that make ESP32SPI smaller or larger? I'm thinking that ESP32SPI could call a constructor with whatever pins it wants, if for instance, it was an external AirLift breakout.

[FoamyGuy]

@dhalbert after exploring this some I do think it's plausible to use _airlift even when the core doesn't own the co-processor and with pins passed via constructor. And also is looking promising on pyportal but I need to test that route still.

The size situation is tricky. ESP32SPI can get smaller if it loses fallback support for working without _airlift. But there are some boards that it looks like _airlift may not fit on that could conceivably use airlift via featherwing. The Feather M4 came up as one that overflowed when I checked. Possibly matrix portal m4 could be tight or overflowing as well, I need to look closer at that one.

If ESP32SPI keeps fallback logic to work without _airlift then it gets a bit bigger but can can be refactored such that the fallback logic is only imported when needed.

[FoamyGuy]

Maybe the fallback transport support could be moved to a new library instead of a new module within ESP32SPI. Then ESP32SPI gets smaller, and only the boards that want to use airlift without being able to fit _airlift module would need to load it.

That could be awkward to explain on support side perhaps. Hopefully the error messages could make it clear when that extra library is needed.

[FoamyGuy]

I updated this in the latest commit to allow user passed pins for init.