Question about rtems_irq_symbolic_name, rtems_vector_number and IRQ stuff.

[Pavel Pisa]

Thanks much for your replies (Joel and Jay).

On Tuesday 19 October 2004 23:00, Joel Sherrill <joel at OARcorp.com> wrote:
> And are all over one of the area of RTEMS that I want to clean up.

OK, I have to live with actual state for next month due to the actual
first development phase deadline.
I would like to co-operate with you and others on enhancements in this area.
I would like to add port of our LinCAN (http://freshmeat.net/projects/lincan/)
to the RTEMS and it would require context pointer in IRQ.

> > 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.
...
> It isn't implemented now.  Till Straumann 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.
>

AGREE, agree, may be, that vector number and context (void *) pointer
is the best ISR arguments combination. This is what Linux and even WinNT+ have

Linux:
  irqreturn_t uld_irq_handler(int intno, void *dev_id, struct pt_regs *regs)
WinNT:
  BOOLEAN uld_irq_handler(IN PKINTERRUPT intno, IN PVOID dev_id)


> > 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.

OK.

> > 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?

We have decided to give try to M9328 MX1 one and half year ago.
When I looked for ARM920T BSP I have found Cogent's CSB336,
so I have reused and modified it for our target.
It should be declared as new BSP in the longer run.
Our board is of Business Card size. It contains 32MB SDRAM
(connected by 16bit bus only), 4-32MB StrataFlash, USB device 
transceiver and connector, TTL RS-232 connector, keyboard, LCD and CMOS
camera connectors, reduced JTAG connector and two 50 pin connectors
with many IO and 16-bit separate IO expansion bus
(D0-D15, A1-A15 and three chipselects).
New revision would contain even DM9000 100/10 ETHERNET controller
with integrated transformer connector onboard or on the cable.
We would publish our schematic and pictures on PiKRON's pages,
when I find some time for that. If we would be able to succeed
with our pilot project, we could offer this to third parties as well.
We expect policy similar to LART for schematics and GPL/MPL
for generic parts of the code.

What is nice on MX1 when compared to XScale, that above described board
requires only 20mA at 5VDC to run on 96MHz. Even with 320x240 gray scale display
with backlight we are at 80mA. So USB socket is all you need for development.
This is with ETHERNET switched off. DM9000 takes another 90mA when it is on.
 
> >   - 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?

This is device/client side. 

Again thanks for your reply, 

                Pavel Pisa
        e-mail: pisa at cmp.felk.cvut.cz
        www:    http://cmp.felk.cvut.cz/~pisa
        work:   http://www.pikron.com