Updating stm32-rs to v0.16.0 (extending gen-device-svd accordingly)

[knieriem]

Hi, I have been working on adapting TinyGo for an STM32H723 (used on the Nucleo H723ZG). After generating the corresponding device/stm32/*.go file from an SVD file from stm32-rs, I noticed that entries were missing. This led me to investigate the current structure of SVD files patched by stm32-rs 0.16.0 from last week. Stm32-rs now uses Rust based svdtools to patch SVDs; quite a bit has changed since stm32-rs/stm32-rs@4a70124. So I iteratively adjusted and extended gen-device-svd.go accordingly. The changes to gen-devices-svd include:

• support multiple enumeratedValues entries per field
• fields: handle dim arrays, isDefault property, derivedFrom
• improved ordering of peripherals (sorting advanced peripherals of a group first; base peripheral ordering fixed)
• defining aliases, such as IWDG for IWDG1

The full list of changes to gen-device-svd for issues that had to be resolved can be inspected in the following set of commits: https://github.com/tinygo-org/tinygo/compare/dev...knieriem:tinygo:update-gen-device-svd

After this preparing work I was able to create a changeset for tinygo/stm32-svd: knieriem/tinygo-stm32-svd@e51475e I'm happy to open a PR if the direction makes sense to the maintainers.

The resulting device/stm32/*.go file for STM32H723 appears to work well regarding peripherals like GPIO, UART, and ETH (based on additional, local modifications to src/machine).

Previously existing device/stm32/*.go files, like the one for e.g. the STM32G031, an MCU I programmed using TinyGo with modifications a year ago, have improved too, as some names got corrected upstream, and the improved gen-device-svd adds entries that were missing previously, like TIM.CCR[2-4], and many constants.

The patch adds 44 new SVD files to the previously existing 87, including:

stm32c011       stm32h523       stm32h723       stm32u031       
stm32c031       stm32h503       stm32h725       stm32u073       
stm32c071       stm32h533       stm32h730       stm32u083       
                stm32h562       stm32h733                       
stm32f778       stm32h563       stm32h742       stm32u535       
                stm32h573       stm32h745cm4    stm32u545       
stm32l152                       stm32h745cm7    stm32u575       
stm32l4p5                       stm32h750       stm32u585       
stm32l4r5                       stm32h755cm4    stm32u595       
                                stm32h755cm7    stm32u599       
stm32n645                       stm32h757cm4    stm32u5a5       
stm32n647                       stm32h757cm7    stm32u5a9       
stm32n655                       stm32h7a3                       
stm32n657                       stm32h7b0                       
                                stm32h7r                        
                                stm32h7s                        

In five cases, previous SVD group files got transferred into a set of more specific files:

• stm32f7x2 ↦ {stm32f722, stm32f732}
• stm32f7x3 ↦ {stm32f723, stm32f733}
• stm32f7x6 ↦ {stm32f746, stm32f756}
• stm32f7x7 ↦ {stm32f767, stm32f777}
• stm32f7x9 ↦ {stm32f769, stm32f779}

To ensure compatibility with existing TinyGo code, I had to introduce a small ed script in the Make process. This script disables certain .yaml patches from stm32-rs that would otherwise narrow 32-bit registers to 16-bit — even when 32-bit access is valid. While these patches are intentional upstream, disabling them seems like a reasonable tradeoff to maintain compatibility with TinyGo's common code.

The patch appears to address some of the issues mentioned in #9, like adding SVD files for stm32u5, and adapting to changes in stm32-rs. The update apparently also implicitely fixes the problems described in #8, specifically regarding the STM32F410 and STM32F429, as mentioned in https://github.com/tinygo-org/tinygo/issues/2717#issuecomment-1070229326.

I have checked that programs using the currently supported STM32 targets can still be compiled (there is one exception, the swan target using the stm32l4r5). Only a few small changes to the TinyGo repository were necessary:

• targets/nucleo-f722ze: add build-tag stm32f722, change stm32f7x2.s to ..722.s (reason: stm32f7x2.svd got replaced by stm32f722.svd and stm32f732.svd)
• targets/swan: rename build-tag stm32f4x5 into stm32f4y5 (previously, there was no specific stm32f4r5.svd, just stm32f4x5.svd was used; now, both files are present. This means that the existing build-tag stm32f4r5 will include the device/stm32/stm32f4r5.go file, and the additional build-tag stm32f4x5 would include the device/stm32/stm32f4x5.go file as well, resulting in build conflicts. Renaming just the tag, which is used in src/machine, into e.g. stm32f4y5 solves this issue)
• src/machine/machine_stm32wlx.go: rename TXFNF into TXE (this is an issue I may address in gen-device-svd yet; it is caused by the way alternate registers are handled)

As mentioned, there is a remaining issue with the swan target's stm32l4r5, caused by differences regarding the TIM_Type (some 16 bit issues, but also missing CCRM[12]_Output - there is only CCRM3_Output). Perhaps this detail should be left as is, and resolved later, perhaps with a more fine-grained timer implementation in src/machine.

[deadprogram]

@knieriem this looks like some very useful and well-thought out work. I will review as soon as I can give it proper attention. Thanks!