Re: Re:Positional/physical addressing

On 6/24/2025 10:05 AM, Don Y wrote:

On 6/24/2025 9:49 AM, Don Y wrote:

On 6/24/2025 9:18 AM, Martin Rid wrote:

CAN network?

>
Each CAN node either needs a unique address to which messages can be
directed;  *or*, to KNOW to listen for particular BROADCAST messages.
>
So, you either send a message to node 5 to do something
OR, you send a message about that something and expect
that node to know that *it* should process that message.
>
If all of the nodes are *identical* (hardware and software),
there is nothing to distinguish one device from any other.

 By way of example, in the 70's, we would do "poor man's networking"
by daisy-chaining IDENTICAL devices with serial ports:
 HOST---->[]----->[]---->[]----->[]
 (each set of brackets represents a device with its serial input
on the left side and output on the right)
 The point is, ALL of the devices are identical, run identical
software, etc.  Their physical position in the chain determines
their "address".

To pick nits, the communications stack needs to be identical.
I.e., from the network's point-of-view, all devices look the
same.  But, the application layer can be completely different.
Typically, *a* HOST is used to perform network discovery and
manage the configuration.  It can distribute any necessary
information to the individual nodes after it has sorted out
what's attached.
E.g., "4Thou art number four" would effectively tell the 4th device
that it is the "four"-th device.  It could query the device type of
4 -- along with the other nodes -- and convey this information to
those nodes.  E.g., "1Number one, be aware that number four controls
the air pressure in the process vessel", "2Number two, be aware that
number one controls the temperature of the inlet air", etc.
Note, also, that the devices can return results to the HOST
(imagine the serial out of the last device being routed back
to the serial in of the host -- through the same cable*S* that
carried the packets down to that last device).
And, with such a loop in place (and the HOST participating like
the other devices), device N can send a message to device 3
as well as expect a reply back.
Also, the application decides how to best utilize the bandwidth
available.  E.g., HOST can just keep sending messages to device
#6 without ever bothering to talk with any of the other devices.
Finally, the content of the messages can be whatever the
application deems appropriate.  E.g., I could say "6ON", "6OFF",
"6ON", "6OFF"...   Or, "6BLINK"; the devices determine how they
will respond to specific messages (commands).  So, I can trade
bandwidth for local processing, as needed.