I’m playing with a clone chip (because shortage) and wondering if there are any concerns for merging code that builds for the original target?
It more or less fully works out of the box with an F103 build, but a few tweaks unlock much higher clock speeds and a higher end ARM core. There’s a minor tweak required for hardware SPI where it behaves slightly different. The chip basically has a clone of most registers bits and locations, with extra features added into reserved bits. In the datasheet everything is renamed to not run afoul I guess.
Could this be merged directly, or would I need to split all the klipper code written for ST and rework it for headers provided by new chip vendor?
Artery AT32F403A, Cortex M4F @ 240Mhz. Early benchmark puts it at 3077K steps for three steppers, so faster than the F446 but slower than H7 series. Believe its also pin compatible with F103 so it could possibly be dropped in on F103 based boards. We’re still actually testing it to make sure its stable though.
Asking question so the work isn’t wasted to integrate but then need to split source tree instead.
1 Like
Great job, I’m working with the same controller, which is used in the Wanhao 0327001 v2 boards. These are sold in Argentina as Hellbot Magna SE 32-bit. Would you like to talk and work together
I have a dirty implementation, I’ll push it up in a branch so you can have a look, and ideally help test some peripherals.
For the most part the peripherals just work so there isn’t a whole lot to do. If the header license is an issue a lot of code will need to be copied and constants and stuff renamed, but I don’t want to do that until there is some confirmation.
It’s the messy first cut, the dev board I’m working on has an 8mhz crystal. There’s a new mcu line in menuconfig for the chip, but the serial shows up as f103. If your board has a different crystal can’t guarantee the clock will be configured correctly.
Curiously, they seemed to miss adding an option to divide the clock by 5 to drive the USB off the crystal at max system frequency – 240/5=48 – but I enabled the usb clock extraction so the core can run full speed. If you test keep an eye for the stability of the USB, clock extraction doesn’t always work as well as crystals so we’ll have to eventually sign off on it being reliable enough for use.
I enabled bootloader entry via the typical 1200 baud setting, but the usb pid/vid codes are different so I’ve just been programming it manually with sudo dfu-util -d ,2e3c:df11 -R -a 0 -D out/klipper.bin --dfuse-address 0x08000000:leave
It’s really hard to say. In general, I’m fine with adding changes to the code to support new chips. However, I’m not sure it is worthwhile to spend a lot of developer time adding and reviewing features for a chip that likely wont be available in a few years. In general, I’m leery of these “clone chips”, because I fear there wont be much long-term support. In contrast, adding support for chips from major vendors does require a lot of work, but we can have good confidence those chips will be available far in the future.
So, FWIW, if a clone chip runs as a stm32f103 then it might be best to just compile it as an stm32f103 and not bother adding code changes. If it needs some minor tweaks (like the gd32f103 or Add support for Nation N32G45x mcus by stas2z · Pull Request #6116 · Klipper3d/klipper · GitHub ) then it may be best to try to limit the impact of those tweaks to the mainline code.
That said, I don’t know enough about your particular chip to give much practical advice.
Cheers,
-Kevin
Okay, thanks. I was mostly wondering if it was an instant no for legal reasons or not.
I’ll just clean it up to build with the stm code, and people can compile off a fork or just run the f103 build until there is more demand.
I’m not aware of any concerns like that. If importing header files (or code) from a vendor into the Klipper repo then those files need a clear copyright statement that is compatible with the GNU GPLv3.
-Kevin