Features request MCU support for ESP32

megablue commented 6 years ago

The idea primarily is intended for supporting a "wireless" setup for the hotend/extruder, so that most of the wires are coming from a secondary board instead of the primary board. with ESP32 we can pretty much just hook up a couple of mosfets and stepper driver to decouple the hotend/extruder electronics, leaving just the power cable required.

KevinOConnor commented 6 years ago

Certainly would be nice. It doesn't appear anyone is actively developing this though, so I'm going to close this issue for now.

jeffeb3 commented 6 years ago

There's something interesting about the ESP32 as a microcontroller, and Klipper appears to make it pretty easy to do. As @KevinOConnor said, there aren't any ESP32 boards that I've seen, at least for 3D printing. I think that's because even though there are "32 GPIO pins". 8 are input only, and several more have different restrictions (6 are used for external flash, 2 are used for the UART, 2 are used in selecting the bootloader). Klipper could help with this, because it's so flexible in it's implementation. Making an ESP32 board with an SPI GPIO to enable all the steppers, for example, or making a board with a multiplexer/shift register for some of the pins is a lot easier if you have a python controller to work out all the bugs with. Or, the ESP32 printer could be made with two MCUs, controlling different aspects of the printer, but only Klipper supports that. I sure would enjoy seeing a stack of MCUs with one for motor control, and one for a few extruders and heaters.

Correct me if I'm wrong, but making Klipper work for the ESP32 would be pretty easy, except that Klipper manages the build process and compiles the microcontroller code, and the ESP32 is a PITA to compile, requiring a lot of different tools that aren't common with the other boards. If Klipper started using platform.io under the hood for doing it's compilation, with a build step for it's preprocessing of the MCU and it's dictionary, then supporting weird boards like ESP32 would be easier, maybe... maybe that would just be another thing to manage.

So it's a catch-22, because an ESP32 printer board can't really exist without Klipper and Klipper won't work with ESP32 unless there's a good user base (and since there are zero boards...).

Add on top of that, what is the point of the ESP32? The wireless control from Klipper would be nice, but is the latency low enough and predictable enough to do anything useful? Certainly not stepper movements (even the extruder), so maybe the heater/Bed PID could move to that chip? It's a fast dual-core CPU, but with Klipper, 8 bit MCUs scream. Maybe it could handle a nice display/controller in addition to some printer functions? If you really want that, then a ESP32 connected to Octoprint via wifi has a lot more interesting information available.

I'm sort of dumping these thoughts here. I've been thinking about something like this. It's really attractive and interesting, but I think I have resigned to giving up. It seems like it just doesn't make sense. Unless someone really had a unique use case, and wanted to make a system that was coupled between ESP32 and Klipper.

hg42 commented 6 years ago

I see several types of Klipper systems and reasons to use them:

use Klipper because of it's features and the convenience of coding most features in python
use a very modular system where each axis, each extruder, each heater has it's own (cheap) MCU
use one (powerful? 32bit?) MCU to control movement and a cheap board (Nano, stm32f103 minimum) for slow tasks
give much more power to existing boards with already good but slow hardware (usually 8bit like RUMBA)
use Klipper to easily scale up existing systems e.g. if you need a lot of extruders or a lot of motors etc.

The typical ESP32 boards are very similar to STM32F103 boards that are cheaper, and it's main attractive features like WLAN don't matter with Klipper (I think). So, at this point I don't see much demand for that.

I agree, that platform.io would be a good way to manage compilation and external libraries etc. and would benefit from the community and solutions behind it. This would especially be of advantage if the number of targets increases (see Marlin that already benefits from it). I thought of trying platform.io myself but didn't start yet (mainly because motivation is currently not strong enough and there are more important things in my queue). I think a switch to platform.io will eventually take place if someone demonstrates that it's working. Note, many people think platform.io is a kind of IDE, but I see it mainly as a script front end to the underlying tools and libraries unifying operations like compilation.

mmone commented 6 years ago

Why make your live hard and select a, in the context of a 3D printer controller, very limited part. In terms of cost the MCU contributes only a fraction to the overall BOM cost of a printer board. And as far as Klipper is concerned the networking is contributed by the Pi anyhow.

FolkertRA commented 5 years ago

Now almost a year later, has anyone made an attempt to port Klipper to ESP32?

