Newbie interrupt question

QNX Newsgroups (Archives) qnx.bsp
1

I’m a QNX newbie, (recovering VxWorks user). I’m starting to port over
the interrupt code from our VxWorks solution to QNX. In VxWorks, our
interrupt functions just handled everything since everything runs in the
same process space with direct access to the hardware. (MPC8245 based)

Now, I’m not sure what the best way (or normal way) to handle interrupts
in QNX. Should only the most basic stuff (unmasking, masking,etc.) be
handled in the callouts; or should everything interrupt related be
handled in the callouts. Handling everything in the callouts would be
kind of painful since it’d all be in assembly.

Advice greatly appreciated.

Thanks,

John K.

2

John Kiernan <jkiernan@birinc.com> wrote:

I’m a QNX newbie, (recovering VxWorks user). I’m starting to port over
the interrupt code from our VxWorks solution to QNX. In VxWorks, our
interrupt functions just handled everything since everything runs in the
same process space with direct access to the hardware. (MPC8245 based)

Now, I’m not sure what the best way (or normal way) to handle interrupts
in QNX. Should only the most basic stuff (unmasking, masking,etc.) be
handled in the callouts; or should everything interrupt related be
handled in the callouts. Handling everything in the callouts would be
kind of painful since it’d all be in assembly.

There are several layers to this.

The callouts supplied by the startup code to the OS are supposed to
ONLY handle the interrupt controller – so mask, unmask, id, eoi, etc.

For drivers, they generally use either InterruptAttach() to associated
a C function with a particular logical interrupt vector (as defined by
startup), or InterruptAttachEvent() to request notification when a
particular interrupt fires.

For drivers, the choice of using InterruptAttach() or InterruptAttachEvent(),
often comes down to a latency issue – Attach() has the best latency, but
can be more system expensive. Generally, IntteruptAttach() associates an
interrupt handler (or ISR) with a particular hardware interrupt – this
code will talk to the particular card generating the intterupt, reading
status register(s), writing control register(s), and copying information
from hardware memory to RAM. It will generally then notify a thread in
the driver process to do any further data handling.

With AttachEvent(), all the hardware work is done at thread time, with
the interrupt essentially causing a thread to be scheduled.

For example, something like a uart (no FIFO) where if you don’t get a
byte, the next one destroys it, is a place where you’d generally attach
an ISR, while a network card, with largish on-card buffers, is a place
where you might tend to attach an event.

Hope this helps to clarify a bit.

-David

Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com

3

David Gibbs wrote:

There are several layers to this.

The callouts supplied by the startup code to the OS are supposed to
ONLY handle the interrupt controller – so mask, unmask, id, eoi, etc.

For drivers, they generally use either InterruptAttach() to associated
a C function with a particular logical interrupt vector (as defined by
startup), or InterruptAttachEvent() to request notification when a
particular interrupt fires.

For drivers, the choice of using InterruptAttach() or InterruptAttachEvent(),
often comes down to a latency issue – Attach() has the best latency, but
can be more system expensive. Generally, IntteruptAttach() associates an
interrupt handler (or ISR) with a particular hardware interrupt – this
code will talk to the particular card generating the intterupt, reading
status register(s), writing control register(s), and copying information
from hardware memory to RAM. It will generally then notify a thread in
the driver process to do any further data handling.

With AttachEvent(), all the hardware work is done at thread time, with
the interrupt essentially causing a thread to be scheduled.

For example, something like a uart (no FIFO) where if you don’t get a
byte, the next one destroys it, is a place where you’d generally attach
an ISR, while a network card, with largish on-card buffers, is a place
where you might tend to attach an event.

Hope this helps to clarify a bit.

That helps a lot, I’m sure when I start implementing this I’ll have many
more questions… Thanks!!

John

4

The BSP is meant to take care of managing the CPU and chipset interrupt
hardware so your code should only have to talk to the hardware it is
written for.

Regarding memory mapping:

  • InterruptAttach()'s ISR heap space is mapped to your process space
    so using the same globals you were already using in VxWorks will also
    work fine.

  • InterruptAttachEvent() only delivers an event to your process/thread
    so all coding is within your process space.


    Evan

5

Hi,

I am new to interrupts and QNX. I wanted to know where should I look for
the Interrupt vector number table if I want to connect to any of the
timer/counter pind of sh4 platform

Thanks
Rohini


David Gibbs wrote:

