You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a feature request and/or tracking issue for adding bitfield operations to enumeratedValues generated enum types.
I would like to open discussion about whether bitfield operations are desired for enumeratedValues generated types.
From those more experienced with embedded/SVD development, are enumeratedValues types meant to be explicitly "only these exact values are expected to be read/written"?
Or is it more like C enums where you can perform bitwise operations on the values?
For example, lets say a field has three variants, which may show up alone, or any combination of the three.
Currently there is no way to express the above semantics.
The example in code:
/// Represents a field with bit range [3:0]pubenumSomeEnumValues{FieldValue0 = 0b0001,FieldValue1 = 0b0010,FieldValue2 = 0b0100,}
So, the field should be able to express any combination of the FieldValue[0,2] variants, but never set the highest bit. Even though the bit range spans 4 bits.
I have run across a number of field definitions that resemble the above situtation.
Currently, it is obviously possible to just define the fields without an enumeratedValues definition, and document the semantics in the field description.
However, it would be nice to be able to define the semantics in the type system using something like types provided by the bitflags crate.
If this is something maintainers, and the wider community, would like implemented, I am happy to contribute code.
The text was updated successfully, but these errors were encountered:
From those more experienced with embedded/SVD development, are enumeratedValues types meant to be explicitly "only these exact values are expected to be read/written"?
There's no space in the current spec to express this, but it would definitely be neat. Not sure how useful it would be though. We couldn't do this with enumerated values.
Right, I think this might be something better left to a higher level, for now. For instance, in a HAL I'm working on, I define convenience structures there using the bitflags crate. Really was hoping there was a part of the spec that allowed generating something similar from the SVD.
This is a feature request and/or tracking issue for adding bitfield operations to
enumeratedValues
generatedenum
types.I would like to open discussion about whether bitfield operations are desired for
enumeratedValues
generated types.From those more experienced with embedded/SVD development, are
enumeratedValues
types meant to be explicitly "only these exact values are expected to be read/written"?Or is it more like C enums where you can perform bitwise operations on the values?
For example, lets say a field has three variants, which may show up alone, or any combination of the three.
Currently there is no way to express the above semantics.
The example in code:
So, the field should be able to express any combination of the
FieldValue[0,2]
variants, but never set the highest bit. Even though the bit range spans 4 bits.I have run across a number of field definitions that resemble the above situtation.
Currently, it is obviously possible to just define the fields without an
enumeratedValues
definition, and document the semantics in the field description.However, it would be nice to be able to define the semantics in the type system using something like types provided by the
bitflags
crate.If this is something maintainers, and the wider community, would like implemented, I am happy to contribute code.
The text was updated successfully, but these errors were encountered: