The ESP32 module used as an ESP32SPI co-processor is a bit of monolith. It does its job silently, in the dark, with no external user controls or indicators. But there is untapped power even as a co-processor.

This issue is an enhancement request to expose additional command handlers from CommandHandler.cpp from the adafruit/nina-fw, especially setPinMode, setDigitalWrite, and setAnalogWrite.

There are also other potentially interesting command handlers, but I'm not sure which are fully implemented even in the C code; I don't seem to get much meaningful returned from getTime or getTemperature for example (I could easily be doing something wrong).

In Arduino, the Airlift breakout can control its on-board red, green, and blue LEDs via the adafruit/WiFiNINA library. But for CircuitPython on a separate M4 processor, the ESP32SPI library would need to expose additional command handlers to be able to control the GPIO pins.

Potentially, many ESP32 co-processor pins could be made available to CircuitPython, depending on form factor:

• ESP 32 Airlift breakout GPIO/A pins:
25[Green LED], 26[Red LED], 27[Blue LED]

• ESP32 Huzzah32 breakout GPIO/A pins:
2, 4, 12, 13, 15, 16, 17, 19, 21, 22, 25, 26, 27, 32

• ESP32 Huzzah32 Feather GPIO/A pins:
A5/4, 12[PULLDOWN], 13[LED], 15, 16/RX, 17/TX, 19/MI, 21, 22/SCL, A1/25, A0/26, 27, 32

• ESP32 Airlift Feather GPIO/A pins:
25[Green LED], 26[Red LED], 27[Blue LED]

[ P.S. I spent several hours trying to do this myself, but between the python code, SPI protocol, and layers of C code, it's beyond my current level. I'll keep digging though. I'm sure someone more skilled in the arts would look at it and say "oh, of course you'd just..." ;-) ]