Reading Encoder and Input Capture on Same Timer

[Tesla Sparks]

Posted on July 15, 2018 at 11:13

Hi everyone!

I'm using an STM32F767ZI and I want to read an encoder: I'm new to STM, so I am using CubeMX in order to set the mcu in the right way. 

I would like to read encoder's signals with only 1 timer, like timer 1.

So I have 3 channels: CH_A and CH_B, that are assigned repectively to 

TIMx_CH1 and TIMx_CH2 ; and also the index, CH_I.

For CH_I, I've read that is possible to set up a third timer channel, like CH3 or CH4, in 'input capture mode' to trig the Index signal, on the same timer, but how can I do that?

I found a callback function in an application note:  'HAL_TIM_IC_CaptureCallback(&htim_that_I_want)' , should I use it and write inside this funcion to reset the related timer?

Is there any automatic way to auto resetting timers when the Input Capture on CH3 or CH4 detects an edge?

Thanks!

[waclawek.jan]

Posted on July 15, 2018 at 12:07

I don't Cube so won't help with the incantations there. I can describe what you need in terms of the Reference Manual, though.

This would be a normal input capture, so you want to set TIMx_CCMR2.CC3S = 0b01 (CC3 channel is configured as input, IC3 is mapped on TI3) and enable it by setting TIMx_CCER.CC3E = 1. This by defaults triggers on the rising edge; you can change that if you want by changing TIMx_CCER.CC3P/CC3NP.

Now you can enable interrupt upon this capture by setting TIMx_DIER.CC3IE (and then enabling the interrupt in NVIC) and then write the proper interrupt service routine which would check if TIMx_SR.CC3IF is set and clear it and then perform whatever you want - e.g. zeroing TIMx_CNT. But I personally wouldn't do that. The interrupt latency may be too long for this to be correct - it may zero the counter too late, when it's away from the index position. And there is no hardware way to reset the counter - the slave-mode-controller is already set to encoder mode so can't be set to reset mode, and there's no input from CH3 to the slave-mode-controller anyway.

What I would do rather, is, that I would simply omit any zeroing of the TIMx_CNT, leave it to count freely, and utilize the captured value from TIMx_CCR3 - which is a snapshot of TIMx_CNT at the moment of the index signal's edge causing the capture - to calculate the absolute position of the encoder whenever needed.

JW

[Tesla Sparks]

Posted on July 15, 2018 at 12:50

I didn't think about interrupt latency, thank you!

I will try doing what u suggest.

Thanks a lot!