Experiment with automated mcu flashing

Developers
1

Several months ago, I put together a (very raw) prototype to assist with micro-controller flashing from the Klipper API Server. The main idea is to make it easier for users to build, deploy, and maintain the micro-controller code. This topic is a place for discussions on this experiment.

The code for this experiment is at https://github.com/KevinOConnor/klipper-dev/tree/work-flash-20210519

The core idea is to place a section in the main printer.cfg with the Kconfig settings and flashing parameters needed for the micro-controller. For example:

[flash_mcu btt-skr-mini-mz]
flash_method: sdcard,btt-skr-mini-mz
kconfig:
  CONFIG_MACH_STM32=y
  CONFIG_MACH_STM32F103=y
  CONFIG_STM32_FLASH_START_7000=y
  CONFIG_LOW_LEVEL_OPTIONS=y
  CONFIG_INITIAL_PINS="!PA14"

With that info, it should be possible for the graphical frontends to be able to command Klipper to build and flash the mcu.

Alas, I have not had time to work further on this experiment. It’s unclear when I’ll be able to work on it again.

There was a previous discussion on this topic at https://github.com/Klipper3d/klipper/pull/4307

-Kevin

6 Likes
2

I was following your experimental example closely, but have not chimed in on it yet. As I am running several multi-MCU setups (5-8 MCUs each with different initial_pins configs), I would be super happy to help testing if needed.

Do we need to directly integrate with Moonraker and UIs like Mainsail - or can’t we first add a quick python script (“flash_all_mcus.py”) for development and testing the functionality?

3

I have to say, this seems like something that might be smarter to integrate into a secondary API server like Moonraker.

Love the idea though