Support for latest svd files / patches from stm32-rs

[sjorsdewit]

Some context: I'm using stm32ral and have found some SVD bugs which I'd like to fix (stm32l4+ sdmmc peripheral). I'm planning to submit a PR to stm32-rs for this after I finish testing it.

While trying to get the stm32ral to build with the latest version of stm32-rs, I have come across some issues:

• stm32ral.py doesn't seem to like the stm32u series svd files. Which is not too surprising given that this series is not currently supported by stm32ral. My workaround for now was to hack the Makefile so it doesn't match this series

• stm32-rs contains fs_device_cluster.yaml which is not compatible:

  • the patch results in clusters without 'dim_index', which is not supported in stm32ral.py. A workaround could be to assume dim=1 in this case
  • the patch results in multiple registers with the same name (both DIEPCTL1 and DOEPCTL1 are renamed to CTL1). I don't understand why or how to handle this case.

I'm not super familiar with this codebase or the SVD file spec, so not sure whether the patch in stm32-rs should be changed or if stm32ral.py needs updating? For now I have simply removed fs_device_cluster.yaml on my local fork, which otherwise appears to build fine with the latest SVD files/patches.

[adamgreig]

Thanks for reporting the issue! I think stm32ral needs updating to handle some of the cluster syntax in SVD that stm32-rs now takes advantage of. It looks like dimIndex is optional, so I don't think it's necessarily a bug in the stm32-rs patches, but I haven't checked that specific case yet.

Not sure about the overlapped registers - are they in fact the same register with two names (i.e. at the same address)? In which case I think stm32ral will merge them to a common name and add all fields to both of them, but perhaps the naming algorithm needs improving for that case.

[sjorsdewit]

The DOEP and DIEP clusters are at different addresses I think (offset 0x900 and 0xB00 according to RM0432 56.15.45). Maybe prefixing the register name with the cluster name in case of conflict could fix this? The resulting names would match those in the datasheet in this case.