waclawek.jan

Bitfield values in CMSIS-mandated device headers

Discussion created by waclawek.jan on Sep 7, 2017
Latest reply on Mar 21, 2018 by waclawek.jan

Some of the peripheral registers have bitfields, which define distinct functionality. In programs, it is often useful to have available symbols which describe this functionality and can be used in setting these fields/registers. For example, the SMS field in TIMx_SMCR register allows to select one of 8 modes (in its original form; in later STM32 models expanded but that's irrelevant here) of the slave controller:

000: Slave mode disabled
001: Encoder mode 1
010: Encoder mode 2
011: Encoder mode 3
100: Reset Mode
101: Gated Mode
110: Trigger Mode
111: External Clock Mode 1

Defining symbols like

#define  TIM_SMCR_SMS__NO                    0  // timer clocked from internal clock
#define  TIM_SMCR_SMS__ENCODER1              1  // TI2FP2=CLK, TI1FP1=dir
#define  TIM_SMCR_SMS__ENCODER2              2  // TI1FP1=CLK, TI2FP2=dir
#define  TIM_SMCR_SMS__ENCODER3              3  // quad mode, counts on both signal's edges
#define  TIM_SMCR_SMS__RESET                 4
#define  TIM_SMCR_SMS__GATED                 5
#define  TIM_SMCR_SMS__TRIGGER               6
#define  TIM_SMCR_SMS__EXT_CLK_1             7

and similar, allows then to write statements for accessing this register like:

  TIM5->SMCR = 0
    OR (TIM5_SMCR_TS__TIM8      * TIM_SMCR_TS_0    )  // master is TIM8
    OR (TIM_SMCR_SMS__EXT_CLK_1 * TIM_SMCR_SMS_0   )  // external clock mode 1
  ;

 

Both SPL and Cube do define symbols like these, in a non-systemic and often ad-hoc fashion.

 

In my opinion, these belong to the CMSIS-mandated device headers be maintainted in the same way as the register definition themselves.

 

Jan Waclawek

Outcomes