cancel
Showing results for 
Search instead for 
Did you mean: 

TIM2 encoder mode - please help !

mehmet.karakaya
Associate III
Posted on October 05, 2010 at 15:20

TIM2 encoder mode - please help !

16 REPLIES 16
Posted on May 17, 2011 at 14:10

Try enabling the TIM2 and GPIOA clocks, before programming/initializing the peripherals.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
mehmet.karakaya
Associate III
Posted on May 17, 2011 at 14:10

thank you for your help  , it worked

I have 2 more question

1) there is an  TIM_IT_Update interrupt source for this timer

how can I detect overflow or underflow ?

I know I can check the counter value itself

but I wonder if there is seperate flags for overflow and underflow ?

2 ) if I choose TIM_EncoderMode_TI1 instead of TIM_EncoderMode_TI12 

then is it,  that  TIM_CH1 input is puls and TIM_CH2 input direction ?
Posted on May 17, 2011 at 14:10

Something like this should be workable.

TIM_ITConfig(TIM2, TIM_IT_Update, ENABLE);

void TIM2_IRQHandler(void)

{

    uint16_t current = TIM2->CNT;

    if (TIM_GetITStatus(TIM2,TIM_IT_Update)

    {

      TIM_ClearITPendingBit(TIM2, TIM_IT_Update);

      if ( current < 0x7FFF )

        highorder += 0x10000;        // Roll over in upwards direction

      else

        highorder -= 0x10000;        // Roll over in downwards direction

    }

}
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
lowpowermcu
Associate II
Posted on May 17, 2011 at 14:10

Hi karakaya,

In my understanding, there is an update event at each overflow/underflow.

I think you can check update flag for overflow/underflow detection.

cheers,

MCU Lüfter

Posted on May 17, 2011 at 14:10

In my understanding, there is an update event at each overflow/underflow. I think you can check update flag for overflow/underflow detection.

But there isn't an explicit bit for overflow, and another for underflow, you are stuck reading the counter and guessing which way it was going when the interrupt was generated. And you have to hope it doesn't dither at the transition point.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
mehmet.karakaya
Associate III
Posted on May 17, 2011 at 14:10

hello clive1,

in this manner I want ask something about interrupts which confuses me much

what is this -->  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_0);

what is this -->  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;

and what is this -->  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;

Posted on May 17, 2011 at 14:10

Well, the NVIC has many possible configurations.

Basically you can assign a flat interrupt priority level, where interrupts of a higher priority will preempt ones which are already running of a lower priority level.

Then there is a less flat mode, where several interrupts can share the same priority level and won't interrupt the processing of each other, but ones (or groups) with a higher priority will.

As I recall you have 4-bits to represent these levels and sublevels. So you could program it with 8 priority levels and 2 sub levels, or 4 priority levels and 4 sub levels, etc.

The trick is to understand how you want to prioritize things, whether in normal operation some things with equivalent importance are occuring, or if other things are critically important. The other trick is to make sure no two interrupts are set with the same priority/sub setting.

For an encoder, I would want it to have a very high priority (low latency), even through I would expect it to have a low frequency of use. Basically the interrupt code would get in and out quickly

Suggest you pull ARM's documentation of the NVIC, or Joseph Yiu's book.

The PriorityGroup works along these lines..

Lower numbers, higher priority

NVIC_PriorityGroup_0 - 0 bits for pre-emptions, 4-bits for sub priority

Flat, no pre-emption, highest sub priorities pending will execute first

Pre.Sub

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0.10

0.11

0.12

0.13

0.14

0.15

NVIC_PriorityGroup_1 - 1 bit for pre-emptions, 3-bits for sub priority

Two Groups, 0.x has preemption priority over 1.x

Pre.Sub

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

1.0

1.1

1.2

1.3

1.4

1.5

1.6

1.7

NVIC_PriorityGroup_2 - 2 bits for pre-emption, 2-bits for sub priority

Pre.Sub

0.0

0.1

0.2

0.3

1.0

1.1

1.2

1.3

2.0

2.1

2.2

2.3

3.3

3.3

3.3

3.3

NVIC_PriorityGroup_3 - 3 bits for pre-emption, 1-bit for sub priority

Pre.Sub

0.0

0.1

1.0

1.1

2.0

2.1

3.0

3.1

4.0

4.1

5.0

5.1

6.0

6.1

7.0

7.1

NVIC_PriorityGroup_4 - 4 bits for pre-emption, 0-bits for sub priority

Flat, higher priority will always pre-empt running interrupt code for lower priority

Pre.Sub

0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

9.0

10.0

11.0

12.0

13.0

14.0

15.0

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
John F.
Senior
Posted on May 17, 2011 at 14:10

clive1 wrote, ''The other trick is to make sure no two interrupts are set with the same priority/sub setting.''

Why?

I thought two interrupts set with the same priority/sub setting would just be serviced consecutively. Please explain further - thanks.

Posted on May 17, 2011 at 14:10

clive1 wrote, ''The other trick is to make sure no two interrupts are set with the same priority/sub setting.''

 

 

Why?

 

 

I thought two interrupts set with the same priority/sub setting would just be serviced consecutively. Please explain further - thanks.

 

I've run into issues cut-n-pasting NVIC_Init() code where things did not work correctly until the preemption and sub-priority levels were unique. Unless there is some specific reason, or a desire for indeterminant behaviour, I'd park each at a unique setting. YMMV

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..