Using record variant for register mapping in Ada

Question

It is OK to model a double usage register with a record variant:

type Capture_Compare_Selection is (Output, Input_TI1, Input_TI2, Input_TRC) with Size=>2;
for Capture_Compare_Selection use(Output=>0, Input_TI1=>1, Input_TI2=>2, Input_TRC=>3);
type TIM_Register_CCMR (CCxS : Capture_Compare_Selection := Output) is record
 case CCxS is
 when Output=>
 OCxFE:Boolean := false;
 OCxPE:Boolean := false;
 OCMx:Output_Compare_Mode := Frozen;
 OCxCE : Boolean := false;
 when Input_TI1 .. Input_TRC =>
 ICxPSC: Input_Prescaler := P_1;
 ICxFF: Timer_Filter := No_Filter;
 end case;
end record with Size=>8;
for TIM_Register_CCMR use record
 CCxS at 0 range 0..1;
 OCxFE at 0 range 2..2;
 OCxPE at 0 range 3..3;
 OCMx at 0 range 4..6;
 OCxCE at 0 range 7..7;
 ICxPSC at 0 range 2..3;
 ICxFF at 0 range 4..7;
end record;

My rationale is that this register (well, fragment of register) has a double usage, depending on the LSB bit; it looks quite like an Ada variant record.

Is there a downside to that or can I commit all the way to this kind of use?

Here is a primer on the documentation:

enter image description here

The full documentation is page 344 of doc RM0090 at ST Microelectronics (huge doc).

Answer 1

I don’t see any problem with your code in itself; this is exactly the sort of thing variant records are for.

I think the only problem with naming record components is that it can lead you into writing code that attempts to directly alter one component, relying on the compiler to do the necessary whole-register reads and writes (the reference document says in para 17.4 that write accesses must be 16- or 32-bits wide, read accesses must be 8-, 16-, or 32-bits wide). There were discussions on comp.lang.ada about the fact that Ada currently has no way to specify this requirement; AI12-0128 refers (for Ada 2020). GNAT now has the pragma/aspect Volatile_Full_Access.

Nevertheless, naming the components will produce much more writable, readable and verifiable code.

• nraynaud: Thanks for your answer. Wrt to the naming, I was on the fence (in C too), between human readable symbols and googlable (cmd+f searchable more precisely) symbols. I settled for googlable in this part because we are at a bare metal level, and we can't do anything without reading the doc anyways, the API is not discoverable or really understandable. So I threw the towel. Wrt to the access size, it gets worse, because there is bit banding on ARM, if you have weight in this community, it would be interesting to put the topic on the table at the same time, it's also about memory access.