TARGET_STM32F1 makes no sense

[EvilGremlin]

Is there any reason to use -D TARGET_STM32F1 -D ARDUINO_ARCH_STM32F1 which are cortex-m3 while HC32F46x are cortex-m4 chips?

[classicrocker883]

there must be some good reason. have you tried disabling those - removing them from the build process? any results?

if I suspect, there must be some code needed in order to compile using PlatformIO, is there a way for the compiler to show what code or parameters it links to or uses, rather than from the Hc32 library?

[shadow578]

the HC32 HAL is implementation wise very similar to the STM32F1 HAL, implementing most of the same functions in mostly the same way.

By building Marlin as-if building for the STM32F1, all while actually only including the HC32 HAL, makes it so that only very few changes have to be made to Marlin itself. That makes merging changes from the upstream repo (MarlinFirmware/Marlin) way easier.

It is a bit of a hack, but makes thing easier for now. If, at some point, HC32 support is added to "normal" Marlin, these additional Defines could be dropped easily.

Hope this helps

[EvilGremlin]

So HC32 HAL is based on libmaple? And does it actually use cortex-m4 instruction set?

[shadow578]

So HC32 HAL is based on libmaple?

Tbh, i'm not really sure. I've based my arduino core on the one used by the voxelab aquila x2. No idea if that is libmaple...

And does it actually use cortex-m4 instruction set

Should be. At least all datasheets of the HC32F460 say it's a Cortex-M4, and according to that gcc is called with -mcpu=cortex-m4.