Catching Interrupts

[Mark VanderVoord]

OK, some progress!  I looked through the interrupt
code in libcpu as Joel suggested.  It is combining the
results of the cause and ir registers to create a
single variable representing the vector number. 
Therefore, instead of catching vectors 4 or 5, I
really wanted 44 and 45.

My ISR is now running properly.  Thanks for the help!

On a related note, I am a little unclear on how the
interrupt handling occurs.  This is how it seems to
work from my reading of the documentation:
 
The interrupt is directed to RTEMS, which immediately
preempts the currently running task with the ISR if
the priority mask of the task is sufficiently low (I
am currently running with all tasks with a priority of
0, therefore they are always preempted).  Once the ISR
is completed, RTEMS determines if a higher priority
task should be run instead of the original, as a
result of actions of the ISR.

I have set up an ISR which sends an event to a task. 
The task being sent is the highest priority task in my
system.  The event is being used to let the task know
when SPI (SSI) has completed a send or receive.  The
task runs at a rate monotonic period of every 2msec.

The reason that I question my understanding of RTEMS
ISR's is this:  the SSI task actually takes more cpu
time when it is using this method than when I was
directly polling the SSI register!  How is that
possible?  Also, I am much more likely to run over the
top of the RMS period running off of interrupts.  This
seems counterintuitive to me.

Could someone give my some insight? 

Thanks again!

Mark VanderVoord
Self-Guided Systems, LLC.


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com