Merge sequential fields with common prefix and same size to arrays

[ekoeppen]

Symbolic fields names in registers make it more complicated to create generic abstractions which work with numerical indices. As an example, the ODR register in the STM32 GPIO peripheral is composed of 16 bits, and setting a pin requires passing in a struct to the write function. I've been experimenting with creating that struct at comptime, but it doesn't seem very elegant.

One way to simplify this would be what svd2ada does when generating fields, which is to generate an array of fields if subsequent fields have the same size and share a common prefix, see here for an example of the resulting code.

[ekoeppen]

To clarify the common prefix a bit more, it would probably also make sense to check if it is followed by a digit, especially the MSP430 SVD files seem to use a lot of common prefixes.

[ekoeppen]

After further experiments it unfortunately seems that it is not possible to have arrays in extern structs where the element sizes are not multiple of 8, not sure if the array approach would work at all.

[mattnite]

Could you explain some of the use cases you're wanting to see? I can imagine some, but I'm sure I'm missing context. I'll share some of my thoughts:

I understand that the struct pattern is less elegant in some scenarios, but it has two qualities:

• the struct corresponds with mutating multiple fields in a single register read/write (in the modify() method)
• declarative nature improves readability

It does make something like iterating GPIO bitfields more difficult, it can be done with comptime and a wrapping function, but there's also something like StaticBitSet that you can cast to to get an array-like interface.

it is not possible to have arrays in extern structs where the element sizes are not multiple of 8

it is also not possible to have arrays of bitfields in a packed struct. Not sure if there are any special cases

generate an array of fields if subsequent fields have the same size and share a common prefix

I've explored incorporating convention parsing before and the problem with it is when you automate it completely, it doesn't scale:

• not everyone uses the same conventions (slightly different usage means shotgun code)
  • you either have to edit SVD/ATDF or regz to deal with nonconforming patterns
• confusing in this specific scenario because SVD can communicate an array of fields, so now there's two ways to do things: naming conventions that regz specifically supports, and the SVD spec itself

Instead I plan to automate importing the different xml registers schemas, and then have tools for refactoring the register structure that provide suggestions that the user explicitly opts in to (as well as manual edits ofc), so an interactive, semi-automatic process. With suggestions for type deduplication, repeated fields, etc, we could improve the generated code, user experience of bringing up a chip, and share these benefits with other communities.

[ekoeppen]

Thanks for the reply! I'm currently working on yet another iteration of an embedded driver library, this time using Zig (after C++ and Ada), it's very much work in progress, but seems very well suited to do in Zig because of the metaprogramming capabilities: https://gitlab.com/40hz/zig/ezdl

While working on the Ada version, I realized that it would make sense to create MCU specific wrappers based on collections of peripherals which are shared between the different MCUs, e.g. on STM32. As an example, using comptime in Zig, this is a GPIO layer which works with duck typing: https://gitlab.com/40hz/zig/ezdl/-/blob/main/src/stm32/peripherals/gpio_v2.zig

Creating support for a new MCU is then quite easily done by adding a new wrapper: https://gitlab.com/40hz/zig/ezdl/-/blob/main/src/stm32/mcus/stm32f072x.zig

The array approach allows for things like GPIOs to use simple integers on the high level API.

I do like the approach to add a refactoring step though, I think that would help with more tricky cases like MSP430, where the definitions are not really usable out of the box (e.g. encoding the peripheral name in the field name).

[ekoeppen]

Let me close this issue, as it's not going to work, looking forward to the postprocessing approach!

[mattnite]

That's an awesome project! Chime in anytime because I want to make device support and writing drivers enjoyable.

Doing a bit more thinking, instead of using the bitset in the standard library, there's precedence for an embedded version (we need a volatile pointer), it'll be part of the mmio namespace in microzig, and we can have something like a BitArray for single bit fields, and FieldArray for multi-bit, repeated fields. Then all you'd have to do to get them is define it in the schema properly. Looking forward to putting that together :)

[ikskuh]

A note here:

packed struct { bool, bool, bool, bool, bool, bool, bool, bool }

is a thing and is an 8 bit "array" of integers, that you can index with comptime known indices

[ekoeppen]

That's an awesome project! Chime in anytime because I want to make device support and writing drivers enjoyable.

Thanks :) ezdl is in this half experimenting, half doing some real stuff phase, so far I've been able to take it much further than with C++ or Ada. I'll definitely check how to contribute to Microzig, it has some nice traction and better out of the box experience.