Question about rtems_irq_symbolic_name, rtems_vector_number and IRQ stuff.
ppisa4lists at pikron.com
Tue Oct 19 15:27:59 UTC 2004
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
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
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
e-mail: pisa at cmp.felk.cvut.cz
More information about the users