I see an interesting application: a semi-wireless print head, e.g. for Delta printers. Main features:

ESP32 communicates with a Raspberry Pi running the Klipper host software over a bluetooth serial port.
Only 2 wires for 12V/24V power
ESP32 interfaces with all peripherals on the print head: extruder heater(s), thermistor(s), fan(s), Z-probe

jakep82 commented 5 years ago

The Z-probe cannot be on a separate MCU. It must be on the same MCU as the drivers that control the Z axis. For a delta, this means it needs to be on the same MCU as the A,B, and C steppers.

I also personally wouldn't trust a wireless interface to control my hotend. A USB or serial connection would be much more reliable, and it only adds one more cable. The rest of this could be accomplished with already supported hardware.

FYI a prototype effector board that does all this and uses an atmega328p already exists. See the link for a video of the first print.

https://youtu.be/_6tTcTtLdDA

jubjub64 commented 4 years ago

Somebody has started to develop boards that fit an ESP32: https://www.tindie.com/products/33366583/grbl_esp32-mpcnc-cnc-controller-ver-121/

It was created for GRBL and the MPCNC but couldn't this work with Klipper too?

MCTaylor17 commented 4 years ago

FYI, Bart Dring, the same person @jubjub64 mentioned just released a new beast of a board: https://youtu.be/IMwXUbWLic0

@jeffeb3 mentioned using a shift register which seems to be the enabling aspect of this. To quote Bart's blog post on the subject:

Recently, support for I2S shift register chips has been added to the firmware. The shift register scheme supports high-speed (125 kHz step rate), jitter-free stepping with up to 32 output pins (28 on this board due to connector limitations). To show off this new capability I designed the universal controller I always wanted. A universal CNC controller covers a huge variety of options so I quickly realized I would have to add some modularity to the design. This would allow you to pick the features you wanted and not have to pay for the ones you don’t need. It would also allow for some amount of future proofing. As new requirements are identified, new modules could be added.

Given the recent trend towards tool-changing machines for multi-material extrusion, I see the 6 stepper driver slots as really compelling. Furthermore, interest in multi-purpose solutions like E3D's Additive & Subtractive Manufacturing By Layer (ASMBL) solution (released yesterday!!) are likely to keep growing as small scale fabrication continues to evolve.

Based on initial response and my own excitement, I have a feeling this board is going to be quite successful. I'm not sure how quickly it will be adapted to 3D printing, but it probably won't be long. That's not to mention the wave of purpose built derivatives likely to follow. So if popularity is a metric as mentioned above, that might be satisfied relatively quickly.

Long way of saying, with all the recent changes, it might be worth giving this a second look.

IXMAN89 commented 3 years ago

Hi,

Is there something new about ESP32 support for Klipper. Fysetc has launched their E4 board with ESP32. I would like to use it for a project.

Greetings Ixman

beikeland commented 3 years ago

E4 board is looking interesting now, but will it be as interesting when chip shortage passes in 6-18 months? Klipper wont ~need~ use the wifi function presumably?

chmondkind commented 3 years ago

Hi there

I‘ve been considering an ESP32 with a short μPython script to enable the printers main supply and also the hotend cooling fan. The fan should have an RPM feedback and a thermocouple would measure the temperature in the hotend itself. This would provide the possibility to control fan rpm: -low setting for „startup“ -PWM ctrl when printer in operation -emergency shutoff of the printer and cooling if temperature exceeds a given value (100C as example)

It may be over engineered, but I‘m a friend of redundant hardware for safety-relevant parts and functions.

This could be extended for hotbed and chamber temperatures as these can be solid-state controlled and two relais in series is safer than just one.

I got this idea when I started going down the water cooling rabbit-hole.

marcboivin commented 3 years ago

Ordered a bunch of ESP32-D0WDQ6-V3, read the entire spec sheet. Looks manageable. Keep you posted once I get my dev board.

I have a very specific target in mind, I want to do a CAN board for my hotted assembly. So no Bluetooth/Wifi here. I'm looking at 2-4 years of BO on all ST products. Hope to have something before that ;)

marcboivin commented 3 years ago

