Setting up Quadrature Encoder Mode in STM32Cube

[Neo M]

Posted on September 23, 2016 at 19:46

Hardware: STM32F767ZIT6 Nucleo 144 Board

IDE: Atollic TrueSTUDIO with STM32CubeMXI am trying to interface a quadrature encoder to TIM4 in the Encoder Mode using STM Cube. I set up the timer and configure the counter to counter till 5000. The function HAL_TIM_IC_CaptureCallback() is called on every interrupt by the encoder and not after 5000 counts. I am most probably using the wrong callback function. Can someone please point me towards documentation for using the

Encoder Mode

 of timers in STM32F7 ? The complete F7 manual hasn't been that helpful. #timer #encoder #stm32-cube

[Neo M]

Posted on April 17, 2017 at 15:50

I think for encoder mode, you should be using HAL_TIM_IC_CaptureCallback and

HAL_TIM_Encoder_Start_IT.

[Vineeth CN]

Posted on June 20, 2017 at 06:29

Hi All ,

   I am interfacing a quadrature encoder to TIM4 in the Encoder Mode using STM Cube with STM32F103. I set up the timer and configure the counter to counter till 1000. The function HAL_TIM_IC_CaptureCallback() is called on every interrupt. I am excepting a call back on when the counter overflow happen ie, when the count reaches to 1000 pulses in this case.

I my application i know for 1mm travel i will be getting suppose 1000 pulses, so i will set 1000 as the pre load count value and if the encoder count reaches to 1000 count i should get an interrupt.

Please help me with a solution.

Thanks and Regards,

Vineeth

[Brian D]

Posted on September 01, 2017 at 00:25

First, I made a mistake of posting my question as comment, which will not be seen as a new reply with question. So here it goes.

Hi JW,

Board: NucleoF722 with STM32F722

I'm using TIM5 for quadrature encoder counter. Following you suggestion to configure the timer, I have question with reference to capture below. Since the encoder channel A and B are mapped to TI1 and TI2 and the encoder Mode is TI12, and the counter is counting on both rising and falling edges of TI1 and TI2 inputs.

Question: Why selecting Rising Edge instead of Both Edge in the polarity selection? (In fact the chip User Manual says 'This configuration (Both edge) must not be used for encoder.' and I don't understand why not?) 

Anyone know why the polarity must be set to Rising Edge (instead of Both edge)?

Best,

Brian

[Brian D]

Posted on September 01, 2017 at 00:21

Hi JW,

Board: NucleoF722 with STM32F722

I'm using TIM5 for quadrature encoder counter. Following you suggestion to configure the timer, I have question with reference to capture below. Since the encoder channel A and B are mapped to TI1 and TI2 and the encoder Mode is TI12, and the counter is counting on both rising and falling edges of TI1 and TI2 inputs.

Question: Why selecting Rising Edge instead of Both Edge in the polarity selection? (In fact the chip User Manual says 'This configuration (Both edge) must not be used for encoder.' and I don't understand why not?) 

Anyone know why the polarity must be set to Rising Edge (instead of Both edge)?

Best,

Brian

[waclawek.jan]

Posted on September 04, 2017 at 10:41

I don't Cube so I don't know what exactly is meant by 'Both edge', but if it's setting of  TIMx_CCER.CC1P (which you've read) then it's because that is a setting for the 'edge detector circuit', in the channel input, which in encoder mode (and a few other modes named therein) does not work as an edge detector but as a selectable invertor, thus has only two settings (and the 'both edges' is the third). The encoder decoding circuit in the slave module does take levels from the input channels (TI1FP1 and TI2FP2 signals, see TIM block schematics) rather than edges - it then detects the edges in itself.

JW

[Brian D]

Posted on September 06, 2017 at 03:51

In other words the CubeMX is wrong under its Parameter Setting\Encoder\Polarity to have the selection of Rising Edge, Falling Edge, Both Edges. Because in encoder mode, regardless of TI1 Mode, TI2 Mode, or both TI1 and TI2 Mode, the counter should be triggered on both edges of each channel; it is not a choice. Therefore, the wording should be Inverted or non-inverted under Polarity selection.

Brian

[waclawek.jan]

Posted on September 06, 2017 at 10:59

Therefore, the wording should be Inverted or non-inverted under Polarity selection.

Yes, but that's only in encoder mode (and a few other modes), so those settings interact, that makes programming CubeMX far less trivial than only directly mapping  few register bits to some single-liners.

[rant mode on]This is why I am not interested in cuboids and kin. At the end of the day, if you really want to use the chip and not only a subset of its features you need to go down and understand the working of it, so cuboids are only an unnecessary intermediary. Sparkling and fuzzing and technicolor, yes, I understand the selling points. I'm just sad ST spends money/time/people on this fluff rather than the right stuff. [rant mode off]

JW

[Brian D]

Posted on September 06, 2017 at 19:58

JW,

'

[rant mode on]This is why I am not interested in cuboids and kin. At the end of the day, if you really want to use the chip and not only a subset of its features you need to go down and understand the working of it, so cuboids are only an unnecessary intermediary. Sparkling and fuzzing and technicolor, yes, I understand the selling points. I'm just sad ST spends money/time/people on this fluff rather than the right stuff. [rant mode off]'

I'm a newbie to STM32 tool sets and so I found Cube is helpful in understanding how the registers are acessed, and a quick way to see generated codes that initializes the registers -- in a strict sequential order sometime -- for the peripherals to work properly. I total agree about reading the registers and their bits meaning. In fact I write my own code since the Cube generated code is too long; i.e. Cube uses over 50 lines of C code to send SPI data, while I need only two lines of code:

while((SPI2->SR)& 0x0080); // if busy

SPI2->DR=0x0A; // TX data 0x0A to Canon EF lens.

As about the Cube wording, there is nothing wrong about using a proper wording when the timer is in Encoder  Mode. The GUI screen should be adapted to each mode of the timer usage. Why the encoder mode has to share the same description with other modes?

Best,

Brian