Got Nuvoton M487 working with the NUC505 driver with minimum modification

[ImproperCatGirl]

I have been working on a port for the Nuvoton M487 and noticed that it uses an almost identical USB IP core to the existing NUC505 driver. I also found that other chips in the NuMicro family (like the M463) appear to reuse this same IP.

I currently have a working "dirty" patch where I took dcd_nuc505.c, but it required several mechanical changes due to minor naming discrepancies in the Nuvoton header files (e.g., USBD become HSUSBD (since the M487 have a separate FS USB port) CEPBUFSTART vs CEPBUFST) and a few IP-specific logic additions (like endpoint flushing in reset).

The Proposal: Instead of creating a new dcd_m487.c, I would like to refactor dcd_nuc505.c into a unified Nuvoton High-Speed DCD that supports multiple MCUs.

Questions for Maintainers:

Are there any specific preferences for how to handle the modified register names and offset to keep the code readable and compliant with the project's style? According to the way of unifying in stm32_fsdev? 

I’m happy to submit a PR once I’ve cleaned up the mechanical renames into an abstraction layer.

[hathach]

yeah, we should refactor to merge nuvoton usbip to same driver and handle the register by either compiler macro or even define our own register struct like dwc2, you can follow that structure. I just don't have enough time to make the PR. I am wiling to help if you could make an PR.

[ImproperCatGirl]

For the "compiler marco" part, how do we ensure maximum maintainability? To using the official header's struct definition, (if in the future the register placement in the address space changes but logic stays the same), or to define our own and patch it if things changed ? The stm32_fsdev currently defined it's own struct, presumably since clones does not change the register layout, but is it possible that in the future, Nuvoton changed the memory layout, while the logic stays mostly unchanged?