Interrupt latency – Echelon Neuron C User Manual
Page 174

162 Additional
Features
Example:
unsigned long globalVariable;
void f() {
__lock {
globalVariable = ...;
}
}
interrupt(IO_3, clockedge(-)) {
__lock {
f();
}
}
Because the interrupt task acquires the semaphore and then calls function f(),
the second lock request (the __lock{ } construct within the function f()) can never
succeed. The chip resets after the watchdog timer expires, and a system error is
logged.
While an interrupt task cannot perform network activity, it can read and
evaluate values for network variables and configuration properties. You can
guard those operations with a __lock{ } statement to synchronize between the
interrupt task and the when tasks, but you cannot guard against asynchronous
updates to these variables as they arrive over the network.
In an application that requires an interrupt task to read such data, it is
recommended that the appropriate when task creates a locked copy of the
relevant data, which can be safely accessed from the interrupt task.
Interrupt Latency
Interrupt
latency
is the amount of time that elapses between the generation of an
interrupt by a device and the running of the associated interrupt task.
Variations in this latency for servicing interrupts can lead to jitter in output
signals generated by an interrupt task, or otherwise affect the algorithm
performed by the interrupt task. This section describes the latency required by
the system firmware, the Neuron C application, and the interrupt task.
When a Neuron C application contains one or more interrupt tasks, the Neuron C
compiler generates an interrupt dispatcher that is added to the application. The
system firmware calls this dispatcher when an interrupt is triggered.
When the system firmware receives an interrupt request from the hardware, the
firmware prepares to run the interrupt task. This preparation adds the following
latency to interrupt processing:
• 54 clock cycles if interrupt tasks run on the interrupt (ISR) processor
• 115 clock cycles if interrupt tasks run on the application (APP) processor
This preparation occurs once for each hardware interrupt request, regardless of
the number of interrupt tasks defined within the application. Interrupts run on
the ISR processor for system clock multiplier settings of 2 or higher (20 MHz or
higher), or interrupts run on the application processor for system clock multiplier
settings of ½ or 1 (5 or 10 MHz).