ESP32 compatibility

[MkLHX]

Hi! Thanks for the lib and the work you make.

I'm trying to use it on ESP32, i see on code that ESPAsyncTCP is a dependency but it's for ESP8266 and the ESP32 have to use AsyncTCP

I try to make something directly on my own lib but without success.

There is any chance you make it compatible with ESP32 in future?

[JarrettR]

@MkLHX it seems to work (sort of) if you simply change all #include <ESPAsyncTCP.h> to #include <AsyncTCP.h> in all the library files. However, it seems to be causing heap poising after a few minutes of activity. Not yet investigated whether this is an issue with this repo, or AsyncTCP

[boblemaire]

You are in uncharted water. You may find the built in debug helpful.

On Jul 30, 2019, at 6:57 PM, Jarrett notifications@github.com wrote:

@MkLHX it seems to work (sort of) if you simply change all #include to #include in all the library files. However, it seems to be causing heap poising after a few minutes of activity. Not yet investigated whether this is an issue with this repo, or AsyncTCP

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[MkLHX]

@MkLHX it seems to work (sort of) if you simply change all #include <ESPAsyncTCP.h> to #include <AsyncTCP.h> in all the library files. However, it seems to be causing heap poising after a few minutes of activity. Not yet investigated whether this is an issue with this repo, or AsyncTCP

Hi @JarrettR, i tested this, but still crash my esp32 every time i call the lib's methods.

Since few hours, i fixed an other issue from arduino-esp32 sdkconfig file in platformio core. The WiFi feature looks working better. May have the time to try debug the lib with AsyncTCP instead of ESPAsyncTCP

[boblemaire]

I've started a project that uses this on ESP32, so I'll be working through issues over the next month or so. Stay tuned for updates.

[rljonesau]

I've been trying and finding that a core panic usually takes place within the IDF tcp code, and the stack back trace seems to suggest AsyncTCP may be to blame by using more closed slots than allowed after several client connects. This is using an esp-prog in JTAG mode.

The (un-commented) printed debug info seems to suggest that the FIN handlers never get called despite FIN packets being present in the Wireshark trace.

Will be interesting to find others experiences.

[rljonesau]

Have made some progress with my core panics.

Firstly I have added some bounds checking to all the places in AsyncTCP tries to use _closed_slot as an array index, this prevents badness in several places there - but the cause still needs to be understood:

if(msg->closed_slot >= 16 || msg->closed_slot < -1) {
  Serial.printf("CLOSED SLOTS BOUNDS!! _tcp_recv_api (%d)\r\n", msg->closed_slot);
  return msg->err;
}
if(msg->closed_slot == -1 || !_closed_slots[msg->closed_slot]) {
    ... 

I then still had random failures where it looked like a race condition during the connect / send phases of asyncHTTPrequest causing core panics. I solved that by altering the sample code to NOT call send() after open(), but hold that off until the request callback, adding a readyState = 1 condition:

void sendRequest(){
    if(request.readyState() == 0 || request.readyState() == 4){
        request.open("GET", "http://worldtimeapi.org/api/timezone/Europe/London.txt");
    }
}

void requestCB(void* optParm, asyncHTTPrequest* pRequest, int readyState){
    if(readyState == 4){  // response
        String JSONinfo(pRequest->responseText());
        Serial.println(JSONinfo);
        Serial.println();
    }
    if(readyState == 1) {  // connected
      pRequest->send();
    }
}

It has now ran for a good deal longer without issue, scraping a simple webpage for now.

The AsyncTCP closed slot issue is obviously not directly this library's fault, but needs to understood so it can be rectified. (eg: WTF is a closed slot anyway?)

[boblemaire]

I've started using asyncHTTPrequest in an ESP32 project. Now using the correct AsyncTCP library for ESP32 and have added a mutex semaphore to protect the data structures in multi-threaded operation. Seems to be working well now in my application (IoTaWatt). Have bumped version to 1.2.0 for ESP32 support. Assuming all will be fine with ESP8266 as nothing really changed there, but will update the ESP8266 version of IoTaWatt to use 1.2.0. Going to close this issue as most of this looks like it could be the thread corruption problem. Please file new issue if problems persist with this version.

[thecodingfrog]

Hi, I keep getting an error : Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Core 1 register dump: PC : 0x400556d5 PS : 0x00060130 A0 : 0x8205273c A1 : 0x3fcebe30
A2 : 0x00000000 A3 : 0xfffffffc A4 : 0x000000ff A5 : 0x0000ff00
A6 : 0x00ff0000 A7 : 0xff000000 A8 : 0x00000000 A9 : 0x00000000
A10 : 0x3fcb7f50 A11 : 0x3c15c740 A12 : 0x00000004 A13 : 0x3fcb7f54
A14 : 0x20544547 A15 : 0x00000000 SAR : 0x00000018 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x400556d5 LEND : 0x400556e5 LCOUNT : 0xffffffff

Backtrace: 0x400556d2:0x3fcebe30 |<-CORRUPTED

[boblemaire]

I'm not supporting this for ESP32. You can get async HTTP by running any client in a FREErtos task. My esp32HTTPrequest works for me in that environment.