Ok so this things runs FreeRTOS. Compiling a simple GPIO example is a significant compilation undertaking (ressource wise). I'll see if I can port stuff from the GRBL fork, but let it be known that compiling this thing on a RPi, if we include FRToS support will take way more time then your regular STM32.

mpalpha commented 2 years ago

This looks like some progress in the other direction. https://github.com/dinosauria123/StacKlipper

beikeland commented 2 years ago

This looks like some progress in the other direction. https://github.com/dinosauria123/StacKlipper

Looks like a tcp/ip connection to moonraker and not a klipper implementation - but it might serve the purpose for some i guess.

cinehorse commented 2 years ago

I hope we get a ESP32 support. This Board is very nice: https://www.pandapi3d.com/product-page/pandacan-extruder Is Board with CAN Interface and CAN works perfect. with Klipper I have upgrade my Ender 5 pro with the BIQU HermitCrab CAN Version. Great. Now only one USB-C Cable goes to Printer Head. I love it

Darkstar77 commented 2 years ago

MKS Tiny Bee, based on ESP32, very interesting little board: https://github.com/makerbase-mks/MKS-TinyBee

Rmdhn1 commented 2 years ago

@Darkstar77 i just want to add that the Tiny bee is built on the work of the MRR team the MRR ESPE, and MRR ESPA are mostly just experimental and research focused, so it's interesting to keep up with them, UART support for TMC2209 is also already available for up to 4 drivers https://github.com/maplerainresearch

rocknstorm commented 2 years ago

though it is a popular board, it is really weird that there is still no solution to make it work with klipper.

marcboivin commented 2 years ago

though it is a popular board, it is really weird that there is still no solution to make it work with klipper.

Because the toolchain. Everything is needlessly wrapped up and they can't support standards to save their lives.

HessianZ commented 1 year ago

still waiting

Sineos commented 1 year ago

still waiting

Interesting information. Does this mean a) You are working on implementing it and will hand in a PR soon? b) You are willing to finance the development with an external developer? c) If neither a) or b) return to waiting 😉

marcboivin commented 1 year ago

The marling guys have done all the patching required to build onto an ESP32

https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.1.x/Marlin/src/HAL/ESP32

It's basically a blueprint for all the shady stuff one would need to do in Klipper.

indyjonesnl commented 1 year ago

Can we add some more structure to this issue and its eventual solution / implementation? Something like a checklist of all hurdles / roadblocks in front of us.

I'm not super familiar with the Klipper codebase (yet), I am missing an overview of the requirements to get the generic MCU code to work on ESP32 (and thus where and how we need non-generic logic added). I have an ESP32 development board and the MKS TinyBee (which is limited to Marlin for now). Wondering how I can help to get Klipper working on the target arch. If anyone could bulletpoint a rough route to a possible solution, I'd be happy to test, build and debug my way to a PR.

marcboivin commented 1 year ago

The main hurdle is to re-implement the non standard interfaces the esp has. Look at what marlin did, it's a good starting point. The reason I didn't do a list it's because point 1 is something like:

Read the esp example and interfaces and re-implement them for klipper.

Other thing is esp uses 2 cores, and some form of real time processing. So we propably need to mess around with that too.

Once again, the stuff the Marlin community did looks promising to figure out what we need to interface

jeffeb3 commented 1 year ago

The mcu docs list out all of the commands the mcu needs to handle:

https://www.klipper3d.org/MCU_Commands.html

But there is probably some decent infrastructure in place for other mcus. Part of the question is, is any of it reusable? If not, we need a lot of work done to impoement all these functions with the esp hardware.

shodanx2 commented 1 year ago

Hello, I'm interested in making this happen ESP32 is an excellent fit for driving stepper, it is one of the fastest MCU you can buy under 5$.

The ESP32 is the favourite MCU of the arduino community, it is very well documented how to do basically anything and there are tons of libraries available, surely this covers everything happening inside a 3d printer.

Now, the espressif toolchain, no idea about using it directly, I've always just used the arduino IDE, it still very fast and takes care of all the nasties for us.

Is there an objection to doing all of this in an arduino sketch ?

As a bonus, it would basically support the RP2040 with the same code.

As for physical hardware, the Makerbase MKS Tinybee looks great and at 22$CAD, including the MCU, that is not a price I could possibly beat.

However I see that this board supports Marlin out of the box.

