ESP32 support (was ESP32 minimum version)

[sysopch]

I am integrating ESP_AT_Lib on a Spansion S6E2CCCAJ device connected to ESP32_DevkitC_v4.

The library initialization stops because the device reports minimal version 1.1.3 whereas the library expects at least 1.6.0.

If I understand correctly this version is that of ESP8266 AT fw. Can I just change the min numbers and expect everything works? What is the minimum version of ESP32-AT fw supported?

Is there a way to specify I am using ESP32 in lieu of ESP8266?

[MaJerle]

@sysopch ESP-32 is not supported.

[sysopch]

I see. I must say that this sentence

ESP AT is generic and advanced library for communicating to ESP8266 and ESP32 WiFi transceivers using AT commands from host MCU.

on this page

made me think that ESP32 was at least partial. Is there any plan for it?

I saw that there are various differences in the AT commands used. In theory I need to setup the network and create a TCP server for the moment.
Is it correct that I should change espi_get_reset_sub_cmd() to implement a different reset sequence and add the encode/decode for the different AT commands (e.g. "AT+CIPAP?" instead of "AT+CIPAP_CUR?") ?

Do you see any blocking/critical points?

Thanks

[MaJerle]

There is a big plan for it. In fact Espressif announced that they will merge esp32 and esp8266 firmwares to use same AT commands. Shall be already in this year.

Yes. You may do it this way.

[Nuck-TH]

Espressif seem to accomplished this in IDF AT v2.0, have you tried it and/or plan to support it?

[MaJerle]

Not sure I understood the same from Espressif. They shall migrate ESP8266 AT to ESP32-like using RTOS sdk. Up to now I do not see anything released for ESP8266, or am I missing something?

[Nuck-TH]

https://github.com/espressif/esp32-at/tree/release/v2.0.0.0_esp8266
and binary release in same repo

[MaJerle]

Yes, but this one is not compatible with ESP8266 firmware. What Espress said is that they will migrate ESP8266 to be compatible with ESP32. So once this happens, I will update ESP lib accordingly. Unless it won't happen, then I need to rethink.

[MaJerle]

See here: espressif/ESP8266_NONOS_SDK#205

[sysopch]

Hi, I actually made the changes I was hinting above and I am now using a modified version of ESP_AT_Lib to talk to a modified ESP-AT fw (extended with custom commands - the default commands are in a binary library and have not changed) for ESP32.
What I am able to do is configure the ESP32 in both Access Point and STA mode (alternatively) and allow incoming TCP connection from a PC to a custom server.

I tried to keep application-specific customizations isolated to some files and protected by configuration macros, but I am do not think the code is ready to be merged. If you guys are interested, I will try to clean it up from unreleasable code (if any) and upload it to a branch/fork
(I am not very familiar with github collaboration, please advise the correct approach).

Please take into account that I did NOT perform regression testing in Visual Studio or with ESP8266.

[tompie69]

Firstly thanks @MaJerle for this library. @sysopch I am also trying to use this library with ESP32. Would you mind sharing the code what you have done?

[sysopch]

OK, then I created the fork https://github.com/sysopch/ESP_AT_Lib.git and uploaded my changes to sysopch/esp32 branch. See README.sysopch.md in branch for details.

I noticed that @MaJerle has already done some work towards supporting different ESP versions in the master, I will look into merging those changes in the following weeks. For the time being my changes have been done starting from the state of the repo as of 4/4/2019.

[MaJerle]

Short update. During the weekend I managed to update my firmware on both, ESP32 and ESP8266 (NodeMCU) boards. This gave me some incompatibility as default setup for AT commands is not the same USB port as on NodeMCU so I have to use ext USB2UART converter. I didn't want to play with recompilation of default firmware, instead I downloaded one from Espressif website.

Currently I use:

• ESP32: AT based on RTOS SDK, V1.2
• ESP8266: AT based on RTOS SDK, v2.0

I have created a new branch on this repository, mainly for migration to new system and testing if everything works (and how it works). Once finalized, I will migrate temporary branch to main repo.

I follow this instruction set:
https://github.com/espressif/esp32-at/blob/master/docs/ESP_AT_Commands_Set.md

Source available under unified_esp32_esp8266 branch name.

So far I did not find any issues among devices, I was able to run same app code on both. So far... :)

[MaJerle]

@sysopch @tompie69 any feedback on that please?

[sysopch]

Hi @MaJerle, sorry about the silence, I was out of office and with limited access to internet.

I am going to integrate your changes in my version and give them a try.

[sysopch]

Hi all,
I did integrate the unified_esp32_esp8266 branch and reapplied my customization for SDspi and custom commands: all appears to be working on my side (further tests are in progress).

It took more than expected, also because we use svn internally and I tried to setup a git repo to better track my changes vs official version.

I have a problem to correctly implement ESP_CMD_RESET and ESP_CMD_RESTORE in SD-SPI mode.

Establishing the serial communication with ESP32 in SDIO in SPI (SD-SPI mode) requires SDIO initialization commands to prepare the ESP32 module to receive the actual SDIO commands encapsulating the AT commands.
I usually execute this sequence after powering up the board, before invoking esp_restore().

The implementation of ESP_CMD_RESET and ESP_CMD_RESTORE conflicts with this approach as it resets the ESP32, invalidating the SD-SPI setup pattern.
My solution has been of disabling these commands, implementing the subcommand as a no-op, but keeping the .cmd_def command invokation to keep the startup state machine with subcommands in place. This works because RESTORE expects a "ready" reply which occurs after power up, even if the restore command itself was not executed.

However this solution is far from ideal, suggestions?

[MaJerle]

Can you make a pull request with you changes? Im not sure if I completely understand how did you implement this.

[sysopch]

I put the changes related to the special SDSPI configuration in the 'device_needs_configure' branch and opened pull-request #45 .
You can't compile this but it should give you an idea of what I did. I also took the chance to document the startup procedure, see the following picture.

I am using the esp_device_set_present() both for mapping the powered ON/OFF state to trigger the actual power on and initialization with a new esp_ll_configure_device() API call. (Maybe this can be integrated into esp_ll_t)

I hope it is more clear now.

[MaJerle]

Now lib supports ESP32 AT V1.2