Question about rtems_irq_symbolic_name, rtems_vector_number and IRQ stuff.

[Pavel Pisa]

Greeting to all RTEMS developers,

I have more RTEMS IRQ handling related questions.

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.

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)

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?

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.
    
I have tried to go through sources, but SCORE cares little about
above problems :-) and BSPs where it is implemented are fuzzy.
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.
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 have got lost within above problems when implementing SPI driver
for our M9328 MX1 ARM920T system.

What I have done and could offer till now:

  - 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

  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.

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.

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.

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