avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] interrupts


From: Larry Barello
Subject: RE: [avr-gcc-list] interrupts
Date: Thu, 17 Mar 2005 17:43:00 -0800

I run multiple high speed interrupts on a system (mega16) with most enabling
the interrupt flag right after entry.  I have many, many overlapped and
aligned interrupts and never have had a problem with the processor locking
up.  Of course, I understand exactly how each interrupt source works and
make sure there are enough cycles (and stack) to get the job done.

For stack you need to understand how deep the nesting can get and make sure
your stack is big enough.  If it is possible for an interrupt handler to
interrupt itself (and I do that too) then you need to be double aware of the
timing issues, or, put in some sort of check for maximum nest and then stop
re-enabling the interrupt source.

An example is a 1ms timer tick that runs tasks at 10 and 100ms intervals.
The 100ms task takes much longer than 1ms to run, but that is Ok, because it
always completes well before the next 100ms interval (I don't have the
particulars in front of me, but it takes something like 4-5ms to run).  All
this is going on while there is buffered high speed serial i/o (38400) and
multiple channels of quadrature encoder interrupts (~100k interrupts/sec)
and the entire system actually works and has about 1/2 the processor
available for running the foreground task (the user interface).

So, if your processor is locking up when interrupts get "too close
together", you have a misunderstanding of how to structure the interrupt
code.  Time to re-read the data sheet carefully and get out the debugger and
see just what "locking up" means.

Cheers!

-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of Jamie Morken
Sent: Thursday, March 17, 2005 2:01 PM
To: address@hidden
Subject: [avr-gcc-list] interrupts


Hi,

When in an interrupt service routine, and another interrupt is triggered
(ie. timer overflow) how does avr-gcc know to handle that other interrupt
once the current interrupt exits?  Does it go right to the next interrupt?

I am using the 16bit timer1 to do PWM code. OCR1A is set to the timer1
overflow interrupt, and it turns the dutycycle on, and sets the PWM
frequency.

OCR1B is set to the timer1 output compare interrupt and it turns the
dutycycle off, its valid range is zero to OCR1A for 100% dutycycle.

When I have these two interrupts triggering very close together (ie at a
high PWM frequency when OCR1A is a small number) the AVR will lock up.  I
guess this is because there is not enough time to execute both interrupt
service routines, so I have put a check in the code to make sure that the
two interrupts have a minimum amount of time between them being called and
it seems to work fine.

What other kinds of conditions are important to keep in mind to avoid
intermittent lock ups of the AVR when using interrupts?  I need to make sure
that the AVR doesn't reset, as it will be controlling a lot of inertia (me
at 10MPH+ on a dynamically balanced scooter) in real time! :)

cheers,
Jamie Morken




_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list





reply via email to

[Prev in Thread] Current Thread [Next in Thread]