Serial protocol with physical decoding - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Serial protocol with physical decoding
On 5/7/2017 7:21 AM, Les Cargill wrote:
Quoted text here. Click to load it

In the pinball example, the guy who designed the wiring harness
knows what order the "nodes" are visited by the wire -- and, this
order doesn't change from machine to machine.

The order is unlikely to change -- after manufacture or deployment.
This is not true of "computers" and devices with assigned addresses.

Also, as there will be an inherently LIKELY order, it will be trivial
to deduce the order and adjust a table (that would almost surely
exist) in the software.  E.g., it would be unusual for the light
adjacent to the left flipper to be followed by the light in the top
RIGHT pop bumper and then the right flipper, then the top left pop
bumper then the light adjacent to the very first light... etc.

Quoted text here. Click to load it

"Minutes"?

Quoted text here. Click to load it

Assigning addresses in this scheme would be trivial:
      3 ADDRESS 14
would cause the first 3 devices to propagate the command
thereby informing the fourth device (in the chain) that
its address is "14".  But, what does that buy you?  Unless
you can then reconfigure the network to a bus topology
(to eliminate the processing delay through each device)

Quoted text here. Click to load it

In the daisy-chain case, its not possible for more than
one device to process a message intended for *one* device.
(You could implement a message that is designed to be
processed by some subset of devices -- even things like
"every other", "every third", etc.)

Quoted text here. Click to load it

OK, I'll ADD the wire back into the bundle -- and just
mark it "spare".  Does that feel better?  Maybe add two or
three, just in case?

Why doesn't RG6 have a spare conductor?  Seems silly to only
use 2; then have to deal with power injectors when you want
to power an in-line amplifier up on the mast...

Why not run 4-pair (or 2-pair) around the interior of an
automobile so the various modules can implement ethernet to
talk to each other?

Or, put a NIC at each of those lamps on the pinball playfield?

You're also ignoring the fact that the devices then become
identical.  You (user) can replace ANY failed/suspect device
with a generic device of the same type -- without having
to do any followup configuration of the device or the
system.

I've been surprised at how many (sub-)applications I have that
can benefit from NOT needing to configure specific devices
to have specific addresses; cases where it would be great if
a user could simply replace a defective unit with a factory
fresh one without also having to "configure" it.

But, that's largely possible because I can control the cabling
technology and topology.

E.g., whenever I add another node to the network in the office,
I have to run a hole new wire from the switch, FOLLOWING the
existing wire bundle as it makes its way around the room to
the location of the new node.  20 years ago, I'd just unplug
the coax feeding the device "downstream", insert the new node
with an appropriate length of coax to that downstream node
and be done with it.

[Of course, the network is disturbed *while* this is happening
(as the downstream PORTION would be in my daisy-chain scheme)
but that's an infrequent event and one in which I participate]

Nowadays, I have to track the lengths of all of the cables
leaving the switch(es) -- so I have an idea how long of a cable
I will need to service a new addition:
    "I'm going to be locating this new node between the color printer
     and the VM server.  The cable to the printer is 13 ft long
     and the VM server is 18 ft.  So, aim for about 15 ft and hope
     for the best (cuz there's no place to "store" any service loops
     and coming up short will mean removing the cable from the bundle
     and starting over)"

OTOH, I can move the color printer to another *room* and not have
to change any configuration tables!  (wouldn't have had to with
10Base2, either, but WOULD have with this daisy-chain scheme)

Quoted text here. Click to load it



Re: Serial protocol with physical decoding
Il giorno domenica 7 maggio 2017 16:16:24 UTC+2, Les Cargill ha scritto:
  
Quoted text here. Click to load it

If you know the position of the devices, you can use something simila to LIN Bus Shunt Method to autumatically address the devices.
But you need some additionaly circuitry.

Bye Jack

Re: Serial protocol with physical decoding
wrote:

Quoted text here. Click to load it

You would need two fields, one the 'Target Address' and a 'Address
Counter'

The Target Address is the device to  be controlled.
The Counter address is the Address that each device increments and
passes to the next device.

But I don't see why a 8 pin address header is a bad idea. You can
still do a pass thru serial chain. plus the devices dont need to
enumerate.

I've done a 2 device serial pass thru chain, but they were hard coded
addresses.

Cheers



Re: Serial protocol with physical decoding
On 5/6/2017 9:14 AM, Martin Riddle wrote:
Quoted text here. Click to load it

No.  The "address counter" serves dual purpose:  when the count
attains '0', the message is intended for the current device.
I.e., it indicates the number of devices *upstream* from the
targeted device that should be skipped.

[Of course, you can define other semantics]

Quoted text here. Click to load it

The only advantage, there, is that it then *tells* the device what it's
position (address) happens to be.  If such a capability was needed,
you could kludge that capability into this structure -- incurring that
overhead only when needed.

Quoted text here. Click to load it

Depends on the number of devices, the distance between them, the
nominal data rates, etc.  E.g., if you have to handle a network
spanning hundreds of feet, you'd want to minimize the number of
conductors (and associated line drivers/receivers).  If you wanted
to handle a network with hundreds of "devices" (note that a device
is an arbitrary construct -- a physical device could, potentially,
consist of 30 devices, if you opted to treat them as such!), then
the width of the address field could exceed a fixed size.

The logical idea of increasing the width of the address field then
penalizes smaller networks as well as impacting maximum data rate
(more symbols to xmit with "no" information content!).  So, you could
encode the "address"/ID in a manner that allows for it to expand to suit
the needs of the particular network/message -- without unduly burdening
short messages/nearby targets or long messages/distant ones.

Quoted text here. Click to load it

So far, the problems that I've identified are related to error analysis
(and recovery) along with distributed clock synchronization.  Hard failures
are (relatively) easy to address:  fix the damn thing!  :>

Re: Serial protocol with physical decoding
wrote:

Quoted text here. Click to load it

Go over to Hack-a-day, theres someone that daisy chained some audrinos
and just let each audrino grab the last 5 bytes of the control packet
and send the remaing bytes to the next device. Addressing is by the
position of the data in the packet.
He has no error control, but the idea of all the devices running the
same code is what your looking for.


Cheers

Re: Serial protocol with physical decoding
On 5/8/2017 3:53 PM, Martin Riddle wrote:
Quoted text here. Click to load it

The code is trivial.  The question concerns identifying "issues"
to which this approach might be more vulnerable (see above).

For example, if messages "dissipate" when they reach their intended
node, then nodes at the far end see much less traffic than near-end
nodes.  They spend less resources processing (propagating) messages
than their upstream peers.  And, they also are slower to notice when
the network has *crashed*.

Etc.


Site Timeline