There exists a special use-case for data handling in a situation where multiple self-addressing devices are using the same bus for communication. In the common case self-addressing devices work as follows:

1. Each device has hardcoded unique piece of information to be used as a seed value for addressing (lets call this “serial number” for simplicity)
2. Upon powering up, the devices negotiate with each other, either on the common bus (think application CanBUS) or nondocumented/out-of-band means
3. During the negotiations, the devices agree about bus addresses of each device, based on presence of each device and everyone’s serial

Self-addressing bus is presented briefly in the image below.

Okay, so far so good. But what happens if the number of devices on the bus changes? There are multiple ways to deal with the situation. In case of new devices, one possibility is to assign the new devices with next, unused bus addresses. But how about when we lose devices? Should we just drop those bus addresses and be happy with it? There is no one size fits all -solution for the total problem, but a reasonable solution for situations where the number of devices is comparably small is to always re-negotiate the bus addresses. Another possibility is to regard missing devices as missing but in-place and re-negotiate only if the new device takes a bus address already in use.

Identifying a bus address change can be made with a couple of techniques. One possibility is to have a register status bit announce a change condition. Another possibility is to send announcement messages for a sufficient amount of time. External shared DIO can also be used in some contexts. And of course, there is the pathological case of reading all serial numbers during all communication rounds, but this is usually something we should try to avoid, and especially if we are designing the actual bus operation.

Let’s define next what is bus data and device address in a self-addressing bus. Bus data is verbatim, contemporary data read from a device on the bus. The bus data can tell it came from a certain bus address, but it cannot directly tell that it came from a certain physical device (though this information is attainable). Device address is something allocated by the system controlling the devices. It is semi-permanent, conceptual address we use in consistently in user interfaces to differentiate between devices. To recap:

1. Device address is used for user interfaces, does not change in practice
2. Bus address is somewhat volatile indication of where the current bus data came from
3. Bus data is various readouts from the device (like voltage, power, etc)

Let’s make short example to clarify how bus address change happens. Let’s say we first have device A with bus address 1. Now, device B comes present on the bus and devices re-negotiate their bus addresses. Device B now gets bus address 1. Device A will switch from bus address 1 to bus address 2. Any cached bus address 1 data needs to be properly invalidated or repurposed.

We have now somewhat adequately described what is bus data and how does it react to address changes. But to make it very clear, we should regard bus data as volatile information, something we might not be able to re-read in the future, rendering the old data outdated. So, what is the non-volatile version of bus data? We can call it device data, or if we want to put it more finely, entity data. In normal operation, device data is linked to bus data. This glue mechanism is called inventory. The linking of bus data to device data is maintained by keeping a record of device serial number in device data. We also have a placeholder for the serial number in bus data (we read serial number bus data only when there is an address change situation).

Small sketch of inventory system managing bus and device data is presented below.

Now, in the event of addressing changes in the system the following happens:

1. All links between all bus data and device data are cut
2. Bus data is zeroed so it does not cause trouble or confusion
3. Complete bus data is read from all available device address
4. Serial numbers between device data and bus data are compared; if there is a match, bus data and device data are linked
5. Special cases are handled

Let’s finally list some of the special cases and the accompanied actions

• New device appears on bus => If there is space, allocate new device address
• Device leaves bus => Keep device data and device address, but mark device non-communicating
• New device replaces old device => Ask user to acknowledge configuring to new device as the old device was
• System startup => Request a mapping of device addresses, serial numbers, and configuration data, then scan bus devices and if the same serial numbers are found, configure the devices accordingly

With all the previous stated we have covered majority of decoupling address and entity/device data in a self-addressing bus environment. We learned that bus data can become obsolete fast and that the real device data should be kept on a separate data structure, with 2-way links between device data and bus data. We also learned about addressing change circumstances and the special cases involved with them.