I have two Ender 2 Pro printers, one with HC32F460 MCU and one with STM32f103xe.
With the SAME gcode file and almost identical printer.cfg, they show a clear difference in speed.
I suspect the CLOCK_FREQ setting of 200 MHz in Kconfig for HC32F460 mcu is incorrect for Ender 2 Pro. I changed the value to 168 MHz and now both printers print at identical speeds and the measured long move speed matches the slicer configuration.
I have a new Ender 2 Pro with the S4 MB and it did not feel as snappy as I would have expected, so I printed a cylinder in vase mode that should have taken 30 seconds but took 36, so we have similar experiences. Maybe @SteveGotthardt could take a look when he has time.
That would only be the case if the serial transmission were implemented in software. The clock for the serial port is obviously generated by the hardware and does not change with a change in CLOCK_FREQ. I guess, CLOCK_FREQ is only relevant for klipper - it probably creates longer wait cycles when it thinks the processor is faster.
My printer works with both CLOCK_FREQ values, but only the 168 MHz value prints at the correct speed.
For what reason did you use the value of 200 Mhz?
By the way - the data sheet of the HC32F460 mentions a clock frequency of 168 Mhz:
The Klipper code has to correlate the host clock with the mcu clock in order to properly schedule events on the mcu. As for using CLOCK_FREQ - there is no reason to presume that the host clock is more accurate than the mcu clock, so we use the clock on the main mcu ([mcu]) as the main clock for scheduling print actions (ie, print_time).
Alas, a snippet from a log doesn’t provide much value. I’d need the full unmodified log attached to this thread. It’s a good idea to run a print (or at least initiate some toolhead movement) and then issue an M112 or emergency stop.
Hi Kevin, here’s a log of the test print that should have taken about 30s plus the priming lines but takes 36s+ instead. The host is a laptop running Debian 10 & Octoprint in virtual SD mode.
I used the 200MHz as CLOCK_FREQ because the bootloader seems to leave it there - that was my bootloader. Maybe there is a new bootloader that leaves it at 168 (voxelabs do that).
My implementation does not set the clock after the boot loader handoff. At system startup the code reads what is in the registers and determines what the clock is.
So… I could set clock freq explicitly, or find out if there is a new bootloader or I made an error reading the registers myself, or the code is wrong converting to system speed.
I am going to check the last one first to see if the code gets the system speed correct.
Uhhh - found out that my board now reports CMU_PLLCFGR: 0x 11 10 29 00
pllp = 1d → /2
pllq = 1d → /2
pllr = 1d → /2
plln = 41d → * 42
pllm = 0 → / 1