Searching \ for '[PIC]Need advice on interrupt routine methods' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'Need advice on interrupt routine methods'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]Need advice on interrupt routine methods'
2008\06\02@191351 by Stephen D. Barnes

flavicon
face
My question is about general/recommended practices for interrupt coding.
I am using the dsPIC30F2010 and using INT0, INT1, and TMR1 interrupts.
INT0 and 1 are external interrupts based on sensor input (IR switch)
I am using timer 1 interrupt on period match for a delay.
My config allows for nested interrupts.
Is it generally ok to have about 30 lines of code inside the interrupt
routine? On INT0 I am decrementing a register several times with a delay
which uses TMR1 interrupt between each decrement.
Should I be calling another routine from the isr to do this?
Any advice welcome!

--
Regards,
Stephen D. Barnes

2008\06\02@193616 by Jinx

face picon face
> Is it generally ok to have about 30 lines of code inside the interrupt
> routine?

Stephen, hi, you can have as many lines of code as you like inside
an ISR. The only proviso is that, generally, if you are expecting
another interrupt, the current interrupt processing is finished. Or
at least left in a state that you can return to if, for example, a higher
priority or other interrupt/event needs processing first

If an interrupting source is re-enabled before ISR completion then
it's possible to interrupt back into an uncompleted ISR. In that
case you'd have to look at something like POPping the stack

For example, if you had only one interrupt, say a 1 second timer
IRQ, then you could have code inside the ISR that took almost 1
second to complete. And that's a lot of code execution time

I think what most people would do is make the ISR short and, if
possible or necessary, pass information from the ISR to the main
loop. But there's nothing to say that an ISR can't be an entity in
itself which completes a task without help from the main loop

However, apart from the h/w side of things, which is important of
course, an ISR is basically only a sub-routine. The question is not
what happens inside the ISR, it's the overall s/w flow management.
You, the coder, are in charge, not the chip

2008\06\02@232005 by Stephen D. Barnes

flavicon
face
Jinx wrote:
>> Is it generally ok to have about 30 lines of code inside the interrupt
>> routine?
>>    
>
> Stephen, hi, you can have as many lines of code as you like inside
> an ISR. The only proviso is that, generally, if you are expecting
> another interrupt, the current interrupt processing is finished. Or
> at least left in a state that you can return to if, for example, a higher
> priority or other interrupt/event needs processing first
>
> <<clipped>>
Thanks for the enlightenment!
Most ISR info I see says to keep it as short as possible but, in my
design, the only other thing going on aside from the code in the ISR is
timer1's interrupt which is required for the delay. I am doing a hobby
robot controller using 2 PWM channels for differential drive. Main
routine calls a ramp up routine which increments both PDC registers to a
preset max value using timer1 running to match the timer1 period reg and
interrupt in between each increment. When one of the IR sensors sees and
obstacle at a preset distance, it provides a switched logic level to
INT0 or INT1 external interrupt pins (left or right sensor). My INT0 and
INT1 ISR's will decrement one of the PDC regs with the same timer1 delay
to provide a ramp down of the appropriate motor causing the bot to
smoothly turn away from the obstacle until the external interrupt pin is
no longer true. Then the same PDC reg is incremented back to where it
originally was, again using the timer1 delay. At thins point, the ISR is
done and returns control to the main loop.

--
Regards,
Stephen D. Barnes

2008\06\02@234320 by Jinx

face picon face
> Thanks for the enlightenment!

You're most welcome

One other thing to bear in mind is that you don't HAVE to
respond immediately to an interrupt. In several of my projects
it's enough for the source's IF to be set by an event and polled
when convenient. You might have a non-urgent event on the
INT0 pin and you want to know ASAP that it happened but
you don't need to know right now. So you don't set its IE,
which keeps it out of the h/w IRQ system, and check its IF
as and when

There could be two events you want to keep track of. Perhaps
a 100ms timer tick and a switch closing. Either of those may be
more important than the other, so you'd put one on IRQ, the
other can be polled. Or both could be polled. Is it important that
the switch closure be detected and acted on immediately to
trigger another event ? Is the 100ms vital for another process ?

A trivia point - you might exit an ISR with RETURN instead of
RETFIE. This disables the interrupt system by not setting GIE,
maybe you want to detect a one-off. You can manipulate GIE
manually of course

> Most ISR info I see says to keep it as short as possible

They usually do say that, but really it depends on the s/w as
a whole, what task priorities you set, what the ISR has to do,
what else is going, etc etc. There's no compelling reason to
make an ISR any particular length per se

2008\06\02@235048 by Stephen D. Barnes

flavicon
face
Jinx wrote:
{Quote hidden}

Ahhh...some very interesting points you have made! I will keep them in
mind as my work progresses from basic obstacle avoidance to more
sophisticated behaviour.
Thanks again!

--
Regards,
Stephen D. Barnes

2008\06\03@081537 by Robert Ammerman

picon face
>>> Most ISR info I see says to keep it as short as possible
>>>
>>
>> They usually do say that, but really it depends on the s/w as
>> a whole, what task priorities you set, what the ISR has to do,
>> what else is going, etc etc. There's no compelling reason to
>> make an ISR any particular length per se

Actually, I have developed several applications where nearly all the CPU
time is consumed in an interrupt handler (up to 90%+). Typically the only
interrupt enabled is a timer interrupt. This allows for short 'tasks' to be
executed on a strictly scheduled basis, and, when done right, provides high
assurance that appropriate real-time deadlines are being met.

In these programs the 'mainline' code usually contains nothing more than a
command processor or simple state machine, which sets flags for the
interrupt level code to handle.

-- Bob Ammerman
RAm Systems

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...