wch: Add initial support for CH32H417

[So1aric]

This draft adds initial support for the CH32H417. Currently, I can generate a flashable binary in which the V3F core wakes up the V5F and toggles PC2, while the V5F toggles PC3.
However, I'm not quite satisfied with the build system yet. Since the firmware for the two cores must be compiled separately, the add_firmware call should somehow accept two source paths. For now, I've added addDualCoreFirmware in the port's build.zig as a workaround — I'm not sure whether this is the right approach, so feedback is welcome.
The HAL is still unfinished, and system_init remains to be implemented.
That said, I'd like to settle on the build system design first before moving on to the remaining implementation.

[So1aric]

#1023

[mattnite]

Hey! This is looking really great, thank you for putting time into a contribution. To what extent did you test this on your hardware, and are able to fetch the SVD through a dependency?

[Grazfather]

Looks good. Is this ready to review? There are some remaining TODOs and some commented out code. TODOs are OK if they are not needed to run the examples, but ideally you'd file an issue for them and reference them in the comment.

You'll also have to rebase.

[So1aric]

Hi!

To what extent did you test this on your hardware, and are you able to fetch the SVD through a dependency?

I’ve only run the blinky example on a nanoCH32H417. Since UART isn’t implemented yet, validation is currently limited to GPIO/LED behavior. I found the SVD in MRS2, but it contained a few bugs; I’m using the ch32-rs patches as a base and added local fixes for STK, GPIO speed, and ISR-related fields.

Is this ready to review?

Yes, I suppose.

There are some remaining TODOs and some commented out code.

The TODOs are intentional for now: a few are possible code-duplication cleanups, and the rest depend on hardware details/features I haven’t verified yet. I've clean-up some of the commented-out code.

[So1aric]

I believe it's ready for review.

[Grazfather]

why did you rename clocks to clock?

[So1aric]

My thinking was just that the other modules here are all singular (gpio, time, pin), so clock felt more consistent. But on second thought plural probably makes more sense (it includes a lot of clocks 🤔). should I change it back to clocks?

[Grazfather]

Yeah, we'd prefer if it matches the other HALs.

Other than that, this looks good. You tested both examples?

[So1aric]

Yeah, we'd prefer if it matches the other HALs.

I've reverted it.

You tested both examples?

Yes, here's how they behave:

[So1aric]

These ports are not running unit tests in CI:
wch/ch32h
These ports are not building examples in CI:
wch/ch32h

    - name: wch/ch32v
      run: zig build test
      working-directory: port/wch/ch32v

Should I add ch32h after this in .github/workflows/ports.yml?

[Grazfather]

Yes please!

[mattnite]

So just a couple things here:

• We need a corresponding examples dir for the port, just blinky is fine for now.
• Add a "test" step to the port. It'd fine if it's just a:

_ = b.step("test", "");

I just want that wired up so that if/when tests are added, no one has to deal with CI scripting.

[Grazfather]

Ah yeah sorry @So1aric, I agree with Matt. Can you move those two blinky files into something like a ch32h417_only/ subdirectory?

[So1aric]

I'm not very familiar with Zig's test setup. Should I just add _ = b.step("test", ""); directly in build()? I couldn't find a reference for this in the other ports.

Edit: done.