-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swap webserver to PsychicHttp #3724
Comments
Difficult as WLED still supports ESP8266 and this seems to only support ESP32. |
I think 8266 support should really be ended. It was never intended to be used as a general purpose MCU, so while it's amazing what you can do "by accident" to hold back development just to maintain support for a platform that was never meant to exist seems wrong. I don't know enough about PROGMEM to comment on why this is used current and what the impact of the lack of support for it would mean |
I've started having a quick hack about to try and judge how hard the migration would be #3726 |
To me, telling people to throw out their existing hardware and buy new boards because some software developer can't be bothered to do the legwork also seems wrong. ;) I'm a couple issues away, but doing something about the web server is on my hit list - ESPAysncWebserver, while clever, seems to have no capability to limit its resource consumption and responds to failure by, well, crashing. I had been planning on sketching a queuing mechanism to put some bounds on it, but replacing the server code outright might be just as effective. FWIW, the PsychicHttp dev has gone on record as being willing to accept ESP8266 patches. PsychicHttp is built on some HTTP server code from the ESP-IDF; it looks like there's some version of it available for ESP8266, in some kind of zombie support state. I'll do some investigation on how easy that code is to get at; I'm still finding my way tracking through the various platform support layers and development repos.
The web pages, js files, etc. used in WLED are embedded as arrays in the firmware binary. Some micros (such as the ESP8266) require different CPU instructions to read constants or data from out of the firmware (aka "PROGMEM", since it's where the program code lies) than from regular data RAM. The trick is usually recognizing a special type ( TL;DR: @netmindz: if you want to sketch a WLED branch with PsychicHttp, I'd be happy to take a shot at getting it to work with ESP8266s. |
It's not a lazy choice, it's a practical issue of lack of support as it was never intended to be used in the way. As for throwing stuff away, you can now get esp32 boards for a couple of dollars and they would only need to do that if they wanted to upgrade to new software. In almost all software development minimum hardware specs go up over time Maintaining two different implementations for different platforms comes at quite a significant development cost. It's possible that replacing the hot garbage that is the current webserver might give new life to the 8266 if you are able to help get this library to add support, but if you can't, then having a functioning webserver is more important to my eyes than supporting obsolete hardware indefinitely |
All WLED HTML files are converted into PROGMEM strings and served from there. For ESP8266 I would not throw it out of the window just yet, though it struggles after 0.14. :D But I would not rule that out either. |
While WLED uses a patched version of the ESPAysncWebserver, there are so many issues with performance and stability that relate to the webserver
If this library lives up to it's claims of delivering much better performance, reduces chance of crashing and has similar API, then it's worth investigating
ArduinoMongoose could be another alternative, but it's API is quite different to the existing library
https://github.com/hoeken/PsychicHttp
The text was updated successfully, but these errors were encountered: