stm32c0 field naming preference

[cbiffle]

Hi! I'm attempting to get your stm32c0 support working, with the hopes of submitting a PR. Ran into a question pretty early.

ST's changed the names of all the GPIO fields on stm32c0. The bits in e.g. PUPDR have historically been named PUPDR0-15, which always seemed weird and duplicative, but it's what the reference manuals say.

In the C0 reference manual, they've renamed them to remove the R. So, PUPD0-15.

So I've got two options:

1. I can reuse similar definitions (the G0's is pretty close, though I'm still finishing comparing them in detail) and end up with API that does not match the reference manual in a relatively subtle way, but where GPIO code can compile for different STM32s without changes.
2. I can create a new GPIO API definition using C0's names, rendering code incompatible but matching the manual.

Normally, I feel like matching the reference manual is the right thing to do. In this particular case I'm torn: the firmware I'm working on also supports g0, and the renaming of things willy-nilly makes supporting both ... verbose. So that has me kind of inclined to match the historical bit names, in defiance of the reference manual. If it were something like changing a field called LOCK to DONUT I wouldn't even consider it, but this is dropping a superfluous R that I often forgot to write anyway, until reminded by rust-analyzer.

What do y'all think? Do you have a policy on this when the reference manual deviates in unexpected ways? (I remember the H7A3 reference manual making some arbitrary power domain register naming changes in a point release, for instance, but I don't remember what y'all did in response.)

Edit: ha, just to complicate things, I took a look at the G0 reference manual (rev 3) and C0 (rev 3) side by side and ... the G0 reference manual contains the same renaming as the C0, but the ST-provided G0 SVD uses the legacy names (the C0 SVD uses the changed names). So the SVD (and stm32-rs) don't match the reference manual already, suggesting that not matching on the C0 wouldn't be horrible.

So please comment here if you think otherwise, but barring input I'm going to work on a PR using the historical names (PUPDRx instead of PUPDx).

[burrbull]

The 2 main use cases of SVD are codegen and debugging.
So I prefer consistency across chip than with RM when difference is small.

Also we widely use clusters/arrays which you can find not fully consistent to RM.

Although I understand why ST renamed these fields. As R is shorthand for register.

[cbiffle]

Yeah, the renaming makes sense to me as well -- it's merely inconvenient if you're trying for portability.

I've got the GPIO renamed to the point where peripherals/gpio/v3 will apply, which seems like a good start. The next issue I've hit is that the stm32c0 SVDs completely omit the flash controller (!). Wheeee

[burrbull]

The next issue I've hit is that the stm32c0 SVDs completely omit the flash controller (!). Wheeee

You could copy full peripheral from other SVD with _copy if it is identical.
Or add with _add.

[Dirbaio]

@cbiffle FYI the stm32-metapac PAC already supports stm32c0 chips (used in the embassy-stm32 HAL).

Naming of registers there is already consistent across chips. Policy is "consistency across chips first, matching the RM second". (stm32-metapac's registers are manually curated, not derived from the SVDs which have lots of inconsistencies which you then have to patch)

[cbiffle]

@Dirbaio

@cbiffle FYI the stm32-metapac PAC already supports stm32c0 chips (used in the embassy-stm32 HAL).

Oh, interesting, you appear to be using the "check in the darn register definitions instead of editing a giant tree of patches" approach that I've been itching to do myself. I'll take a look.

[Dirbaio]

yeah, exactly! :) it was born out of the frustration with the patches...