Support ESP-AT commands over SPI

[bgould]

As per @deadprogram in tinygo-org/tinygo#694:

The ESP32/ESP8266 official firmware is this: https://github.com/espressif/esp-at

It supports either AT commands over UART or AT commands over SPI.

I think the ideal situation would be to add the SPI interface support to the current espat driver (https://github.com/tinygo-org/drivers/tree/master/espat) to allow using either the UART or SPI in a similar way to how the SSD1306 drivers works (https://github.com/tinygo-org/drivers/blob/master/ssd1306/ssd1306.go#L52-L75) although the SSD1306 is SPI/I2C the concept should be similar.

At a glance it appears SPI support is wrapped with "SDIO" protocol - to wit:
https://github.com/espressif/esp-at/blob/master/docs/SDIO_AT_User_Guide.md

possibly relevant:
https://www.ercankoclar.com/wp-content/uploads/2017/11/SD-InputOutput-SDIO-Card-Specification.pdf

[deadprogram]

Actually what you want is this one: https://github.com/espressif/esp-at/tree/master/main/interface/hspi

[bgould]

I've been doing some reading into this and I think this can work but from what I can tell it is the case that:

• Different boards with integrated esp32 (Arduino Nano 33 IOT, Adafruit Metro Airlift, etc) seem to have different pins connected for the SPI interface
• The connected pins do not seem to match the GPIO pins in the "hpsi" README for any of the boards I've looked at. Nevertheless it seems like any pins can be used for the SPI interface: Boot-loop when HSPI is used as AT interface espressif/esp-at#137 (comment)

I will need to dig into the ESP-AT firmware a bit to see how the "SPI iomux" gets configured as described in that comment to ensure that this is possible. I suspect that we would then need to have a separate ESP-AT firmware build for each configuration. Maybe we could eventually build firmware for the common configurations using CI to make it easier for people so that this would be less of a problem.

[deadprogram]

That HSPI interface is code that runs on the ESP32 itself, not the code that runs on whatever MCU is connected. You are correct that various pins on the ESP* will need to be coded correctly for that particular setup. although they usually have the same configs.

I think having at least one pre-built binary that can be flashed for any given ESP* on a particular board would be extremely helpful.

Also having a way to correctly have a USB CDC "passthru" written entirely in TinyGo so that boards like the Arduino Nano33 IoT can flash the attached ESP32-compatible WiFi chip (NINA-W102).

[bgould]

Ugh I've been spinning my wheels with this trying to figure out how to build the HSPI version of the firmware... I've come to realize that upstream esp-at master seems to have dropped the HSPI option from the Kconfig menus sometime after the v1.2.0.0 tag and before the v2.0.0.0_esp32 tag.

The option does exist in the hybridgroup/esp32-at fork on the arduino-nano33-iot branch so I will proceed with that as my starting point (probably where I should have started in the first place in retrospect)

[deadprogram]

Seems like it is there in the master branch: https://github.com/espressif/esp-at/tree/master/main/interface/hspi also https://github.com/espressif/esp-at/blob/master/main/component.mk#L10

[bgould]

I know that's why I was so confused ... I saw the code there but it when I run make menuconfig on master all I get are these for the options:

On the v1.2.0.0 tag make menuconfig gives me the HSPI option:

Maybe it is just a problem with their menu system and manually updating the options in the config would work... for now though I have something workable and it is probably better to start out with the version of the firmware that is known to work with the driver. Once I have the SPI communication working ok with v1.2.0.0 I can maybe swing back around and look at v2.0.0.0 some more.

[deadprogram]

A very reasonable approach!

[deadprogram]

Just found this message on an issue for the esp-at repo: espressif/esp-at#259 (comment)

Not very encouraging to use the AT over SPI interface... makes me wonder if we should be looking more seriously at the SDIO interface.

[bgould]

Sorry didn't notice your last comment until just now... even reverting to the older firmware that had SPI support I couldn't get the module to ack back to any commands no matter what I tried. Finally I just wanted to make sure that my pin definitions were correct so I tried communicating with the WiFiNINA firmware using the same pins, which is working... I ended up going down the rabbit hole pretty far and I think I should be able to have something serviceable before too long. I do still think getting ESP-AT working over SPI/SDIO is valuable but I think it might be worthwhile to wait until Espressif brings back support for it.

In the meantime I'm focusing my work here: #98