Sujet : Re: Re:Positional/physical addressing
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.designDate : 24. Jun 2025, 18:05:06
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <103elsj$24a8c$2@dont-email.me>
References : 1 2 3
User-Agent : Mozilla Thunderbird
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)
If I pass a message (from the host) of the form "1xxxxxx", the
first device receives the message, notices that it begins with
a '1' and assumes it is meant for it; the message is absorbed
by that device.
If the message is of the form "2xxxxxxx", the first device receives
the message, notes that it does NOT begin with a '1' and, therefore,
is not intended for it's use. It "decrements" the first character
('2') and passes along the message payload ("xxxxxx") with this
new "address" -- "1xxxxxxxx".
The SECOND device sees this message, notes that the first character
is a '1' and assumes it is meant for it; the message is absorbed by
this SECOND device.
[There are other equivalent schemes]
The point is, ALL of the devices are identical, run identical
software, etc. Their physical position in the chain determines
their "address".
Note that the HOST can begin sending the next message immediately;
devices have stored (temporary) copies of earlier messages so the
communication link need not be left idle while earlier messages
percolate down the chain.
The problem with this approach is that any device failure renders
inoperative everything downstream!
[This approach also introduces latency proportional to the
"distance" (number of hops) from the HOST. But, there are
ways around that.]