Now that we've seen the basics of handling interrupts, let's
take a look at some more details and some advanced topics.
Interrupt environment
When your ISR is running, it runs in the context of the process that attached it, except with a different stack. Since the
kernel uses an internal interrupt-handling stack for hardware interrupts, your ISR is impacted in that the internal stack
is small. Generally, you can assume that you have about 200 bytes available.
Ordering of shared interrupts
If you're using interrupt sharing, then by default when you attach an ISR using InterruptAttach() or InterruptAttachEvent(), the new ISR goes to the beginning of the list of ISRs for that interrupt. You can specifically request that your ISR be
placed at the end of the list by specifying a flags argument of _NTO_INTR_FLAGS_END.
Interrupt latency
Another factor of concern for realtime systems is the amount of time taken between the generation of the hardware interrupt
and the first line of code executed by the ISR.
Atomic operations
Some convenience functions are defined in the include file <atomic.h> — these allow you to perform atomic operations (i.e. operations that are guaranteed to be indivisible or uninterruptible).
Interrupts and power management
In order to help the kernel save power, you can make an interrupt "lazy" by specifying an acceptable latency for it.