So first question that should be answered, should I just use Marlin ?

Well, to answer this, I'm going to buy that board, hook it to my printer use Marlin and see whether I need to try Klipper !

andremalenfant commented 1 year ago

Well, whole point of the thread is to put klipper on an ESP32, so... I personally don't like Marlin's architecture. At this point it becomes more a question of preference than hardware.

As for Arduino, I would stay away. I am a software engineer, so I have a bias. The main reason is Arduino is an abstraction layer to simplify coding so it trades functionality for simplicity. The ESP-IDF opens up the door to FreeRTOS. Code is task/event driven instead of built around a loop. You get control over multithreading, interrupts, etc. It can be leveraged with Arduino, but there is no point other than mixing different library models and making a big mess. Again, that depends on your proficiency in coding and the goal you want to achieve.

Plus, I have so far been impressed with the integration of ESP-IDF with VScode. Worked flawlessly for me and the Arduino IDE is a pain. Granted you can use Arduino in VSCode, but it's not fantastic.

jeffeb3 commented 1 year ago

You can still write tasks in arduino and access freertos. If you look at the board manager code, it just calls setup() in main() and then calls loop() inside a task.

I would prefer an implementation using esp-idf and platformio. But someone just needs to take the first step. Any step. If we had something working in arduino, someone will come back later to add a feature arduino can't do and switch it over. There will be a few hurdles, but nothing major.

The MVP can be something simple. It does not have to be perfect the first time. As long as we are honest about the limits of a first draft, people can accept the risk, and it will continually get better.

Whoever writes it first can choose the first arch.

Sineos commented 1 year ago

If such an extension wants to have the chance to be included in Klipper main line, then it needs to follow Klipper's philosophy of including new MCU hardware. Without being the expert or having the last call on such:

Pull in as few as possible external dependencies
Typically do not use the high abstraction these SDKs are using, i.e. going down 20 levels until you reach the actual hardware layer
Be as close to the hardware as possible

