Multi-MCU support

[stefanfoulis]

First: thanks for kiauh! It makes the install so much easier and also repeatable❤️.

I was wondering if there is support for multi-mcu firmware building/flashing?

So for a single klipper installation with multiple-mcu's. In my case I have an SKR 1.4 as the main controller board and a n Arduino Nano that handles some additional sensors and fans.

It would be super cool if it were possible to have the same ease of use for rebuilding/flashing the firmware with kiauh with such a setup.

[dw-0]

Atm you have to run the build+flash processes multiple times. For each mcu once, and then select the corresponding mcu. But i have something on my ToDo List, to directly build and flash another mcu once the previous flash is done.

[Frix-x]

It would be cool to also have an option in the Firmware menu to only Flash or SD flash without rebuilding for when you have multiple same MCU (like two SKR 1.4 for example). Another option would be to be able to specify multiple number in the MCU flash selection : that way KIAUH could build and then flash the MCUs specified one after the other.

[dw-0]

Coming back to this FR i have some questions...

@stefanfoulis What was your actual idea that would make life easier? What do you want to see when the first flash was successfully done? A dialog for example asking you if you want to flash another MCU if the script detected more than a single MCU connected over USB?

It would be cool to also have an option in the Firmware menu to only Flash or SD flash without rebuilding for when you have multiple same MCU (like two SKR 1.4 for example).

@Frix-x This one should be possible now with todays commits :) You now have a "build only", "flash only" and "build + flash" option in the advanced menu. So you could either do a "build + flash" for the first SKR and then a "flash only" for the second one. Or you could do "build only" and then two times "flash only".

Another option would be to be able to specify multiple number in the MCU flash selection : that way KIAUH could build and then flash the MCUs specified one after the other.

That would probably be a big QoL thing in terms of flashing. I might look into that, but for now it's rather low priority.

[behold81]

Not sure if this is what's being asked or not. However Ill comment here and please let me know if I should create a new request.

When an update requires the MCU to be applied you may need to create a selection of firmware files. 1st will obviously be the main board MCU. However many run 1-2 RPI MCUs that require a build and flash that could be automated and managed by Kiauh as it has direct access to the RPI can this not be more managed??

[dw-0]

I think it fits in this issue but this is a pretty extensive undertaking. I would need to implement a firmware-config-manager. Because the make menuconfig command always saves to a file with an identical name of .config. Those different .config-files need to be managed, that means renaming them, saving them somewhere, listing them in the interface to let the user select which firmware(s) he/she want's to build and flash.

I know that the last few days required several reflashes if you updated Klipper daily. But i also know that the developer is working on a better solution in general and someone else even mentioned, that an option to have multiple .config files might be a good idea :)

[behold81]

Yeah multiple .config files. if you can pass a parameter in to it for custom configs to load/save from as a start then you could manage any Kiauh created as you would know the names used for each MCU.

Longer term the menuconfig needs a config selection menu if not passed at loading.

Thats one approach I can think off.

[hg42]

I once wrote a quick and dirty script system to manage and build multiple MCUs. It does several jobs:

• combining multiple config files (so you can easily compare e.g. stepper_x with stepper_y with meld or windiff etc.)
• all MCUs get a name, the first is output as nameless in the combined printer.cfg
• maintain replacements in the config files (e.g. remove the name of the first mcu and replace it name prefix in all pins, this allows using an editor replace-all function or sed to move pins from one host to another, if they are all symbolic)
• managing the MCUs and building/flashing those that have active [mcu ...] sections in the config.
• building those into different out/xxx directories
• flashing those that got new binaries by a configured flash method. For more automatism, e.g. I use stty to put serials into dfu mode, and flash via dfu-util instead of copying the binary to the usb storage. The scripting system has functions like flash_dfu for a configured variable flash=dfu, or flash_make for flash=make, etc.

This uses a mcu-xxx directory for each mcu in klipper_config.

Each mcu directory contains a config file (in my case a zsh script, because the whole scripting is written for zsh) with some variables to configure some things. The KCONFIG file is kept local to the mcu directory. The out directory is structured with sub-directories for each MCU and kept elsewhere, because it should not become part of a backup.

The whole build magic is quite easy:

make V=1 KCONFIG_CONFIG=$cfg OUT=$out/ $action

so, just tell make the mcu specific config file location and the specific output directory KIAUH could simply use the specific config file and output directory instead of the defaults (Obviously you have to create the directory with mkdir-p etc.).

Basically, flashing should also work like this with action=flash. But as I said, make flash isn't always what I wanted, because it's not really trying to avoid manual steps (pressing buttons, that may be mechanically inaccessible), so I added a script layer and tried to find more automatic ways to do it (though, I am aware that there might still be MCUs where the automatism doesn't work, I would probably remove such hardware from my system).

It may also be possible, that current developments allow to simply use make flash, I didn't 3D print for more than a year... so I'm not aware of the current state of Klipper.

Also, KIAUH is interactive anyways, so it may not be necessary to add other flash methods.

Actually, it would be better to improve make flash instead of inventing another scripting layer. At the time, when I wrote the scripts, Klipper development had a lot of other much more important topics.

[johnwilling]

I would also like to put in my support for this feature. While I'm new to Klipper, I have just done a Ender 5 Plus/Mercury One.1 conversion with a BTT M8P, Hermt Crab CAN, and an BTT ADXL345 so I have 3 klipper MCU's to update when I needed. SO I have to keep switching the settings in menuconfig for each MCU. It would be nice for Kiauh to have a option to Save MCU settings to a "Name" and conversely to Load the "Name" MCU settings.

Any status on the Feature?