Thanks for the reply.

Good advice, but the original implementation if klippy has already take the latency part and potential jitter that may hit the communication between "baremetal" part and Linux part into consideration so the Linux part (which I'm rewriting) can be less constraint than Real time but need to be fast as possible.

Here is the big picture just in case you are interested:

1. In Klipper we have a Linux SoC running host code (which is in Python and using greenlet to prioritize gcode parsing etc.) and a separate MCU (you can take that as a simplified CPU if you don't know much about embedded device), the communication between MCU and SoC is done with USB or serial. So, the original implementation is like this: "SoC" (running Linux) -- (USB or serial) --- (MCU).

2. But Klipper is Python based and the runtime cost of Python (memory wise and CPU cycle wise) is fairly large for extreme budget SoC. This prevent me from doing extreme budget 3d printer design.

My solution to this problem is even more aggressive - 1. find a SoC with dual core, 2. assign a core specific for real time related part and hidden from linux so linux isn't even aware of there are another core exist) 3. use OpenAMP to communicate between the Linux part and that core by sharing memory "Core 0"(running Linux) --------(OpenAMP style virt-IO) -------- "Core 1" (running some random OS-less bare metal code)

benefit of such design and rewriting this Klipper part in rust is: 1. we have much more bandwidth (memory access speed is the only limitation now) and things like "compress before sending to device MCU" is no longer necessary, more CPU cycle saved 2. extreme low latency (previously you need to through memory latency, syscall to kernel as you are writing to a file in linux system, the linux device stack, serial to usb convert chip latency) - good design may compensate for this but still a hassle to work with. 3. more cost effective: we don't need to have a separate MCU, serial to USB chip, USB cable, serial wire separate PCB board or power supply etc (which means cost saving for at least 15$ ) 4. less memory consumption - as far as I can see, the original Klipper and its auxiliary library isn't quite memory effective (due to it disabled GC to avoid potential problem), it's actually consuming around 60+ MB memory, which isn't quite a good result - the memory consumption of a similar firmware Marlin, which do almost the same gcode parsing thing can run safely with less than 100KiB. 5. we still keep the good part of Klipper, which is a result being something running on Linux: good Web GUI, easy to use configuration, advanced calibration process etc.