Interrupt latency – Echelon Neuron C User Manual

Page 174

Advertising
background image

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

Advertising