TIM2 encoder mode - please help !

[mehmet.karakaya]

Posted on October 05, 2010 at 15:20

TIM2 encoder mode - please help !

[Tesla DeLorean]

Posted on May 17, 2011 at 14:10

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

[mehmet.karakaya]

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 ?

[Tesla DeLorean]

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     } }

[lowpowermcu]

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

[Tesla DeLorean]

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.

[mehmet.karakaya]

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;

[Tesla DeLorean]

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

[John F.]

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.

[Tesla DeLorean]

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