ESP32 Dual Core Wifi ?

[greycon]

I am working on an ESP32 based data logger (Only temperature in the first instance.) It takes a reading and POSTs it as JSON to a server - all working fine. Now I want to add a HTML server on the ESP32, so a user can browse to the device and see a table of readings for the sensor. I have been using the ESP32 Arduino classes, but I'm going to switch to IDF and RTOS - I prefer to use RTOS.

I was wondering what would happen if the device was in the middle of the POST (Takes about 1 to 2 seconds.) when a user tried to connect on an incoming HTTP call. Would it get dropped? Or does the WiFi HTTP Server class buffer such data.

But my real question is, would it be feasible (even advisable) to run the HTTP Client code (Responsible for POSTing out data) on 1 core, and the HTTP Server on another? Would the cores share the WiFi hardware nicely? I realise it's probably way overkill, but I'm in big time learn mode here (New to ESP32 - plenty of experience with NXP)

Hope someone might have some experience / opinions here that you might share. Thanks.

[username]

But my real question is, would it be feasible (even advisable) to run the HTTP Client code (Responsible for POSTing out data) on 1 core, and the HTTP Server on another? Would the cores share the WiFi hardware nicely? I realise it's probably way overkill, but I'm in big time learn mode here (New to ESP32 - plenty of experience with NXP)

The cores will share the hardware nicely. I have an http server on Core 1, and a telnet server on core 0. works like a champ.

[MicroController]

would it be feasible (even advisable) to run the HTTP Client code (Responsible for POSTing out data) on 1 core, and the HTTP Server on another

Feasible? - Maybe.
Advisable? - Not at all.
In this case there is nothing to be gained by restricting the way FreeRTOS may allocate available CPU time. Leave the tasks 'unpinned' and let FreeRTOS freely schedule them to the cores.
Most of the IDF and its libraries is perfectly multi-tasking capable. Notable exceptions are only things like hardware setup/driver initialization which cannot be done concurrently by different tasks; these cases are usually noted in the documentation.
Specifically, the HTTP server and client won't interfere with one another; the underlying layers of network drivers transparently take care of all necessary synchronizations.

As to the feasibility: The HTTP server (maybe also the client) creates its own private management task under the hood which won't let you control on which core the HTTP heavy-lifting runs. While you can control on which core your application's task runs, that task may or may not be where most of the processing of an HTTP request actually happens.

There are reasons why some tasks must be pinned to a specific core (accessing RTC FAST Memory and certain interrupt allocations come to mind), but in most other cases you get better results by not hindering the OS's scheduling.

[greycon]

Understood, loud and clear - and thanks. I've been digging in a lot, into documentation and code since I posted this, and it's become much clearer to me. I have to say I am extremely impressed with the Espressif IDF, the Eclipse Plugin, the sample code, the community support - amazing.

I've worked in recent times with some other SOC providers, slightly higher-end hardware, but the documentation and support is not a patch on the Espressif world.