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