Updated: October 28, 2024 |
Attach an Interrupt Service Routine (ISR) that returns an array of sigevents to an interrupt source
#include <sys/neutrino.h> int InterruptAttachArray( int intr, const struct sigevent * const *(*handler)(void *, int), const void *area, int size, unsigned flags); int InterruptAttachArray_r( int intr, const struct sigevent * const *(*handler)(void *, int), const void *area, int size, unsigned flags);
For more information, see Flags, below.
libc
Use the -l c option to qcc to link against this library. This library is usually included automatically.
The InterruptAttachArray() and InterruptAttachArray_r() kernel calls attach the Interrupt Service Routine (ISR) identified by handler to the hardware interrupt specified by intr. They automatically enable (i.e., unmask) the interrupt level. These functions are identical except in the way they indicate errors; see the Returns section for details. They're similar to InterruptAttach() and InterruptAttach_r(), except that the handler must return either NULL or a NULL-terminated array of sigevent structures. Attaching an ISR superlocks the process's memory (see Locking memory in the Process Manager chapter of the System Architecture guide).
Before calling InterruptAttachArray() or InterruptAttachArray_r(), the process must have the PROCMGR_AID_INTERRUPT ability enabled. Otherwise the attachment fails with an error code of EPERM. For more information, see procmgr_ability().
On a multicore system, the interrupt handler runs on the CPU that takes the interrupt.
Interrupt vector numbers
The interrupt values for intr are logical interrupt vector numbers grouped into related interrupt classes that generally correspond to a particular interrupt controller on the CPU.
There can be additional interrupt classes defined for specific CPUs or embedded systems. For the interrupt assignments for specific boards, see:
The mapping of logical interrupt vector numbers is completely dependent on the implementer of the startup code. Device drivers should generally allow runtime configuration of interrupt numbers.
Interrupt handler function
The function to call is specified by the handler argument. Its prototype is:
const struct sigevent * const *(*handler)(void *area, int id);
The arguments are:
The handler function runs in the environment of your process.
Follow the following guidelines when writing your handler:
The handler can call TraceEvent(), but not all of its commands are valid.
The handler function should return NULL or a NULL-terminated array of sigevent structures that the kernel delivers. The event doesn't need to be registered. These events are defined in <signal.h>. Consider the following when choosing the event type:
(QNX Neutrino 7.0.4 or later) In order to use an event of type SIGEV_THREAD, your process must have the PROCMGR_AID_SIGEV_THREAD ability enabled.
Flags
The flags argument is a bitwise OR zero or more of the following values:
The interrupt structure allows hardware interrupts to be shared. For example, if two processes take over the same physical interrupt, both handlers are invoked consecutively. When a handler attaches, it's placed in front of any existing handlers for that interrupt and is called first. You can change this behavior by setting _NTO_INTR_FLAGS_END. Although the microkernel allows full interrupt sharing, your hardware might not.
Processor interrupts are enabled during the execution of the handler. Don't attempt to talk to the interrupt controller chip. The operating system issues the end-of-interrupt command to the chip after processing all handlers at a given level.
The first process to attach to an interrupt unmasks the interrupt. When the last process detaches from an interrupt, the system masks it.
If the thread that attached the interrupt handler terminates without detaching the handler, the kernel does it automatically.
Normally, InterruptAttachArray() and InterruptAttachEvent() automatically unmask an interrupt the first time something is attached to it. If you specify _NTO_INTR_FLAGS_NO_UNMASK, the kernel leaves the interrupt masked, and you must specifically call InterruptUnmask() to enable it.
The _NTO_INTR_FLAGS_TRK_MSK flag and the id argument to InterruptMask() and InterruptUnmask() let the kernel track the number of times a particular interrupt handler or event has been masked. Then, when an application detaches from the interrupt, the kernel can perform the proper number of unmasks to ensure that the interrupt functions normally. This is important for shared interrupt levels.
The OS uses _NTO_INTR_FLAGS_ARRAY internally to indicate that the handler was attached with InterruptAttachArray().
Blocking states
These calls don't block.
An interrupt function ID. If an error occurs:
Use the function ID with the InterruptDetach() function to detach this interrupt handler.
Safety: | |
---|---|
Cancellation point | No |
Interrupt handler | No |
Signal handler | Yes |
Thread | Yes |
If you're writing a multithreaded resource manager using the thread_pool_*() functions, and the thread that has called InterruptAttachArray() is also joining the thread pool by calling thread_pool_start() with POOL_FLAG_USE_SELF set, then that thread must also set _NTO_INTR_FLAGS_PROCESS in the flags argument when calling InterruptAttachArray(). If it doesn't, the thread may exit as part of the thread pool's dynamic threading behavior, and the interrupt handling will then be lost.