ESP3D 4.X new features / improvement

[luc-github]

This discussion is about new expected features in addition of current open topics if they are not integrated in 3.X version, even it is not for short term it is always good to think about futur

• I plan to keep current communication same as 3.X - I think the json and text is now quite stable , clear and efficient, so no need to change/document it but add new features.
• While 3.X will keep ESP8266 support - I think we reached the limit in space and performances for new features so I plan to drop support of ESP8266 which will simplify a lot the code
• Add plugin feature is something that could be nice, there is already lua support but it may not fit all needs when a C/C++ code can, I already have some ideas that will rely on hooks in different part of the code thank to smart grblHAL current plugin system.
• Move from Arduino to espressif IDF is something I may consider, because of ESP3D-TFT the merging could be done but in that case the ESP3DLib code coul not be same, from another point of view many features in ESP3D are not used in ESP3DLib when they are in ESP3D-TFT so it could be a code simplification for ESP3DLib actually (no need streaming support , no need screen support, no need multiple firmware support ,etc because everything is handled by Marlin itself which is the only fw using ESP3DLib

Any Ideas / Constructives Feedback are welcome as usual , thank you

[luc-github]

Another big change is may be to migration to RUST instead of C++, it seems the futur for ESP32 development, more and more resources exists: https://docs.esp-rs.org/std-training/ , https://github.com/esp-rs
The idea would be to go to https://github.com/esp-rs/esp-hal (no std ) to keep the firmware size as small as possible or at least same as current size

Does anyone has feedback on RUST, not necessarly on esp but general point of view ?
What I understand about RUST vs C/C++:

Memory Safety Superiority

• Compile-time guarantees: Ownership/borrowing system eliminates dangling pointers, memory leaks, and data races.
• No garbage collector: Performance equivalent to C/C++ without runtime overhead.
• Impact on firmware: Reduces critical crashes (70% of Chrome security bugs stem from memory issues in C/C++).

Reliable Concurrency for Dual-Core

• Thread-safe model: Static verification of concurrent access patterns, critical for ESP32's dual-core architecture.
• Native async/await: Better I/O handling than C-style callbacks.

Embedded Optimization

• no_std by default: Minimal binaries (~20KB vs 100KB+ in C++ with libraries).
• Direct hardware control: Low-level MMIO register access.
• Aggressive LTO: Code size reduced by 30-50% vs standard C++.

Modern Ecosystem

• Cargo + ESP-RS: Integrated dependency management (esp-hal, esp-idf-hal).
• Hardware-focused docs: ESP32-specific examples (WiFi, BLE, coprocessors).
• Unified toolchain: espup simplifies setup vs CMake/ESP-IDF.

Long-Term Maintainability

• Safe refactoring: API changes detected at compile time.
• Built-in testing: Native hardware-in-loop testing with probe-rs.
• Active community: Major contributions from Espressif and Ferrous Systems.

Critical Case:

A Rust ESP32-C3 firmware shows 1.5x fewer runtime errors than its C++ counterpart after 6 months, with comparable memory footprint.

For safety-critical firmware, Rust reduces risks while maintaining raw C/C++ performance – explaining its growing adoption in embedded systems.

[luc-github]

the https support will be a major new feature, it will allow to add another feature : brotli compression support , the brotli support is now ready for 10 years on most of modern browser but on all web browsers the brotli support is limited to https ...
the inital tests show a current 93KB index.html.gz will become 58KB which is a huge improvement but still need to confim this file is still working when https is implemented ^_^ but sound promising

[kleffa]

maybe a great great upgrade should be a way to control 3D printer remote, like a MTTQ service with Home assistant
esp32-cam can send notification with pictures and yes, the famous ping pong stuff

[elbuglione]

You only need to focus on one feature: adding the ability to run GCODE as proposed by jamespearson04's fork.
any other attribute or new tool is practically an ornament.

[luc-github]

Why is so important ?

[elbuglione]

This feature puts ESP3D in direct competition with Octoprint at a fraction of the computational and energy cost.

[luc-github]

if you think an ESP board can compete with a raspberry PI you are wrong - hardware capabilities differences are huge, constraintes are differents, and even when this feature will be will implemented (#243) it will come with several limitations in usage.

and FYI great jamespearson04's work is already implemented in https://github.com/luc-github/ESP3D-tft and it does not work as it should due to hardware performance, but bring a lot of knowledge and informations - so need a complete rewrite with new approach - which is planned

[elbuglione]

Look... I think the ESP32cam is more than enough to handle printing as long as it's done via UART at 250,000 baud (I just implemented it that way and it works perfectly).
Perhaps it would suffice to assign the main execution core exclusively to the SD card reading and "printing" function; and everything else running on the second core. This would ensure that no "ornament" interferes with what's important.

[luc-github]

ho so you already have a reliable working solution ?
how do you stream gcode and video without impact print quality ?

[elbuglione]

I don't have a working solution... otherwise I would have uploaded it already.
I'm just throwing out an idea that I'm pretty sure would work.
Maybe the video streaming won't have a very consistent FPS, but who cares... it's not like it's such an important feature.

[luc-github]

man you give me advice on how to do things - I would expect you know what you are doing - not guessing it would be ok

[elbuglione]

You're right. Just ignore me.