Encoder Read And Index Pulses

[tomtom9196]

Posted on February 06, 2013 at 15:43

Im using a quadrature encoder hooked up to TIM3-CH1/2 and it works fine, counting both edges, up and down.

 First question is how to read the TIM3-counter values from within a regular (50 us) ISR. Using TIM_GetCounter(TIM3) will cause a problem because the counter-value may be read at a time where it is being updated (written) and therefore generating a corrupt value. How to do this and make sure the value read is a correct (non corrupted) one ?Second question is about using a index-pulse coming from my encoder. This index-pulse should be used for checking the encoder counter value to make sure it is not drifting over one revolution. I cannot use any interrupts to do this.Is it possible to having the index-pulse generating a capture of the TIM3-counter and also transfer this (using double-buffered DMA) to a variable in memory ?The index-pulse is coming into TIM3-CH3, but since TIM3 is already setup in encoder-count mode, would it even be possible to have the TIM3-CH3 to trigger a capture of the counter as well as initating a DMA-transfer ?Thanks for any help with this! #encoder-index-quadrature-tim3

[Tesla DeLorean]

Posted on February 06, 2013 at 15:54

If metastability is an issue read it twice till it doesn't change, but the thing is synchronous, the inputs are synchronized, and the read is likely to take 4 cycles.

There is really no way to know if you're reading it immediately before, or after, it's about to change.

[emalund]

Posted on February 06, 2013 at 16:23 First question is how to read the TIM3-counter do not fall into the trap of a=count, b=direction. if you are using a counter directly, you WILL fall into it. a=count, b=direction misses/gains a count at some direction changes. Erik

[tomtom9196]

Posted on February 06, 2013 at 16:27

If the read is taking 4 cycles, it may not be unlikely that the counter would change during that time. I do not care if the counter is changing just before or directly after my read. It does not matter.

Im worried that I start to read the counter-value, and during the 4-cycle read, more encoder-pulses arrive, changing the counter-value.Reading through the manual I realize I may trigger a capture and store the counter-value, then the stored counter-value could be read. Then the stored value cannot change while Im reading it. Im thinking of using a compare-event on TIM2 to trigger a capture on TIM3, is that possible ?

[flyer31]

Posted on February 06, 2013 at 16:36

You read the timer value in one assembler command - this is an atomic operation.

Of course, as soon as you have read it, there might already be some other state in the timer - but this you never can control - you only have the value you have read - what do you expect more? You just have to be sure that the value itself is correct. E. g. if you would use a 64bit timer, then you would need to think very carefully, as 64 bit read operations are not atomic. But the timers anyway are only 16 or 32 bit - and 16 or 32 bit operations are atomic in STM32F4, so there is no problem. @Eric: Can you give an example, how to generate such a counter problem? I use the counter with a very precise rotary encoder, and a missing count would hurt me tremendously (but up to now I never saw something like this, also if I disturb my input line to create jittery signals - the reference signal will pass always exactly at +- zero counts, after it once has referenced successfully).

[tomtom9196]

Posted on February 06, 2013 at 17:12

Ok, thanks a lot. If the read is atomic, then I do not have to worry! I did not know this was the case.

Anyone having a suggestion on how to use the index-pulse to capture a value on the TIM3 ?

[emalund]

Posted on February 06, 2013 at 18:53

how to generate such a counter problem?

I can't find my old timing sheet but write out the 16 stages of A/B/curr_dir/new_dir and you will see the issue the solution is to make logic looking at current state and previous state Erik

[emalund]

Posted on February 07, 2013 at 05:16

my solution is virtually identical to the ''real life logic'' in this link

http://www.fpga4fun.com/QuadratureDecoder.html

I GUESS you can implement quadrature logic in software, I would be very weary, you can see pulses in the sub-microsecond range when the encoder is stopped precisely over a border between opaque and clear.  Thus i have always either used one of the HP quadrature decoder chips, a FPGA or discrete logic.  Interestingly enough Microchip seems to support my 'feelings' they have a microcontroller wit a hardware uadrature decoder as part of the chip. Erik

[flyer31]

Posted on February 07, 2013 at 17:21

Hi Eric,

thanks for the interesting link - but I think this happens only if you count a clock signal in dependency of the state of the A/B line. Then of course you get problems if the A/B line changes in the same moment as also the clock signal comes. But the Encoder interface in the STM32F4 does not count the clock signal, but it counts directly the A/B line changes. And this is a very clear instruction, and asynchronous counting of an external signal should be no problem for such a timer. To my knowledge this is a very clear procedure with no ambiguities (unless of course A/B get so jittery that they would have their edges at the same time - but this should definitely not happen for an encoder signal). If you look at figure 112 and 113 of the STM32F4 reference manual (part 14.3.16 ''Encoder interface''), then you see that ''normal'' A/B jitter situations are handled very correctly. Why do you think that the Microchip QEI interface should be better than the STM32F4 Encoder interface? To my experience they both work very well (I worked with dsPIC33 before I switched to STM32F4).

[emalund]

Posted on February 07, 2013 at 18:30

<i>Why do you think that the Microchip QEI interface should be better than the STM32F4 Encoder interface? To my experience they both work very well (I worked with dsPIC33 before I switched to STM32F4).</i>

I just had a look at the F4 datasheet (I am not currently using the F4) and what I see is NO quadrature detector, just a mention that the timers can be used for quadrature inputs.  Were I using the F4 I would, probably, have 47 documents.  If there is a document stating that the F4 has an actual quadrature decoder, pleas provide a link. Erik