Encoder Interface with STM32F4

[furqan]

Posted on August 08, 2014 at 20:16

I am trying to interface a quadrature encoder with my stm32f4. The code is almost the same as available on ''micromouse'' or many of the other forums.

The major problem I am facing is: In debug mode I am able to see the counter of my Timer increase(or decrease) and I can see in real time that the previous and current counter values are slightly different. However, their difference is continually 0. I then added an arbitrarily large delay between getting counter values and now I am able to observe a small constant difference. However, this is very crude and inaccurate. Any suggestions on how I can get accurate difference between the counter values and then find speed from it? #encoder #stm32f4 #stm32f4 #timer #timer #encoder #qei

[Tesla DeLorean]

Posted on August 08, 2014 at 20:29

Sample the counter against a hard and known time base.

[jpeacock2399]

Posted on August 08, 2014 at 20:57

Look at the difference between the two encoder phases.  It sounds like you are oscillating back and forth, net change is zero.  Make sure your direction phase is 90 degrees out from the step phase.  If the direction phase changes between the step rise and fall edges you won't see a net increase.

  Jack Peacock

[furqan]

Posted on August 09, 2014 at 07:38

I was thinking of using Systick ISR to sample the values after a known period of time.

[furqan]

Posted on August 09, 2014 at 07:41

No the DIR bit remains stable and the counter values always either increase or decrease (not both).

[furqan]

Posted on August 09, 2014 at 19:00

I am able to get a somewhat correct speed (need testing on oscilloscope to confirm) but I have run into a side problem.

When I start the motor my 'Count', 'totalCount' and 'distance' are all seemingly correct. But when midway through debugging, for testing purposes, I stop the motor the variables 'totalCount' and 'distance' take a huge jump. Sometimes this even occurs when I start the motor. The other variables like 'Count' and 'Speed' behave correctly. Any idea why this erroneous behavior may occur. The encoder reading code is as below: void encoderRead(void){         Count = TIM_GetCounter(TIM4);     TIM4->CNT = 0;     totalCount += Count;     Delay(10); //10ms delay using systick } void speedCalculate(void){     volatile float a,b,x,y,z,f;          x = Count/32;     y = 1/x;     z = y*0.008;     a = 60/z;     b = a/50;     speed = b;          f=totalCount/(50*32);     distance = f*pi*2*radius; }

[Tesla DeLorean]

Posted on August 09, 2014 at 19:32

Would generally recommend NOT resetting the counter, but simply comparing it to the previous reading to come up with a delta measurement. Remember also the count can go backward.

[furqan]

Posted on August 09, 2014 at 20:55

Yes that worked...Thank you!

[furqan]

Posted on August 11, 2014 at 05:07

I am sorry to bother again but I have another query related to the encoder interface:

The quadrature encoder I am using gives 16 counts per revolution on a single channel when counting one edge (either rising or falling). Thus, has a capability of giving 64 counts per revolution if using both channels and detecting both edges. When using the following instruction: TIM_EncoderInterfaceConfig(TIM4, TIM_EncoderMode_TI12,TIM_ICPolarity_Rising, TIM_ICPolarity_Rising); What is the number of counts per revolution with this configuration? 32 counts per revolution?

[Tesla DeLorean]

Posted on August 11, 2014 at 10:03

I don't spend my time using the encoder settings, but wouldn't it be pretty simple just to turn the shaft 360 degrees, and observe the magnitude of the change?