Perfect example for this is likely the RP2040 code (https://github.com/Klipper3d/klipper/tree/master/src/rp2040). Go ahead and compare these "few lines of code" with around 183000 lines of code from the pico-sdk

creatormir commented 1 year ago

The main feature is that esp32 has 2 240 MHz cores. You can run many slow tasks on one core, and one/two tasks on a second core. In FreeRTOS, a separate task is created, any interrupts are disabled, and you get a loop without interrupts.

void IRAM_ATTR Core1( void* p) {
    portDISABLE_INTERRUPTS();  

    for (;;){
    }
    vTaskDelete(NULL);
}
TaskHandle_t Task_1;  
    xTaskCreatePinnedToCore(
        Core1,       // Function that implements the task.
        "Core1",          // Text name for the task.
        4096,      // Stack size in bytes, not words.
        ( void * ) 1,    // Parameter passed into the task.
        configMAX_PRIORITIES -1, // tskIDLE_PRIORITY+2,
        &Task_1,
        1 // Core 1
    );

Giuseppe499 commented 1 year ago

What steps should someone take to implement a new MCU? There is some documentation about this task?

I would like to implement support for esp8266 and maybe esp32. I would like to use an esp8266 and a mpu6050 together as a USB accelerometer like the KUSBA.

victorhalla commented 1 year ago

In my point of view, bringing ESP32 to klipper would open up many possibilities, however integrating it at this point will require a lot of effort so that the firmware generation process follows the same current process. One option would be to build an independent firmware that communicates through the Klipper protocols (MCU Commands), this way the firmware would be outside of Klipper and its construction would follow the normal ESP32 standard. One possible use would be communication between the Klipper and the ESP32 MCU via Bluetooth.

Giuseppe499 commented 1 year ago

@victorhalla That would be an interesting approach. I've seen a basic implementation of this made in Rust but I didn't test it yet. Here is the link if someone is interested. I think that this could be the best approach for now but I would like to reimplement the firmware in C++ or C using the ESP SDK. Right now I am hesitant to invest time in this as @JamesH1978 said on discord

there is a reason these are not a klipper mcu, no wireless support, bad timing and latency. a whole world of hurt

and also

i very much doubt it would be fast enough or the timings good enough for accelerometer measurements

Considering that my use case would be accelerometer measurements, for now, I think I will not try to port klipper to esp8266 or esp32. I will just buy a rp2040.

ulope commented 1 year ago

Right now I am hesitant to invest time in this as @JamesH1978 said on discord

there is a reason these are not a klipper mcu, no wireless support, bad timing and latency. a whole world of hurt

AFAICS this was directed at the esp8266 which is pretty ancient at this point. The various ESP32s should out-perform an RP2040 by near enough an order of magnitude.

victorhalla commented 1 year ago

@victorhalla That would be an interesting approach. I've seen a basic implementation of this made in Rust but I didn't test it yet. Here is the link if someone is interested. I think that this could be the best approach for now but I would like to reimplement the firmware in C++ or C using the ESP SDK. Right now I am hesitant to invest time in this as @JamesH1978 said on discord

there is a reason these are not a klipper mcu, no wireless support, bad timing and latency. a whole world of hurt

and also

i very much doubt it would be fast enough or the timings good enough for accelerometer measurements

Considering that my use case would be accelerometer measurements, for now, I think I will not try to port klipper to esp8266 or esp32. I will just buy a rp2040.

I have been working with serial connections via Bluetooth for a long time and have never had any problems with data loss. The RFCOMM protocol itself already has features that reduce errors so it's pretty reliable . Latency is generally low and I don't think it would be an issue. My idea of use would be an ESP32 MCU for the extruder connected to the Klipper (PI) via a Bluetooth Serial connection. This model would allow the use of only 2 wires for power supply, as everything else would be on the board (fan, adxl, extruder, hont end, etc.) Very interresting the Anchor because it may simplify the process...

chrisalbertson commented 9 months ago

Right now I am hesitant to invest time in this as @JamesH1978 said on discord

there is a reason these are not a klipper mcu, no wireless support, bad timing and latency. a whole world of hurt

AFAICS this was directed at the esp8266 which is pretty ancient at this point. The various ESP32s should out-perform an RP2040 by near enough an order of magnitude.

The Raspberry Pico is very fast if you don't need to do floating point math. It also has two cores.

The reason I have a 3D printer is to suport robotics projects. Robots are not unlike 3D printers in that they have many motors that must run in realtiime.

I just implemented a simple RP2040 controller that has a klipper-like architecture. My Python software runs in a Pi4 and sends commands (via I2C or UART) to the RP2040 were they get placed into a table (one row per motor) and executed.

I separated the RP2040 software into two parts. Part 1 handles comunications which is very "klipper-like" and HDLC-like and managing the table, keeping entries up to date with new commands from the Pi4. and Part 2 handles running ther motors based on the content of the table.

Each part runs on its own core. So the running of the motors never hangs because of waiting on a serial port or handling communications errors the motrs run on a "very-hard" realtime loop and the communications runs on a "sort of hard realtime loop.

In is all written in "micro python" and not any C at all. Micropython is unlike cpython in two ways 1) there is no GIL and you can do actual multiprocessing on multiple cores 2) it ca optionally be compiled to executable code and is nearly as fast as C. Yes you have to give up some dynamic Python feature if you want to compile but the choise is very granular and not either/or.

Now to the point. I test the on both ESP32 and RP2040 and only change pin assignments. Both are very fast.

I would not sujgest using Micropython on Klipper MCUs. My comments are only that 1) there is much to be gained byu iusing both CPU cores and 2) the RP2040 is nothis at all like "an order of magnitude slower" thern ther ESP.

MR-VENOM commented 7 months ago

@chrisalbertson did you manged to run klipper on esp32 ?? can share some details or the source code for the same.

DragarX commented 6 months ago

@chrisalbertson did you manged to run klipper on esp32 ?? can share some details or the source code for the same.

ESP32 and Pico both can run the same C++ code, so I assume you'd just compile a binary file for the esp32 with the same settings as the pico, then setup the pin assignment in klipper itself.

chrisalbertson commented 6 months ago

No. I have not been working on Klipper. I am still a rather new Klipper user. But I have lots of experience with this kind of software. I have been wanting to look into the Klipper source code. I’ve been wondering if the second core of the RP2040 is being used. If not I’d find a why to use it.

ESP32 is interesting because it is very fast and also dual core.

