Question about rtems_irq_symbolic_name, rtems_vector_number and IRQ stuff.

Tue Oct 19 21:00:23 UTC 2004

Well I guess no one else wants to wade into the tar pit with me? :)

Pavel Pisa wrote:
> Greeting to all RTEMS developers,
> 
> I have more RTEMS IRQ handling related questions.

And are all over one of the area of RTEMS that I want to clean up.

The traditional RTEMS interrupt model (rtems_interrupt_catch, etc)
works great with CPUs that have enough vectors on the CPU to keep
you from having to include a PIC.  THe PowerPC and x86 (as implemented 
on a PC and nearly everywhere else) however tend to have a single
external interrupt source and then you have to go look at some
board dependent interrupt controller ot find out what happened.

This has lead to one interrupt model on every CPU except the
ARM, PowerPC and x86.  The PowerPC suffers from having the other
way of doing it and this is the "old exception model".  It is
(too) slowly being deprecated.

You are obviously on either a PowerPC or x86.

> 1) what is difference of types rtems_irq_symbolic_name, rtems_vector_number
>    Is there some function to convert one value to another or the value
>    is supposed to be equal? Or they are opaque and there is no public
>    relation between them.

I think that in general they are the same concept and different data
types from the different implementations of IRQ processing.  The
rtems_vector_number is simply an unsigned32 while the symbolic name
is an enum.

Long term merging the names together somehow is probably the right
thing to do.

> 2) Is there some declared way to get pointer to rtems_irq_connect_data
>    from rtems_vector_number in the ISR routine
>          xxxxx_isr(rtems_vector_number v)

That isn't the prototype for ISR handlers with the new exception model.
Unfortunately on the PowerPC, it is a void.

Till has a nice way to get an argument if that is what you want to do.
Eventually, I would like to see ISR's take a void * pointer as an
argument.  Unfortunately, this involves tinkering with all the ports.

> 3) Is it correct to use BSP_install_rtems_irq_handler in device like code
>    implemented in my application or rtems_interrupt_catch is supposed
>    to be used there exclusively?

If you are on a ARM, PowerPC, or x86, don't use rtems_interrupt_catch.
Use the other version.

> 4) Is there some way, how to block IRQ source in the ISR routine
>    until event is processed by worker thread? Only way I see from
>    the sources is to try to locate rtems_irq_connect_data and call
>    its off routine. But this could lead to some collision with
>    RTEMS internal use of this routine.

RTEMS proper does not use that code so there wouldn't be a conflict.
You can do that if you can get the structure.

> I have tried to go through sources, but SCORE cares little about
> above problems :-) and BSPs where it is implemented are fuzzy.

There are unfortunately two IRQ models and differences between the
APIs on the x86 and PowerPC.  This really needs to be addressed.

I have come to accept that two IRQ models makes some sense based
upon the differences in CPUs but the PowerPC and x86 need to have
the same interfaces.

> There is very important lack of feature in RTEMS IRQ handling.
> There have to be way, how to deliver some context pointer
> into ISR. I have seen some discussion about that already
> on the list, but I would like to know actual state of your mind.

It isn't implemented now.  Till has an extension for the PowerPC
(and maybe x86) and if it could be implemented in a sweep across
RTEMS ports, I would take it and merge it.

Modifying all RTEMS ports is a challenge.  But I killed 3 ports
after cutting the 4.6 branch so now is likely the best time to
ever do this.

> If it is problem to change ISR definition, it would be enough
> to provide (long) or (void *) "private" fields into rtems_irq_connect_data
> and define way, how to get from (rtems_vector_number) to the
> (rtems_irq_connect_data *). The private field could mean benefit even
> for xxxxx_isr_on(), xxxxx_isr_off() and xxxxx_isr_is_on() in some
> setups.

I think Till Straumann has what you are looking for.  I don't know
of a standard routine to do this.

> I have got lost within above problems when implementing SPI driver
> for our M9328 MX1 ARM920T system.

You are on an ARM.  I believe Till's patch could easily be adapted to
that.

> 
>   - USB loader and flasher for this target with Linux support application
>   - MicroWindows compatible UID keyboard driver for matrix keyboard
>     connected to GPIO. Implemented as worker thread driven by GPIO
>     interrupts and RTEMS time.
>   - MicroWindows changes to support framebuffer output on the target
>   - I2C driver with request queues running as RTEMS task

Is this BSP related to one of Cogent's?

>   some of the works can be downloaded from my page, other items can
>   be provided on request. If there is interrest I can put them
>   into Wiki pages when I find some spare time (not before mid of November). 
> 
>   I use August CVS snapshot of development RTEMS branch for my work.

Then if you modify any code to provide a way to get an argument
it could be merged easily.

> What I need to do:
> 
>   - SPI communication driver
>   - USB device support for MX1 UDC, I have it running outside of RTEMS
>     but I would be pleased, if there is some USB device framework defined
>     for RTEMS. If not, I can provide our simple code.

Is this host side or client side?

> There is even prepared and running simple flat widget library (SUITK).
> It enables to define screen in XML files and build screens
> from this description.

Neat.

> Thanks for replies in advance
> Best wishes
> 
>                 Pavel Pisa
>         e-mail: pisa at cmp.felk.cvut.cz
>         www:    http://cmp.felk.cvut.cz/~pisa
>         work:   http://www.pikron.com

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