Echelon Neuron C - Manual (Page 173)

Neuron C Programmer’s Guide 161
Sharing Data with an Interrupt Task
In general, an interrupt task can access any data that the main application can
access. There are times when you might want an interrupt task to share data
with the main application. Sharing data between asynchronous processes can
lead to data integrity problems, so you should exercise care when sharing data.
Important: An interrupt task can read data that is declared with the eeprom
keyword, but cannot write to it. The firmware logs system error 48 when it
detects an attempt to write to eeprom data. Writing to an EEPROM or flash
memory device is a time-consuming task that is not supported within an
interrupt context. To ensure that eeprom data is written, the interrupt task
should update an appropriate flag, and allow the main application to write the
eeprom data.
When an interrupt task runs runs in the ISR processor, the system firmware
provides a binary semaphore to synchronize access to shared resources between
the application and the ISR processor. However, when an interrupt task runs
runs in the application processor, there is no semaphore available, and you must
manage resource sharing as you would for other function types (such as callback
functions).
You use the Neuron C __lock keyword within the application or the interrupt
task to access this semaphore and synchronize access to shared resources. The
__lock keyword defines a block of code (within a pair of curly braces) that is
controlled by the semaphor.
The __lock keyword is not supported for the lowest system clock rates (5 MHz
and 10 MHz). However, you can use it within either Neuron C code or pure C
code (for example, within a library).
Example:
interrupt (IO_0) {
... // do something not guarded by the semaphore
__lock { // acquire semaphore
... // do something guarded by the semaphore
}
// release semaphore
... // more unguarded code
}
Because there is only one semaphore, you cannot nest locks. Nested locks yield a
compiler error, NCC#585. Defining a lock with target hardware or firmware that
does not support semaphores yields a linker error, NLD#506. If you define a lock
for an interrupt task that runs within the application processor, the Neuron
Exporter issue a warning message (NEX#4014) that the hardware semaphore
and the __lock{ } statement are not operational for the specified system clock
setting. In addition, when the interrupt task runs, no semaphore is acquired, but
a system error is logged.
You can define a lock both in Neuron C code and in pure C code (such as a
function library).
While the compiler can detect and prevent direct nesting of __lock{ } statements,
it cannot detect runtime-nesting of lock requests. Consider the following
example.