Is there any official plan to consider supporting Klipper’s migration to the general ARM Linux system. My idea is not to directly brush ubuntu, debian, and armbian systems into the ARM development board for online script installation, which undoubtedly adds some burden. Can I break away from this method, first cross compile on the PC side, then copy some Klipper Python libraries and any dependent files to the corresponding file system, and then directly burn them to the embedded ARM Linux environment?
For example, I want to port Klipper’s host side to imx6ull, but I don’t want imx6ull to pre install systems such as ubuntu or debian. Because the file system is too large, I want this file system to be even a very compact file system that I can build directly through buildroot.
Klipper’s architecture consists (at its minimal configuration) of two components:
- Klipper host software - A Linux process that does all the management work like reading / streaming / processing the Gcode, evaluating sensors, reaction to user input etc. This needs a full fledged operating system with Python and all other bells and whistles
- Micro-Controller - Pretty bare metal firmware to manage the different MCUs and their peripherals
- Linux MCU - An optional service to use the host SBC’s GPIOs and buses like SPI / UART / I2C
Technically your request might be possible but surely not in Klipper’s current form.
Personally I see no benefit in such since already today a RPI Zero 2 (or any other cheap SBC) is more than sufficient to run a full Linux plus Klipper
So why was it not initially implemented through C/C++? Like Marlin firmware, I can guess that Python is fast enough to develop compared with C/C++, so you first chose Python language for development when designing it. However, as far as the technical route I mentioned is concerned, if an ordinary board wants to port Klipper, it must support python2 and python3. These two libraries are really large for solutions with small resources.
Back when the MCUs have been only 8bit the Klipper architecture had the really significant advantage to offload all computational intensive topics to the host process and the MCU was basically only used for moving the steppers and reading temperatures.
But still today, Klipper allows to achieve much higher step rates than monolithic firmwares like Marlin or RRF
The biggest advantage Klipper has is the ability to use multiple MCUs. This is why a full fledged host computer is needed.
As for the choice to use Python, I believe Kevin has indicated that was to reduce the barrier to entry for new contributors. Writing everything in C/C++ would have dramatically reduced the number of contributors, and I think this has proven to be a wise choice over time.
I tried to port Klipper to an ordinary ARM Linux file system, but I ran into a problem. When importing cffi packages, you need to compile them through the compiler first and then import Python packages. However, it is too big to port such a cross compiler to an ordinary ARM Linux file system.
AFAIK most of the important Python (core) routines are C++ cores with a Python call stack…This is at least the case for mathematical libs and so on we use.
@morixinguan: See the difference in implementaion strategy: Marlin is running at the (limited) hardware of a 3D printer, used to be Atmel 8 Bit “Arduino-Type” MCU (or today A3 or A4 Cores). Here Space and “hands on memory” is lethal. Klipper reduces the code on the printer to a minimum and ports the “time consuming” computations to a powerful (and hardware independant) external CPU (e.G. a RasPi). So even on a weak printer, you may enjoy the power of an up-to-date CPU. My Anycubic Mega S is running on a Arduino Mega Hardware 
Klipper for this printer is running on a Intel I3…
So if you want to replace the “up-to-date CPU” against another Atmel, you may do that, but you will be very alone with this solution…
Klippy compiles the chelper module when it is not present or when a source file is newer.
You could run klippy in a virtual machine to trigger the compilation then copy the .so to your target.
Or do a cross-compilation by changing GCC_CMD to a cross-compiler in klippy/chelper/__init__.py. It should be doable since there is no system libraries linked.
Eventually you can modify check_build_code to always return False, if you want to skip the check and be sure that no compilation will be attempted on your target.
Of course updates will require to repeat this process.
You can choose to only use one version of Python, either 2, or 3 with the latest version of klipper, and package it in a minimal way, eg. with buildroot.
Thank you for your answer. I am very proficient in the embedded Linux operating system, but I may not be familiar with the PC side. Just today, I have achieved what I want.