-
Notifications
You must be signed in to change notification settings - Fork 74
Expose additional NINA FW SPI command handlers (AKA Release the Kraken) #36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I just submitted PR #38 that exposes the low level GPIO commands already in the nina-fw. Nothing specific to a particular ESP32 board. |
nice! |
Yup, I’ll test and review tomorrow.
…On Mon, Apr 22, 2019 at 10:51 PM ladyada ***@***.***> wrote:
nice!
anyone wanna test it out? @brentru <https://github.com/brentru> should be
able to twiddle the RGB LEDs on the AirLift breakout
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACOW7GIDT6XHUH3BZFMA5TPRZ2TDANCNFSM4HFKWATA>
.
|
:D |
Also confirmed working: Pin 13 Red LED on Feather ESP32, & Pin 13 Red LED on ESP32 Huzzah Breakout. No reason to think this shouldn't work on any capable pin on any NINA FW board. |
Merged into master and released! |
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..." ;-) ]
The text was updated successfully, but these errors were encountered: