cpu: add support for GD32E23x

[jparker324]

Contribution description

Integration of GD32E23x (and potentially other GD devices) into RIOT-OS. Creation of board/gd32e230c-eval and cpu/gd32e23x.

Code was reused/adapted where possible from the following sources

• cpu/gd32v, board/seeedstudio-gd32, and board/sipeed-longan-nano for GD32VF103 and GigaDevice library references
• cpu/stm32 and board/nucleo-f091rc for Cortex M0+ and peripheral references and potential topology of family organization
• cpu/saml1x and board/saml10-xpro for Cortex M23 references
• GigaDevice firmware libraries and examples as available at https://gd32mcu.com/en/download?kw=GD32E2

Testing procedure

TBD

Issues/PRs references

Forum post 3935

[jparker324]

I'm opening the PR for review. The code compiles without errors, but it's time for some feedback from the team here as I continue.

1. Serial debug doesn't work yet. For this reason alone, consider everything untested. In the Keil example projects provided by GigaDevice serial debug is exposed though the ETM.
2. Peripherals are copied and modified as needed from what existed for GD32VF103. We can work to unify a /common/ set going forward. I'll be getting an GD32F310 dev kit this week for more comparison to help in that direction. Some peripherals are still missing, WDT (some timer cleanup), I2S, CMP (RIOT supported?), AF mapping for GPIO, DMA, etc. come to mind.
3. Debug/programming adapter interfaces are incomplete. GigaDevice's dev kits /boards/gd32e230c-eval and /boards/gd32vf103f-eval have an onboard GD-LINK interface that presents as a generic CMSIS-DAP adapter. Alternatively, there are SWD pins available for the E230, and JTAG pins for the VF103 and I have been able to connect a Segger J-LINK. Either solution is able to flash the device, but I'm not sure which is going to be better given the prior point about serial debug interface.

[riot-ci]

Murdock results

:x: FAILED

33426fef8ff6be65562e2f5737529d5eaafd8a26 initial gd32f310c population

Artifacts

[benpicco]

Sorry for the long delay,I almost forgot about this PR :sweat:

But I'm very interested, just it's quite a large PR that makes it hard to review. Can you organize the commits a bit better so you have one commit adding the vendor files (which then contains the largest chunk of the new lines), one for the CPU additions. If you change common code outside the new CPU, that's a new commit. Another commit for the board too. You can edit your commits with git rebase -i master (You can replace master with the first commit before your branch to keep the changes easier to review on Github in the 'force-pushed' view, as this then won't include the changes to master since the time you started the branch`)

And I see you added new periph drivers for the new MCU family - are those really so different from the ones used by GD32V that we can't have a gd32_common and avoid the duplication?