RTOS for MCU? about klipper

[paulie-g]

RTOSs do not improve realtime properties in the single-task case, they endeavour to preserve those properties in the presence of multitasking (and can offer a toolkit of additional functionality with known guarantees). Since a major use case for klipper is using low-end AVRs on existing printer control boards, a RTOS is impractical even if it were necessary, which it likely isn't. I'm not the author, mind you, this is just an educated opinion based more on familiarity with RTOS concepts than with the klipper codebase.

[KevinOConnor]

On Mon, Sep 04, 2017 at 04:52:33PM +0000, Jed Frey wrote: Have you evaluated jitter and timings with the current embedded controller?

I've performed a number of benchmarks - the results are in the Features.md document. Due to difficulty in measuring jitter at the hardware level, I've not done direct measurements of that. However, I have analzyed the klipper assembler that gcc produces and feel confident there are reasonable bounds on jitter. On the AVR, it's ~50 instructions to enter the timer irq handler and about 100-160 instructions per step (~3us / ~10us on 16Mhz AVR). Jitter on other platforms (eg, arm) are going to be dramatically better - sub 1us. But, it's harder to analyze the exact jitter from the code as those platforms aren't necessarily deterministic on each instruction.

I'm wondering if moving to a RTOS would make things more deterministic. Before finding ```klipper``` I was playing around with using ChibiOS as an MCU OS and using it as just an IO for Python scripts.

Klipper uses baremetal on its current platforms. As Paul G mentions, an RTOS generally isn't going to improve performance. However, it is possible to port Klipper to an RTOS if desired. Indeed, on the work-linux-mcu-20170804 I've done just that - it's a port of the Klipper mcu code to a Linux real-time process.

…

-Kevin