John Kiernan <> jkiernan@birinc.com> > wrote:
I’m a QNX newbie, (recovering VxWorks user). I’m starting to port over
the interrupt code from our VxWorks solution to QNX. In VxWorks, our
interrupt functions just handled everything since everything runs in the
same process space with direct access to the hardware. (MPC8245 based)

Now, I’m not sure what the best way (or normal way) to handle interrupts
in QNX. Should only the most basic stuff (unmasking, masking,etc.) be
handled in the callouts; or should everything interrupt related be
handled in the callouts. Handling everything in the callouts would be
kind of painful since it’d all be in assembly.

There are several layers to this.

The callouts supplied by the startup code to the OS are supposed to
ONLY handle the interrupt controller – so mask, unmask, id, eoi, etc.

For drivers, they generally use either InterruptAttach() to associated
a C function with a particular logical interrupt vector (as defined by
startup), or InterruptAttachEvent() to request notification when a
particular interrupt fires.

For drivers, the choice of using InterruptAttach() or InterruptAttachEvent(),
often comes down to a latency issue – Attach() has the best latency, but
can be more system expensive. Generally, IntteruptAttach() associates an
interrupt handler (or ISR) with a particular hardware interrupt – this
code will talk to the particular card generating the intterupt, reading
status register(s), writing control register(s), and copying information
from hardware memory to RAM. It will generally then notify a thread in
the driver process to do any further data handling.

With AttachEvent(), all the hardware work is done at thread time, with
the interrupt essentially causing a thread to be scheduled.

For example, something like a uart (no FIFO) where if you don’t get a
byte, the next one destroys it, is a place where you’d generally attach
an ISR, while a network card, with largish on-card buffers, is a place
where you might tend to attach an event.

Hope this helps to clarify a bit.

-David

Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com

6

Rohini <rohini_ct@yahoo.com> wrote:

Hi,

I am new to interrupts and QNX. I wanted to know where should I look for
the Interrupt vector number table if I want to connect to any of the
timer/counter pind of sh4 platform

Assuming the BSP was written by QNX, you should take a look at the
sample buildfile from the BSP – it should have a set of comments
describing the logical interrupt vector assignments.

-David

Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com

7

David Gibbs wrote:

John Kiernan <> jkiernan@birinc.com> > wrote:

I’m a QNX newbie, (recovering VxWorks user). I’m starting to port over
the interrupt code from our VxWorks solution to QNX. In VxWorks, our
interrupt functions just handled everything since everything runs in the
same process space with direct access to the hardware. (MPC8245 based)


Now, I’m not sure what the best way (or normal way) to handle interrupts
in QNX. Should only the most basic stuff (unmasking, masking,etc.) be
handled in the callouts; or should everything interrupt related be
handled in the callouts. Handling everything in the callouts would be
kind of painful since it’d all be in assembly.


There are several layers to this.

The callouts supplied by the startup code to the OS are supposed to
ONLY handle the interrupt controller – so mask, unmask, id, eoi, etc.

For drivers, they generally use either InterruptAttach() to associated
a C function with a particular logical interrupt vector (as defined by
startup), or InterruptAttachEvent() to request notification when a
particular interrupt fires.

For drivers, the choice of using InterruptAttach() or InterruptAttachEvent(),
often comes down to a latency issue – Attach() has the best latency, but
can be more system expensive. Generally, IntteruptAttach() associates an
interrupt handler (or ISR) with a particular hardware interrupt – this
code will talk to the particular card generating the intterupt, reading
status register(s), writing control register(s), and copying information
from hardware memory to RAM. It will generally then notify a thread in
the driver process to do any further data handling.

Which function should be used in the thread to get the notification?
Is it possible to have different notification types (ISR returning different events) to notify
different threads?

Thanks,

Armand

With AttachEvent(), all the hardware work is done at thread time, with
the interrupt essentially causing a thread to be scheduled.

For example, something like a uart (no FIFO) where if you don’t get a
byte, the next one destroys it, is a place where you’d generally attach
an ISR, while a network card, with largish on-card buffers, is a place
where you might tend to attach an event.

Hope this helps to clarify a bit.

-David

8

Armand Ciejak <armand.ciejak@free.fr> wrote:

Which function should be used in the thread to get the notification?

The blocking function that matches the type of notification that you
specify in the event structure returned from the handler, or passed to
the InterruptAttachEvent() call.

Is it possible to have different notification types (ISR returning
different events) to notify different threads?

Yes. But…

If you use a notification type of SIGEV_INTR, it will only unblock
an InterruptWait() in the thread that called the InterruptAttach*().

If you use signals or pulses, you can have different threads get them.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com