Why does it need to be fast? My LED animations seem to use 100% of the RP2040. This is just plain silly. I suspect it is “bit banging" with one core. Both ESP and RP2040 have on-board hardware to do the bit timming for addressable LEDs. But this is way down on the to-do list.

I’m using bnoth RP2040 and ESP32 for robotics, driving BLDC motors.

On Apr 27, 2024, at 10:12 PM, DragarX @.***> wrote:

@chrisalbertson https://github.com/chrisalbertson did you manged to run klipper on esp32 ?? can share some details or the source code for the same.

ESP32 and Pico both can run the same C++ code, so I assume you'd just compile a binary file for the esp32 with the same settings as the pico, then setup the pin assignment in klipper itself.

— Reply to this email directly, view it on GitHub https://github.com/Klipper3d/klipper/issues/199#issuecomment-2081332300, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQKNRT57X6NBY3JSBMBB6DY7SALLAVCNFSM4ESX5EG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBYGEZTGMRTGAYA. You are receiving this because you were mentioned.

nikhil-robinson commented 6 months ago

@chrisalbertson did you manged to run klipper on esp32 ?? can share some details or the source code for the same.

ESP32 and Pico both can run the same C++ code, so I assume you'd just compile a binary file for the esp32 with the same settings as the pico, then setup the pin assignment in klipper itself.

My attempt to make klipper work on esp32 : https://github.com/nikhil-robinson/klipper_esp32

The comands work fine and my esp can talk to klippy through uart. Tested on esp32 esp32h2 esp32c3, only problem is I had to hardcode the the compiler_request.txt file for esp because of the diffrent build system others than that it's fully flexible.

nikhil-robinson commented 6 months ago

No. I have not been working on Klipper. I am still a rather new Klipper user. But I have lots of experience with this kind of software. I have been wanting to look into the Klipper source code. I’ve been wondering if the second core of the RP2040 is being used. If not I’d find a why to use it. ESP32 is interesting because it is very fast and also dual core. Why does it need to be fast? My LED animations seem to use 100% of the RP2040. This is just plain silly. I suspect it is “bit banging" with one core. Both ESP and RP2040 have on-board hardware to do the bit timming for addressable LEDs. But this is way down on the to-do list. I’m using bnoth RP2040 and ESP32 for robotics, driving BLDC motors. … On Apr 27, 2024, at 10:12 PM, DragarX @.***> wrote: @chrisalbertson https://github.com/chrisalbertson did you manged to run klipper on esp32 ?? can share some details or the source code for the same. ESP32 and Pico both can run the same C++ code, so I assume you'd just compile a binary file for the esp32 with the same settings as the pico, then setup the pin assignment in klipper itself. — Reply to this email directly, view it on GitHub <#199 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQKNRT57X6NBY3JSBMBB6DY7SALLAVCNFSM4ESX5EG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBYGEZTGMRTGAYA. You are receiving this because you were mentioned.

The klipper firmware will only need one core to work for. I am planing to use the esp32 one core for running klipper and another one to act as am NIC for the klippy soc via spi/sdio so that th3 pcb footprint will be less and I can save a lots on components.

shodanx2 commented 6 months ago

Hi,

Earlier in this thread there were people asking if esp32 firmware could be built without the ESP's IDF firmware.

I believe youtuber cnlohr youtube.com/@CNLohr has a IDF-free SDK with extremely fast compile and flash time.

I'm having difficulty finding the exact repository at the moment but ... I think it exists

For the moment I can only find the one for the esp8266 "nosdk8266" (also a good contender to run klipper)

Here is what I could find

https://www.youtube.com/watch?v=AWT2w7v9szs https://hackaday.com/2016/11/30/the-esp-a-new-1kb-contender-appears/ https://github.com/cnlohr/nosdk8266 https://github.com/cnlohr/esp82xx https://www.youtube.com/watch?v=LiKNRBIcGII

And to anyone looking at the ESP32, you should know there is another excellent value MCU called the CH32V003 which only costs 0.30$ in 50x QTY, is RISCV, 48MHZ 16K and it also has a very beefy version with builtin ethernet, 8 UARTS, 2 CAN and 256K mem for about 2$USD

And this MCU is being heavily worked on by cnlohr as per https://github.com/cnlohr/ch32v003fun

Klipper3d / klipper

Features request MCU support for ESP32 #199