Echelon Neuron C - Manual (Page 172)

152 Functions
domain/subnet/node address on the network. Typically, cloned devices are
intended for low-end systems where network tools are not used for installation.
The LonTalk protocol inherently disallows this configuration because devices
reject messages that have the same source address as their own address. The
update_clone_domain( ) function enables a device to receive a message with a
source address equal to its own address. There are several restrictions when
using cloned devices; see the NodeBuilder FX User’s Guide .
Important: This function has a mechanism that ensures that a reset or power
cycle during an EEPROM modification does not cause the device to go
unconfigured. This mechanism uses the error log to serve as a semaphore. Thus,
the error log is written to on every call to this function, even if the net effect of
the function is to not modify or write to the configuration data at all (because the
new contents match the old). Applications must minimize calls to this function to
ensure that the maximum number of supported writes for EEPROM is not
exceeded over the lifetime of the application.
More information about cloned devices can be found in the ISO/IEC 14908
(ANSI/EIA/CEA-709.1)
Control Network Specification .
Syntax
#include <access.h>
void update_clone_domain (domain_struct * domain , int index );
Example
#include <access.h>
domain_struct domain_copy;
void f(void)
{
domain_copy = *(access_domain(0));
// Modify the domain copy as necessary
update_clone_domain(&domain_copy, 0);
}
update_config_data( ) Function
The update_config_data( ) function copies from the structure referenced by the p
configuration data pointer parameter to the config_data variable. The
config_data variable is declared const, but can be modified through this function.
The config_data variable is automatically defined for every program in the
<echelon.h> file.
Important: This function has a mechanism that ensures that a reset or power
cycle during an EEPROM modification does not cause the device to go
unconfigured. This mechanism uses the error log to serve as a semaphore. Thus,
the error log is written to on every call to this function, even if the net effect of
the function is to not modify or write to the configuration data at all (because the
new contents match the old). Applications must minimize calls to this function to
ensure that the maximum number of supported writes for EEPROM is not
exceeded over the lifetime of the application.