@NAPCAL, while I appreciate you posting this, can I say that as somebody who just spent 12+ hours getting CAN running on the Octopus and CAN toolhead boards that your script wouldn’t be any more helpful to somebody who is new to setting up CAN on their Octopus than the other references found here, on Reddit and the various sundry places Google searches lead you to. At the very least, you need to add background and initial information as to what is being done and why.
Your use of DFU exclusively for firmware loading is different than that used by the other references linked to above and this difference, I think, helps me find an answer to one of my questions above.
Could I suggest you add to the beginning of your script:
a) An explanation of exactly what is happening in this process. A big thing that needs to be explained is why a canboot.bin
image is first loaded into the Octopus (and the toolhead board) and is then followed by klipper.bin
.
b) A set of instructions for downloading & installing CanBoot and PySerial?
c) Instructions for explicitly executing commands out of the CanBoot
and klipper
folders and running make (menuconfig|clean)
from within them. You might also want to point out that the .bin files are in the out
sub folder of CanBoot
and klipper
.
At the end of the script, could I suggest that you add:
a) Instructions for setting up the CAN bus on the Raspberry Pi (ie creating the “can0” file).
b) A brief outline of what needs to be done for a toolhead (or other) board that will be connected to the Octopus using CAN.
In going back to my questions above:
- In your process, you do two DFU loads of the Octopus, the first is of canboot.bin at 0x08000000 and the second is of klipper.bin at 0x08008000 - I suspect what is happening here is that
canboot.bin
(and the CanBoot functionality) is stored at a lower location in memory than the subsequent load ofklipper.bin
. This isn’t obvious from the two make menus where the “Bootloader offset” (CanBoot) is32KiB
, the same as “Application Start Offset” which I would have thought there’s a conflict/overwrite situation as the other installation guides use CanBoot for installing the Octopus’klipper.bin
file after using DFU forcanboot.bin
.
As somebody who has worked with various bootloaders over the years, I’m impressed that the klipper.bin
file is relocatable - I think almost every other one I’ve worked with has required the start address of the application firmware must be stated explicitly and those that don’t, a special build process is required to make the generated code relocatable.
- Any idea what is the “CanBoot Deployer” that comes up when doing a CanBoot menuconfig for the Octopus? You have left “Build CanBoot deployment application” as “Do Not Build”.
Finally, can you comment as to whether or not there Is there any difference in how Klipper/Moonraker/Mainsail(Fluidd) is loaded using the Raspberry Pi Imager versus just loading the Raspberry Pi OS and then using KIUAH to load these applications? I think loading them via KIUAH ensures that they go in with only Python 3 (where as the Raspberry Pi Imager provides a Python 2/3 mix) - but this is only a theory.
Sorry for starting off this reply with my being negative about your process, I hope you understand that they come from somebody that has just climbed a mountain and understands exactly what you have put down (as well as knows it’s 100% right), but also knows it would not be helpful for somebody about to start their journey.