Adding New Hardware Interrupts

Joel Sherrill joel.sherrill at
Tue Apr 8 17:28:26 UTC 2008

Robert S. Grimes wrote:
> Thomas Dörfler wrote:
>> No, as Joel pointed out, you should use the rtems_irq_* set of
>> functions, due to the (no longer so) new exception handling concept.
> Okay, will do - I'm glad I asked!  But where are these documented?
Maybe a readme somewhere but seriously this is an
area we need more documentation in.  I have started
to cover these in the class material so probably need
to look at rewriting the Interrupt Manager chapter
to discuss both styles of interrupt management and
which CPUs use which.

Or even better.. remove the chapter from the User's
Guide and move it to the BSP & Drivers Guide and then
re-write it. :-D

Volunteers appreciated or sponsored work. 
>> Ok, we already built in a tweak to handle the additional stuff, although
>> I am not sure whether it does all it should do.
>> If you look into c/src/lib/libbsp/powerpc/virtex/irq/irq.h , you will
>> find, that we already import a defintion from your Xilinx EDK named
>> "XPAR_INTC_MAX_NUM_INTR_INPUTS". If this is set to the real maximum of
>> all your FPGAs, then the irq handler functions are already aware of the
>> additional IRQ inputs and should treat them properly. So if you have a
>> total of 20 lines routed to your obpintc, (?), then you should be able
>> to install an interrupt handler for the highest IRQ source using the
>> following interrupt number:
> Okay, that should be workable.  I will have to rebuild my BSP, though,
> as the number of interrupts has increased.  Without looking (yet) at the
> code, I suppose the only cost to making that number largish is the size
> of table or two, right?
That should be it.
>> What is still missing is a set of definitions to give nice names to
>> these interrupt inputs and their numbers, but since you want to treat
>> them on application level, you should also name them their. So we might
>> find things like that in your code later:
>> appl_io.h
> Yes, of course!  ;-)
>> ...
>> Does this make sense for you?
> Yes, it does.  Your approach is certainly workable.  I do, of course,
> dream of a world where the Virtex BSP is as component-driven as the EDK
> peripheral model, but that is a lot more work; and right now, the
> current project deadlines are breathing down my deck  ;-)
It is always that way.  Just fix what you can fix, ask questions
and make suggestions.  This BSP is going to be a work in progress
for a while given the number of variations.
> Thanks, guys!
> -Bob

Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

More information about the users mailing list