Add GD32F10x to known datasheets

[dmlambo]

Hello @maxgerhardt ! I've made some changes to add support for f103, but with only moderate success.

• added the datasheet quirks
• added more "A" family distinguishing features, such as for PeripheralPins.c

I hope this doesn't go against the grain for you, it's a new codebase for me. :) If you want to grab the relavent parts and merge it yourself, by all means!

What's not in the change, obviously, are all the additions to ArduinoCore-GD32 to make it compile. There wasn't too much to be done to get it going, just adding the startup files, variants, and the GD32F10x_firmware (cmsis/spl).

I got to a point where it was compiling and I could upload firmware, but I don't have an external debugger, so I can't say where it stops, other than it stops in the bootloader. I tried changing the FLASH offset with no luck. I'm not going to look into it any further without a way of actually debugging it.

[maxgerhardt]

First of all, I'm amazed that someone was able to look through this mess of a script and pin system I made and still make sensible additions to it. Woah. The changes do look good.

What's not in the change, obviously, are all the additions to ArduinoCore-GD32 to make it compile. There wasn't too much to be done to get it going, just adding the startup files, variants, and the GD32F10x_firmware (cmsis/spl).

Could you still PR that in at https://github.com/CommunityGD32Cores/ArduinoCore-GD32/ for reference, so I can have your reference state? I do have a ST-Link debuger and should also have a F103 board somewhere, so I am able to debug if it stops somewhere for whatever reason.

[dmlambo]

No problem! It's interesting work! 😄

Here's a draft PR with the changes to the arduino core.

I went a little crazy after staring at the code for about 12 hours straight and had to stop cold, so it's in a bit of a dangling state. But that's the gist of the changes.

[dmlambo]

Ah, found the problem. The startup .S didn't match the linker script in /variants... the section name and stack pointer name were wrong, so the isr vector table wasn't being placed at 0x0. I can now get an LED to blink. Hooray!

I also made a very expensive STLink by hooking up an RPi with OpenOCD to my f103 board (someone made an SWD bit blaster interface) and using remote GDB in vscode to debug the bootloader. I spent maybe 3 hours saving the $7 it'd cost from Amazon. At least I can debug my code now! 😃

[dmlambo]

Hmm, were the build failures my fault?

[maxgerhardt]

No, they were broken with a SPL update in the Arduino core in which they just removed support for gd32f170,190 chips (but fixed bugs for other f1x0 series chips). That is still an open issue to fix.

[dmlambo]

Incoming. 😄

This is a doozie, I know. I went ahead and added pin remapping logic for A family boards. It's not fully tested, but it builds with additional changes to the package which I haven't pushed yet.

So basically I had to hand-code a structure to describe the remappings, and it's all laid out quite clearly in the user manual. There are too many gotchas to make tabula worth it, in this case. It took about 3 hours to write it all out, but that was including figuring out the best layout for the remapping structure.

The main differences are:

• All pins are grouped together for output, contrary to the previous sorting by ADC peripheral. This is to allow clean _ALTx layout, and follows exactly what stm32duino does.
• There's a new include in the package called gd32x10xremap.h which contains all the remap values from SPL (including the board ifdefs) but wrapped in a macro so I can add names to allow DISABLE remappings. pin_function uses this to determine whether to enable or disable the remapping.
• Gathering pins thus now takes an array of criteria (to gather UART and USART at the same time, for instance), and does a sort at the end based on the pin name. The sort is lexigraphic, but I pad the pin number to ensure correct order.
• Added another PIN_FUNCTION which takes a REMAP instead of AFIO.

I don't guarantee I didn't break the other family of boards. I think there's opportunity to separate them a bit more, and I may tackle that a bit next. I'll do some testing on my board locally as well to make sure it does mostly what it's supposed to. It also got a bit ugly with the pin gather and adding ALT decorations, so I may try to clean that up a little bit, or maybe just add some comments to justify the ugliness. 😆

I'll push my changes to ArduinoCore as well so you can see the whole context.

Let me know what you think!

[dmlambo]

Just noticed a problem in the variant.h generator, it doesn't create all the ALT pins. Whoops.