You might want to consider an ESP32 platform, which is more "future proof".
They're dual core, so much of the infrastructure stuff (WLAN, serial, etc.) is handled by the core separate from the core running your stuff. And, it runs much faster. So that makes the timing easier.
Downside is that it's not as mature a platform, so there's a bit more work there.
But the change isn't very hard. I'm working on a project where I've gotten a single codebase which works with both by using #ifdef [arch] to accommodate the library differences. Wemos mini D1 pro and ESP32-WROVER-B (16MB). There's way more "headroom" with the WROVER.
Hi Mike, you're right. I've been waiting for the ESP32 to mature a bit and become cheaply and easily available, I'm surprised how long it has been taking. I'm hitting the ceiling again on the ESP8266 when doing things like multiplexing and handling web requests at the same time.
I'm also looking forward to things like capacitive touch sensors and the extra GPIOs. At the moment I'm getting extra pins using 595s, which works great, but is a bit of a sweat.
Still very immature in my opinion. I just started exploring how feasible it would be to move over to this and almost instantly hit a snag with captive portal behavior (using AsyncWifiManager, though the issue is not with AsyncWifiManager). The answer was a fix to esp-idf (
), which was not rolled in to the 1.0 release of the arduino platform. It got rolled in to master shortly after I submitted a ticket. So to be able to implement a captive portal with ESP32, I have to use master of
As far as I know, AsyncWifiManager is also the only wifi manager to fully support the ESP32, which says a lot about 3rd party library support.