TIM2 encoder mode - please help !

[mehmet.karakaya]

Posted on October 05, 2010 at 15:20

TIM2 encoder mode - please help !

[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 ?

[FF1]

It will be also useful for others if you can post your working code because it seems more people have same trouble.

Thank

Fabio

[Tesla DeLorean]

Posted on May 17, 2011 at 14:10

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

[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

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

    }

}

[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

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.

[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

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

Thanks for the response. I'm pressing for more of an answer because I genuinely don't understand. Programming Manual 15491.pdf says (2.3.5)

If software does not configure any priorities, then all exceptions with a configurable priority have a priority of 0.

and (2.3.6)

Only the group priority determines preemption of interrupt exceptions. When the processor is executing an interrupt exception handler, another interrupt with the same group priority as the interrupt being handled does not preempt the handler,

If multiple pending interrupts have the same group priority, the subpriority field determines the order in which they are processed. If multiple pending interrupts have the same group priority and subpriority, the interrupt with the lowest IRQ number is processed first.

I like things determinate!

Why should, ''things not work correctly'' until the preemption and sub-priority levels are unique?

re YMMV ... My mileage SHOULDN'T vary!

[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