Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26480 > unrolled thread

Serial protocol with physical decoding

Back to article view | Back to comp.arch.embedded

Contents

  Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-03 23:14 -0700
    Re: Serial protocol with physical decoding Clifford Heath <no.spam@please.net> - 2017-05-04 16:40 +1000
      Re: Serial protocol with physical decoding Mark Storkamp <mstorkamp@yahoo.com> - 2017-05-04 12:26 -0500
        Re: Serial protocol with physical decoding rickman <gnuarm@gmail.com> - 2017-05-04 15:46 -0400
    Re: Serial protocol with physical decoding Jack <jack4747@gmail.com> - 2017-05-04 00:28 -0700
      Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-04 00:48 -0700
        Re: Serial protocol with physical decoding rickman <gnuarm@gmail.com> - 2017-05-04 10:29 -0400
    Re: Serial protocol with physical decoding Reinhardt Behm <rbehm@hushmail.com> - 2017-05-04 16:44 +0800
      Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-04 07:09 -0700
    Re: Serial protocol with physical decoding Tim Wescott <tim@seemywebsite.really> - 2017-05-04 09:54 -0500
      Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-04 10:52 -0700
        Re: Serial protocol with physical decoding Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 14:53 -0500
          Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-04 13:17 -0700
            Re: Serial protocol with physical decoding Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:30 -0500
              Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-04 23:57 -0700
      Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-13 21:58 -0700
    Re: Serial protocol with physical decoding Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-05-05 00:50 +0200
    Re: Serial protocol with physical decoding Les Cargill <lcargill99@comcast.com> - 2017-05-04 18:47 -0500
      Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-04 20:07 -0700
        Re: Serial protocol with physical decoding Les Cargill <lcargill99@comcast.com> - 2017-05-07 09:21 -0500
          Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-07 10:22 -0700
          Re: Serial protocol with physical decoding Jack <jack4747@gmail.com> - 2017-05-08 00:04 -0700
    Re: Serial protocol with physical decoding Martin Riddle <martin_ridd@verizon.net> - 2017-05-06 12:14 -0400
      Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-06 12:29 -0700
        Re: Serial protocol with physical decoding Martin Riddle <martin_ridd@verizon.net> - 2017-05-08 18:53 -0400
          Re: Serial protocol with physical decoding Don Y <blockedofcourse@foo.invalid> - 2017-05-08 18:50 -0700

Page 1 of 2  [1] 2  Next page →

#26480 — Serial protocol with physical decoding

I want to push a bit stream through a series of *identical* devices
and have (identical) software running on each determine if that
particular device is being addressed, or not.

It seems like the simplest way to do so is to require each device
to examine an address field in the packet and, if '0', assume the
data that follows is intended for its consumption.  If not,
decrement the address and pass the packet along.

(I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
signals)

Of course, this means a failure of any device renders those that
follow it inaccessible.  That's acceptable.

It also means there is a latency proportional to the device address
inherent in the protocol.  Also acceptable (the data source can
take that into consideration when creating the message stream).
And, the incremental latency can be made pretty small.

Another downside is the cost of updating data on *all* (multiple)
devices as this requires N messages.

An alternate message format (or, a cleverer encoding of the above)
could be used to allow a single COMPOSITE message to be propagated
in which a node encountering a '0' address field strips the data
that is intended for its use and then reconstructs a message
bearing a '0' address field with the BALANCE of the data that it
then passes to the next device, in series.  In effect, letting
each subsequent device strip off "its" data before passing the
remainder along.

[When no data remains, the message dissipates]

As such, you could "address" any set of contiguous addresses
by creating an initial message of the form:
     <first_target_ID> <first_datum> ... <last_datum>
where the number of data present in the message implicitly defines
the *last_target_id* relative to the first_target_id.

Any problems with this sort of kludged encapsulation?

[toc] | [next] | [standalone]

#26481

On 04/05/17 16:14, Don Y wrote:
> I want to push a bit stream through a series of *identical* devices
> and have (identical) software running on each determine if that
> particular device is being addressed, or not.
>
> It seems like the simplest way to do so is to require each device
> to examine an address field in the packet and, if '0', assume the
> data that follows is intended for its consumption.  If not,
> decrement the address and pass the packet along.
>
> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
> signals)
>
> Of course, this means a failure of any device renders those that
> follow it inaccessible.  That's acceptable.
>
> It also means there is a latency proportional to the device address
> inherent in the protocol.  Also acceptable (the data source can
> take that into consideration when creating the message stream).
> And, the incremental latency can be made pretty small.
>
> Another downside is the cost of updating data on *all* (multiple)
> devices as this requires N messages.
>
> An alternate message format (or, a cleverer encoding of the above)
> could be used to allow a single COMPOSITE message to be propagated
> in which a node encountering a '0' address field strips the data
> that is intended for its use and then reconstructs a message
> bearing a '0' address field with the BALANCE of the data that it
> then passes to the next device, in series.  In effect, letting
> each subsequent device strip off "its" data before passing the
> remainder along.
>
> [When no data remains, the message dissipates]
>
> As such, you could "address" any set of contiguous addresses
> by creating an initial message of the form:
>     <first_target_ID> <first_datum> ... <last_datum>
> where the number of data present in the message implicitly defines
> the *last_target_id* relative to the first_target_id.
>
> Any problems with this sort of kludged encapsulation?

Why daisy-chain? If all devices have to be listening anyhow,
why not send the same data to all in parallel, and get each
one to validate the checksum and determine if the message
is intended for them. That way you can use broadcast (groups),
and one software failure doesn't take down the chain.

Otherwise you start getting into USB-style distribution trees
with all the complexity of enumeration, routing, etc. Avoid
that if you can, would be my advice.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#26489

In article <590acce3$0$58351$b1db1813$19ace300@news.astraweb.com>,
 Clifford Heath <no.spam@please.net> wrote:

> On 04/05/17 16:14, Don Y wrote:
> > I want to push a bit stream through a series of *identical* devices
> > and have (identical) software running on each determine if that
> > particular device is being addressed, or not.
> >
> 
> Why daisy-chain? If all devices have to be listening anyhow,
> why not send the same data to all in parallel, and get each
> one to validate the checksum and determine if the message
> is intended for them. That way you can use broadcast (groups),
> and one software failure doesn't take down the chain.
> 
> Otherwise you start getting into USB-style distribution trees
> with all the complexity of enumeration, routing, etc. Avoid
> that if you can, would be my advice.
> 

If each device is identical, and running identical software, how do you 
get the devices to not all think the message is for them?

How about a hybrid approach where the data stream is connected in 
parallel, but the enable is daisy chained. On initialization, only the 
first device would see the enable, and it would receive and acknowledge 
a message setting its address, then it would set the enable for the next 
device in the chain, and the initialization continues until each has 
received a unique address. This would also solve the synchronization 
issue since one address could be reserved as an 'all listen' address 
that could be used to initiate an action.

[toc] | [prev] | [next] | [standalone]

#26491

On 5/4/2017 1:26 PM, Mark Storkamp wrote:
> In article <590acce3$0$58351$b1db1813$19ace300@news.astraweb.com>,
>  Clifford Heath <no.spam@please.net> wrote:
>
>> On 04/05/17 16:14, Don Y wrote:
>>> I want to push a bit stream through a series of *identical* devices
>>> and have (identical) software running on each determine if that
>>> particular device is being addressed, or not.
>>>
>>
>> Why daisy-chain? If all devices have to be listening anyhow,
>> why not send the same data to all in parallel, and get each
>> one to validate the checksum and determine if the message
>> is intended for them. That way you can use broadcast (groups),
>> and one software failure doesn't take down the chain.
>>
>> Otherwise you start getting into USB-style distribution trees
>> with all the complexity of enumeration, routing, etc. Avoid
>> that if you can, would be my advice.
>>
>
> If each device is identical, and running identical software, how do you
> get the devices to not all think the message is for them?

The message is received by a node and the address is decremented before 
being passed on to the next.  Only when the message address reaches zero 
does the node accept it as being for it.


> How about a hybrid approach where the data stream is connected in
> parallel, but the enable is daisy chained. On initialization, only the
> first device would see the enable, and it would receive and acknowledge
> a message setting its address, then it would set the enable for the next
> device in the chain, and the initialization continues until each has
> received a unique address. This would also solve the synchronization
> issue since one address could be reserved as an 'all listen' address
> that could be used to initiate an action.

Sounds good to me, but I bet there is an issue that hasn't been 
described yet.  When a new node is added to the system the nodes would 
need to be re-synchronized.

This makes me wonder what the purpose of such a network would be.  It 
would be very hard to manage a chain of any length and distance so that 
you knew which node was which.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26482

Il giorno giovedì 4 maggio 2017 08:13:50 UTC+2, Don Y ha scritto:
> I want to push a bit stream through a series of *identical* devices
> and have (identical) software running on each determine if that
> particular device is being addressed, or not.
> 
> It seems like the simplest way to do so is to require each device
> to examine an address field in the packet and, if '0', assume the
> data that follows is intended for its consumption.  If not,
> decrement the address and pass the packet along.

> Another downside is the cost of updating data on *all* (multiple)
> devices as this requires N messages.

You can think of a special broadcast address that is not decremented but the device simply accept the message and ppass it over to the next.

But if you put a checksum on the message, you need to recalculate the checksum every time the address is decremented (or you don't put the address in the checksum...)

Bye Jack

[toc] | [prev] | [next] | [standalone]

#26483

On 5/4/2017 12:28 AM, Jack wrote:
> Il giorno giovedì 4 maggio 2017 08:13:50 UTC+2, Don Y ha scritto:
>> I want to push a bit stream through a series of *identical* devices and
>> have (identical) software running on each determine if that particular
>> device is being addressed, or not.
>>
>> It seems like the simplest way to do so is to require each device to
>> examine an address field in the packet and, if '0', assume the data that
>> follows is intended for its consumption.  If not, decrement the address
>> and pass the packet along.
>
>> Another downside is the cost of updating data on *all* (multiple) devices
>> as this requires N messages.
>
> You can think of a special broadcast address that is not decremented but the
> device simply accept the message and ppass it over to the next.

Yes, that's a good idea.

My comment, above, was intended to deal with the case of sending
DIFFERENT data to ALL devices vs. sending the SAME data to all
of them.

E.g., if I wanted to set the devices per the following table:

ID    Value
3      CC
4      D
5      EEEE
6      FFF

I could send the message (ignore the obvious error, here):

3CCDEEEEFFF

device 3 to peel off the "CC" and pass "0DEEEEFFF" along which would cause
device 4 to peel off the "D" and pass "0EEEEFFF" along which would cause
device 5 to peel off the "EEEE" and pass "0FFF" along which would cause
device 6 to peel off the "FFF", dissipating the message (i.e., devices
7 and higher would see no traffic)

By contrast, your suggestion would allow for a

*XYZ

message to be propagated, as is, to all subsequent devices (assume '*' is
the "special broadcast address").  This would be useful in some cases.

> But if you put a checksum on the message, you need to recalculate the
> checksum every time the address is decremented (or you don't put the address
> in the checksum...)

Yes.  And, each device would have to delay acting on the data until
the balance of the message had been received -- even though it could
begin propagating the data that follows its payload as soon as it
has been received.

Putting the checksum at the head of the message would require each
device to buffer the ENTIRE message -- placing a limit on the length
of the chain -- as it wouldn't be able to tweek the checksum until
after it sees the entire message.

[There's some hand-waving here; you could also adopt a message format
that lets a "trailer byte" be modified to bias the checksum as needed
AFTER the message has been passed through with the original, unmodified
checksum]

[toc] | [prev] | [next] | [standalone]

#26487

On 5/4/2017 3:48 AM, Don Y wrote:
> On 5/4/2017 12:28 AM, Jack wrote:
>> Il giorno giovedì 4 maggio 2017 08:13:50 UTC+2, Don Y ha scritto:
>>> I want to push a bit stream through a series of *identical* devices and
>>> have (identical) software running on each determine if that particular
>>> device is being addressed, or not.
>>>
>>> It seems like the simplest way to do so is to require each device to
>>> examine an address field in the packet and, if '0', assume the data that
>>> follows is intended for its consumption.  If not, decrement the address
>>> and pass the packet along.
>>
>>> Another downside is the cost of updating data on *all* (multiple)
>>> devices
>>> as this requires N messages.
>>
>> You can think of a special broadcast address that is not decremented
>> but the
>> device simply accept the message and ppass it over to the next.
>
> Yes, that's a good idea.
>
> My comment, above, was intended to deal with the case of sending
> DIFFERENT data to ALL devices vs. sending the SAME data to all
> of them.
>
> E.g., if I wanted to set the devices per the following table:
>
> ID    Value
> 3      CC
> 4      D
> 5      EEEE
> 6      FFF
>
> I could send the message (ignore the obvious error, here):
>
> 3CCDEEEEFFF
>
> device 3 to peel off the "CC" and pass "0DEEEEFFF" along which would cause
> device 4 to peel off the "D" and pass "0EEEEFFF" along which would cause
> device 5 to peel off the "EEEE" and pass "0FFF" along which would cause
> device 6 to peel off the "FFF", dissipating the message (i.e., devices
> 7 and higher would see no traffic)

What is the value of this vs. sending four messages?  You could send the 
message to 7 first.  Once that message has cleared the first unit send a 
message to 6, then 5, 4 and finally the message goes out to 3.  When 
message 3 is received by device 3 the message for 7 is being received by 
7.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26485

AT Thursday 04 May 2017 14:14, Don Y wrote:

> I want to push a bit stream through a series of *identical* devices
> and have (identical) software running on each determine if that
> particular device is being addressed, or not.
> 
> It seems like the simplest way to do so is to require each device
> to examine an address field in the packet and, if '0', assume the
> data that follows is intended for its consumption.  If not,
> decrement the address and pass the packet along.
> 
> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
> signals)
> 
> Of course, this means a failure of any device renders those that
> follow it inaccessible.  That's acceptable.
> 
> It also means there is a latency proportional to the device address
> inherent in the protocol.  Also acceptable (the data source can
> take that into consideration when creating the message stream).
> And, the incremental latency can be made pretty small.
> 
> Another downside is the cost of updating data on *all* (multiple)
> devices as this requires N messages.
> 
> An alternate message format (or, a cleverer encoding of the above)
> could be used to allow a single COMPOSITE message to be propagated
> in which a node encountering a '0' address field strips the data
> that is intended for its use and then reconstructs a message
> bearing a '0' address field with the BALANCE of the data that it
> then passes to the next device, in series.  In effect, letting
> each subsequent device strip off "its" data before passing the
> remainder along.
> 
> [When no data remains, the message dissipates]
> 
> As such, you could "address" any set of contiguous addresses
> by creating an initial message of the form:
>      <first_target_ID> <first_datum> ... <last_datum>
> where the number of data present in the message implicitly defines
> the *last_target_id* relative to the first_target_id.
> 
> Any problems with this sort of kludged encapsulation?

Your second format reminds me of the Interbus. This is also a daisy-chained 
fieldbus. A packet contains data for all at fixed positions. Each client can 
take its part (as its input) and replace it with its output. The whole 
packet is protected be a crc that each client recalculates when it changes 
the message.
This means of course that the size of inputs and output for each client must 
be equal. If a client has more out than in, the message from the master must 
be padded with dummies.
During a config phase the master determines how long each clients part is 
and the client discover where in the message their part is.

I once implemented something similar using simple uarts using RS422. Each 
client re-transmits the (modified) message. The output goes to the next 
client. At the end the loop is closed by connecting to a common rail back to 
the master.
I even had some way two RS422 drivers. One always on for connecting to the  
next client, another that is connected to the common back rail and is only 
switched on by the client if it is the last in the ring. This was determined 
during initial config by the master and the last client setup accordingly.
This even allowed to keep the ring working when one client failed. The ring 
was just closed before it. Of course every client after this point was cut 
off.

This automatic ring closure is also part of the Interbus and I had taken the 
idea from there.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#26486

On 5/4/2017 1:44 AM, Reinhardt Behm wrote:
> AT Thursday 04 May 2017 14:14, Don Y wrote:
>
>> I want to push a bit stream through a series of *identical* devices
>> and have (identical) software running on each determine if that
>> particular device is being addressed, or not.
>>
>> It seems like the simplest way to do so is to require each device
>> to examine an address field in the packet and, if '0', assume the
>> data that follows is intended for its consumption.  If not,
>> decrement the address and pass the packet along.
>>
>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
>> signals)
>>
>> Of course, this means a failure of any device renders those that
>> follow it inaccessible.  That's acceptable.
>>
>> It also means there is a latency proportional to the device address
>> inherent in the protocol.  Also acceptable (the data source can
>> take that into consideration when creating the message stream).
>> And, the incremental latency can be made pretty small.
>>
>> Another downside is the cost of updating data on *all* (multiple)
>> devices as this requires N messages.
>>
>> An alternate message format (or, a cleverer encoding of the above)
>> could be used to allow a single COMPOSITE message to be propagated
>> in which a node encountering a '0' address field strips the data
>> that is intended for its use and then reconstructs a message
>> bearing a '0' address field with the BALANCE of the data that it
>> then passes to the next device, in series.  In effect, letting
>> each subsequent device strip off "its" data before passing the
>> remainder along.
>>
>> [When no data remains, the message dissipates]
>>
>> As such, you could "address" any set of contiguous addresses
>> by creating an initial message of the form:
>>      <first_target_ID> <first_datum> ... <last_datum>
>> where the number of data present in the message implicitly defines
>> the *last_target_id* relative to the first_target_id.
>>
>> Any problems with this sort of kludged encapsulation?
>
> Your second format reminds me of the Interbus. This is also a daisy-chained
> fieldbus. A packet contains data for all at fixed positions. Each client can
> take its part (as its input) and replace it with its output. The whole
> packet is protected be a crc that each client recalculates when it changes
> the message.
> This means of course that the size of inputs and output for each client must
> be equal. If a client has more out than in, the message from the master must
> be padded with dummies.

Actually, that's not a requirement in my scheme.

Consider a few approaches:

    <packet>	::= <ID> <messages> <CRC>
    ...
    <message>	::= <length> <content>

Here, each message can be opaque -- yet its size IN THE PACKET can easily
be determines by the <length> field introducing it.  The number of messages
can be deduced by parsing the <length> header of each successive <message>
until you encounter one with a special <length> value (e.g., '0').  This
then implies the location of the <CRC> to follow -- and the start f the
NEXT packet.

[Of course, it *requires* each device addressed in that packet to be
targeteed for *some* sort of command -- even if that it a NOP (so
its <length> field is != 0)]

Another approach:

    <message>	::= <stop> | <start> | <speed> | <position>
    <stop>	::= STOP
    <start>	::= START
    <speed>	::= SPEED <percent>
    <position>	::= GOTO <X> <Y>

(these might be manifest constants or literal ASCII character sequences)

The "length" of each <message> is implicit in the message's identity.

My requirement that the same/identical software run on all devices means
EVERY device can understand ALL messages.  A device doesn't have to
know what TYPE of device it is or where in the chain it is located.
The device upstream looks like its master and those downstream look
like its peers.

> During a config phase the master determines how long each clients part is
> and the client discover where in the message their part is.

Yes, a valid alternative.  But, only if you want to support different
TYPES of clients (devices).

> I once implemented something similar using simple uarts using RS422. Each
> client re-transmits the (modified) message. The output goes to the next
> client. At the end the loop is closed by connecting to a common rail back to
> the master.

Actually, that might make some sense.  I'd only pursued a unidirectional
(output only) scheme. But, you could modify this to allow devices to append
data that they want to return to the "master" -- by exploiting each subsequent
device's mandate to propagate EVERYTHING that comes into it after eliding
its particular payload (and injecting its reply).

> I even had some way two RS422 drivers. One always on for connecting to the
> next client, another that is connected to the common back rail and is only
> switched on by the client if it is the last in the ring. This was determined
> during initial config by the master and the last client setup accordingly.
> This even allowed to keep the ring working when one client failed. The ring
> was just closed before it. Of course every client after this point was cut
> off.

I don't think I need to include recovery mechanisms.  If some portion
of the "network" (field) can become inaccessible, then its likely that
things need to be repaired.  Otherwise, where a device sat in the chain
would determine its relative importance -- you'd be inclined to spend
effort reconfiguring the chain whenever its device content changed
and you'd probably never be *assured* that you could find an
optimal/satisfying configuration.

[I'm looking for a cheap/simple solution, not necessarily an efficient one!]

OTOH, closing the ring at least provides *some* diagnostic information
to the master.  If it fails to see some indication that its most recent packet
had propagated through all devices, it could throw an error.  Without that
loop closing, it would have to assume all was well!

> This automatic ring closure is also part of the Interbus and I had taken the
> idea from there.

[toc] | [prev] | [next] | [standalone]

#26488

On Wed, 03 May 2017 23:14:09 -0700, Don Y wrote:

> I want to push a bit stream through a series of *identical* devices and
> have (identical) software running on each determine if that particular
> device is being addressed, or not.
> 
> It seems like the simplest way to do so is to require each device to
> examine an address field in the packet and, if '0', assume the data that
> follows is intended for its consumption.  If not, decrement the address
> and pass the packet along.
> 
> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT signals)
> 
> Of course, this means a failure of any device renders those that follow
> it inaccessible.  That's acceptable.
> 
> It also means there is a latency proportional to the device address
> inherent in the protocol.  Also acceptable (the data source can take
> that into consideration when creating the message stream). And, the
> incremental latency can be made pretty small.
> 
> Another downside is the cost of updating data on *all* (multiple)
> devices as this requires N messages.
> 
> An alternate message format (or, a cleverer encoding of the above) could
> be used to allow a single COMPOSITE message to be propagated in which a
> node encountering a '0' address field strips the data that is intended
> for its use and then reconstructs a message bearing a '0' address field
> with the BALANCE of the data that it then passes to the next device, in
> series.  In effect, letting each subsequent device strip off "its" data
> before passing the remainder along.
> 
> [When no data remains, the message dissipates]
> 
> As such, you could "address" any set of contiguous addresses by creating
> an initial message of the form:
>      <first_target_ID> <first_datum> ... <last_datum>
> where the number of data present in the message implicitly defines the
> *last_target_id* relative to the first_target_id.
> 
> Any problems with this sort of kludged encapsulation?

I've done this, it worked -- the customer went through some personnel 
changes and the project died before it could get shipped, but cest la vie.

I wouldn't overthink things vis-a-vis the composite message -- just send 
lots of little messages and be happy.  Complexity leads to bugs.

Use all ones in the address field as a 'broadcast' address.

Or do the address decrementing by shifting down one bit, and consider the 
message "yours" if the least significant bit is zero.  That only allows 
eight devices, but if you foresee a lot of traffic with identical 
messages for selected sets of devices, this would move you on down the 
road.

-- 
www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#26490

On 5/4/2017 7:54 AM, Tim Wescott wrote:
>> Any problems with this sort of kludged encapsulation?
>
> I've done this, it worked -- the customer went through some personnel
> changes and the project died before it could get shipped, but cest la vie.

I used the first format with cheap single-chip MCU's many years
ago -- using a LONG SPACE to signal the start of the packet (to
"resynchronize" any drifted clock; a VERY LONG BREAK would
cause a one-shot in the device to trigger and hardware reset the
device)

But, the data rates were very low and the line interfaces
had plenty of noise margin (EIA232).

I'd like to come up with a scheme that I could apply to a variety of
similarly "open ended" network configurations -- that have very
different physical characteristics (e.g., a 10 ft long chain
and a 300 ft long chain -- trading data rate for network size)

> I wouldn't overthink things vis-a-vis the composite message -- just send
> lots of little messages and be happy.  Complexity leads to bugs.

The problem with lots of messages comes from having to update many
devices (nodes?) continuously.  You incur the message overhead
for every individual message.  With the "composite" format,
the master can just push an endless stream of data out and each
node picks off what's important.

> Use all ones in the address field as a 'broadcast' address.
>
> Or do the address decrementing by shifting down one bit, and consider the
> message "yours" if the least significant bit is zero.  That only allows
> eight devices, but if you foresee a lot of traffic with identical
> messages for selected sets of devices, this would move you on down the
> road.

I have to look at the different applications that I have in mind to see
whether I want a "bit oriented" protocol or a byte-oriented.  I.e.,
I don't want to get coerced (subconsciously) into letting a UART make
me think in terms of "characters" when something more like a self-clocking
JTAG might make more sense.

The big downside that I see is handling transmission "problems".
E.g., if node X detects a CRC error, it has no way of knowing
if it's data is intact *or* if the error is part of the data
that it will be propagating.  If it *corrects* the CRC that
it passes along (to coincide with that data content), then it
has "blessed" that data (by hiding the CRC error from those
downstream from it!).

This suggests the node has EFFECTIVELY decided the error was
in its portion of the data packet (if so, it definitely
shouldn't be USING that data!)

Repeat for cases where one or more nodes loses clock
recovery or message synchronization (thus, *misinterprets*
the serialized data stream)

[Reinhardt's suggestion of "closing the loop" bears some merit!
But, it alone doesn't ensure that everything handled the
packet correctly]

[toc] | [prev] | [next] | [standalone]

#26492

On Thu, 4 May 2017 10:52:40 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>I'd like to come up with a scheme that I could apply to a variety of
>similarly "open ended" network configurations -- that have very
>different physical characteristics (e.g., a 10 ft long chain
>and a 300 ft long chain -- trading data rate for network size)


At some point you need to worry about reinventing Ethernet.  And many
MCU's are available with Ethernet for a very small incremental cost.
Although perhaps not at the very low end.  A huge advantage is that
you can punt much of the infrastructure to the customer ("It's
Ethernet, deal with it.").

[toc] | [prev] | [next] | [standalone]

#26493

On 5/4/2017 12:53 PM, Robert Wessel wrote:
> On Thu, 4 May 2017 10:52:40 -0700, Don Y <blockedofcourse@foo.invalid>
> wrote:
>
>> I'd like to come up with a scheme that I could apply to a variety of
>> similarly "open ended" network configurations -- that have very
>> different physical characteristics (e.g., a 10 ft long chain
>> and a 300 ft long chain -- trading data rate for network size)
>
> At some point you need to worry about reinventing Ethernet.  And many
> MCU's are available with Ethernet for a very small incremental cost.
> Although perhaps not at the very low end.  A huge advantage is that
> you can punt much of the infrastructure to the customer ("It's
> Ethernet, deal with it.").

Depends on the nature of the "messages" being passed -- their
content and frequency.

E.g., would you spring for the cost of a NIC, MCU capable
of supporting a TCP (or even just UDP) "stack" -- just to
command individual hammer drivers on/off at some sub-sonic rate?

OTOH, running a bunch of wires from *one* set of hammer drivers
(accessed "in parallel" from an MCU port) out to a bunch of
solenoids dramatically changes how you wire them, how you
deal with expansion, etc.

With Ethernet, you'd have to ensure each node had a unique address
so you could distribute the message to all and know that the
right node acted on it -- AND, that no OTHER node acted on it!

By interposing each node in a serial chain, a node need not
care about it's "address" -- it's *implied* (when the ID byte
is 0, the message is for you.  Otherwise, its for someone
DOWNSTREAM from you).  So, you can produce identical devices
and still treat them as individually unique.

Of course, this makes binding addresses to physical nodes
a separate issue:  you either carefully document the
physical (electrical?) order of the nodes at deployment
*or* introduce a "configuration step" in which you
empirically derive the (address,node) mapping.

     "I just activated node 1.  What do you see as having
     changed in the field?  OK, I'll write that down.  Now
     proceeding to node 2..."

This would be tedious *if* the field configuration changed,
often.  But, if it is largely static and only updated as
needs evolve (or, in response to failures), then its almost
assumed that some degree of manual intervention will be
required (i.e., someone has to swap out the defective node
or splice a new node into the chain <somewhere> -- which
may not be at the *end*)

[toc] | [prev] | [next] | [standalone]

#26497

On Thu, 4 May 2017 13:17:18 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 5/4/2017 12:53 PM, Robert Wessel wrote:
>> On Thu, 4 May 2017 10:52:40 -0700, Don Y <blockedofcourse@foo.invalid>
>> wrote:
>>
>>> I'd like to come up with a scheme that I could apply to a variety of
>>> similarly "open ended" network configurations -- that have very
>>> different physical characteristics (e.g., a 10 ft long chain
>>> and a 300 ft long chain -- trading data rate for network size)
>>
>> At some point you need to worry about reinventing Ethernet.  And many
>> MCU's are available with Ethernet for a very small incremental cost.
>> Although perhaps not at the very low end.  A huge advantage is that
>> you can punt much of the infrastructure to the customer ("It's
>> Ethernet, deal with it.").
>
>Depends on the nature of the "messages" being passed -- their
>content and frequency.
>
>E.g., would you spring for the cost of a NIC, MCU capable
>of supporting a TCP (or even just UDP) "stack" -- just to
>command individual hammer drivers on/off at some sub-sonic rate?


I'm not sure I can answer that definitively, even for myself, but as a
first order approximation, if it's a separate box, the first choice of
interconnect should be Ethernet or one of its wireless cousins (WiFi,
Bluetooth), if a wireless connection is required.  And UDP+IP does not
impose much of a burden, even on a OS-less MCU.

Which is not to say that there aren't going to be exceptions.  But I'm
pretty sure things are at the point where you need to justify *not*
using Ethernet on an external connection.


>OTOH, running a bunch of wires from *one* set of hammer drivers
>(accessed "in parallel" from an MCU port) out to a bunch of
>solenoids dramatically changes how you wire them, how you
>deal with expansion, etc.


Direct drive stuff is one obvious exception.  But you're asking about
devices you're sending packets to.


>With Ethernet, you'd have to ensure each node had a unique address
>so you could distribute the message to all and know that the
>right node acted on it -- AND, that no OTHER node acted on it!


Any device claiming to be Ethernet should have the process for
attaching a unique MAC address well established.  Use the MAC number
as the device serial number (pre-pend some of your own digits for
sanity, on the sticker you attach to the outside of the device).


>By interposing each node in a serial chain, a node need not
>care about it's "address" -- it's *implied* (when the ID byte
>is 0, the message is for you.  Otherwise, its for someone
>DOWNSTREAM from you).  So, you can produce identical devices
>and still treat them as individually unique.
>
>Of course, this makes binding addresses to physical nodes
>a separate issue:  you either carefully document the
>physical (electrical?) order of the nodes at deployment
>*or* introduce a "configuration step" in which you
>empirically derive the (address,node) mapping.
>
>     "I just activated node 1.  What do you see as having
>     changed in the field?  OK, I'll write that down.  Now
>     proceeding to node 2..."
>
>This would be tedious *if* the field configuration changed,
>often.  But, if it is largely static and only updated as
>needs evolve (or, in response to failures), then its almost
>assumed that some degree of manual intervention will be
>required (i.e., someone has to swap out the defective node
>or splice a new node into the chain <somewhere> -- which
>may not be at the *end*)


The implied address approach doesn't really fix the problem.  Sure
someone attached *something* to port 7 of controller 13, but did they
do that correctly?  IOW, is that water valve on 13/7 actually attached
to the cold supply to the motor cooling system, or did someone attach
it to the hot water line to the reactor heater?  Or is what they
plugged into 13/7 actually attach the electrical power switch for the
ammonia pump motor?  Or heck, maybe it *is* an actual accelerometer,
of the type you wanted, but did they plug the X axis one into 13/7
like the should have, or did they get the Y or Z axis one?

There are also diagnostic advantages to being able see the entire
network from one place.  It also offers some opportunities for
redundancy (controller 13 appears to be unresponsive, have the
monitoring system send a predefined safeing command to all the devices
13 was supposed to be controlling).  If you need higher levels of
redundancy, having two Ethernet ports on devices is also easy, and
having two parallel sets of Ethernet switches, with a few
interconnects, leaves you with two links to any device.

Certainly the setup and verification procedures will be *different*. I
see modest-to-large advantages in a fair number of situations for the
Ethernet approach, and small-to-modest advantages for the custom
approach in (fewer others), and a majority where it's a wash.

[toc] | [prev] | [next] | [standalone]

#26498

On 5/4/2017 10:30 PM, Robert Wessel wrote:
> On Thu, 4 May 2017 13:17:18 -0700, Don Y <blockedofcourse@foo.invalid>
> wrote:
>
>> On 5/4/2017 12:53 PM, Robert Wessel wrote:
>>> On Thu, 4 May 2017 10:52:40 -0700, Don Y <blockedofcourse@foo.invalid>
>>> wrote:
>>>
>>>> I'd like to come up with a scheme that I could apply to a variety of
>>>> similarly "open ended" network configurations -- that have very
>>>> different physical characteristics (e.g., a 10 ft long chain
>>>> and a 300 ft long chain -- trading data rate for network size)
>>>
>>> At some point you need to worry about reinventing Ethernet.  And many
>>> MCU's are available with Ethernet for a very small incremental cost.
>>> Although perhaps not at the very low end.  A huge advantage is that
>>> you can punt much of the infrastructure to the customer ("It's
>>> Ethernet, deal with it.").
>>
>> Depends on the nature of the "messages" being passed -- their
>> content and frequency.
>>
>> E.g., would you spring for the cost of a NIC, MCU capable
>> of supporting a TCP (or even just UDP) "stack" -- just to
>> command individual hammer drivers on/off at some sub-sonic rate?
>
> I'm not sure I can answer that definitively, even for myself, but as a
> first order approximation, if it's a separate box, the first choice of
> interconnect should be Ethernet or one of its wireless cousins (WiFi,
> Bluetooth), if a wireless connection is required.  And UDP+IP does not
> impose much of a burden, even on a OS-less MCU.

Why the "separate box" criteria?  Should car manufacturers replace
CAN with Ethernet?  Should PC manufacturers use ethernet to connect
their floppy disk drive to the CPU (on the other end of the
motherboard)?  See my pinball machine example, elsewhere, this thread.
Should the pushbutton controls for my garage door opener use ethernet
frames to pass "open" and "close" commands to the actuator head?
Or, individual keystrokes from the external keypad to the controller
in the actuator?

> Which is not to say that there aren't going to be exceptions.  But I'm
> pretty sure things are at the point where you need to justify *not*
> using Ethernet on an external connection.

Should my doorbell use an ethernet connection?  My thermostat to
talk to the furnace?

As I said, it depends on the nature of the data ("messages") being
exchanged and their frequency.  My CCTV cameras are IP based -- because
they move a fair bit of data, continuously, and I need (choose) a bit of
processing power AT the camera.  It's easier to run CAT5 with a PoE
injector than to run a separate power connection and coaxial video
cable back to <something>.  Esp if I want to be able to add more
cameras without having to upgrade an N-port "camera card" in a PC...
(N = 4 or 8)

>> OTOH, running a bunch of wires from *one* set of hammer drivers
>> (accessed "in parallel" from an MCU port) out to a bunch of
>> solenoids dramatically changes how you wire them, how you
>> deal with expansion, etc.
>
> Direct drive stuff is one obvious exception.  But you're asking about
> devices you're sending packets to.

Why can't I send packets to solenoids?  Again, see the pinball example.

One wall of the house is glass.  Blinds on each window.  Do I run
ethernet to each window?  Or, do I install a "blind controller"
<somewhere> and pass messages over a low speed serial interface
to tiny motes mounted on the motors for each of the individual
blinds:
     3OPEN
causes the 4th motor "from here" -- "external" to "here" -- to open
while:
     2CLOSE
causes the 3rd motor to close.

>> With Ethernet, you'd have to ensure each node had a unique address
>> so you could distribute the message to all and know that the
>> right node acted on it -- AND, that no OTHER node acted on it!
>
> Any device claiming to be Ethernet should have the process for
> attaching a unique MAC address well established.  Use the MAC number
> as the device serial number (pre-pend some of your own digits for
> sanity, on the sticker you attach to the outside of the device).

But, then they aren't IDENTICAL devices!

I can rephrase my problem and claim I'm using MCU's with serial
numbers laser etched into their silicon from the factory.  Now,
I have a means of uniquely identifying each device -- even if I
talk to them using CAN or any other transport layer.  No need
to rely on wiring "position" to identify a device!

Remove the MAC address and solve the problem with ethernet.
I.e., you have to ADD the MAC address back in -- or, some other
"unique identifier".

Apples-apples.

>> By interposing each node in a serial chain, a node need not
>> care about it's "address" -- it's *implied* (when the ID byte
>> is 0, the message is for you.  Otherwise, its for someone
>> DOWNSTREAM from you).  So, you can produce identical devices
>> and still treat them as individually unique.
>>
>> Of course, this makes binding addresses to physical nodes
>> a separate issue:  you either carefully document the
>> physical (electrical?) order of the nodes at deployment
>> *or* introduce a "configuration step" in which you
>> empirically derive the (address,node) mapping.
>>
>>     "I just activated node 1.  What do you see as having
>>     changed in the field?  OK, I'll write that down.  Now
>>     proceeding to node 2..."
>>
>> This would be tedious *if* the field configuration changed,
>> often.  But, if it is largely static and only updated as
>> needs evolve (or, in response to failures), then its almost
>> assumed that some degree of manual intervention will be
>> required (i.e., someone has to swap out the defective node
>> or splice a new node into the chain <somewhere> -- which
>> may not be at the *end*)
>
> The implied address approach doesn't really fix the problem.  Sure
> someone attached *something* to port 7 of controller 13, but did they
> do that correctly?

Sure, someone bought a box of 50 model 123 Ethernet valve controllers.
And, I can now "see" the controller that they just cabled to my system.
Did they attach the correct device?  Did they wire it to the correct
valve?  Or, is it wired to a light bulb, instead?

Using a different transport protocol doesn't tell you anything
about the outside world.

> IOW, is that water valve on 13/7 actually attached
> to the cold supply to the motor cooling system, or did someone attach
> it to the hot water line to the reactor heater?

Is the water valve on 12:34:56:78:9A:BC port 7 actually attached
to the cold supply to the motor cooling system, or did someone attach
it to the hot water line to the reactor heater?

Or, to the hand towel dispenser in the men's room?

> Or is what they
> plugged into 13/7 actually attach the electrical power switch for the
> ammonia pump motor?  Or heck, maybe it *is* an actual accelerometer,
> of the type you wanted, but did they plug the X axis one into 13/7
> like the should have, or did they get the Y or Z axis one?

How is any of this made BETTER or mode robust/reliable by using Ethernet?

> There are also diagnostic advantages to being able see the entire
> network from one place.

Why can't I see the daisy-chained devices?

> It also offers some opportunities for
> redundancy (controller 13 appears to be unresponsive, have the
> monitoring system send a predefined safeing command to all the devices
> 13 was supposed to be controlling).

How do you *talk* to those devices if the controller that handles them
is unresponsive?  Why does ethernet to an unresponsive controller
give you that ability but daisy-chain to an unresponsive controller
doesn't?

That's a separate design issue.  And, you have to decide how much you
want to invest in your solution to address those conditions.

If I sense a water leak in the house, I have no way of knowing
WHERE it is.  Perhaps a toilet is "running on".  Or, maybe a
hose to the washing machine has ruptured.  Or, someone left a
faucet partially open.  (all have happened, here)

In my case, I can shut off water TO THE HOUSE.  But, not to the
toilet, individually.  Or, the faucet.  So, the magnitude of the
leak weighs into how I attempt to protect the house.  If it's a slow
leak, chances are, its a toilet running on or a faucet that wasn't
turned off completely.  Send a message to the occupants -- even if
they are away on vacation.  If no response, maybe let the leak
continue (running up the water bill for this month) *or* shut off
the house supply -- until you *need* to turn it back on (e.g., to
water the yard).

If I wanted more options in handling this "failure", I'd spend
more resources on better isolating the source of the leak AND
limiting the damage that it could potentially cause.

If I want to be able to turn off ALL the solenoids because I
suspect one solenoid controller may be crashed with its
solenoid engaged (which could cause it to burn up), then I'd
add a disconnect in the power feed to the "solenoid bus".
Or, a special disconnect for just that one solenoid.

> If you need higher levels of
> redundancy, having two Ethernet ports on devices is also easy, and
> having two parallel sets of Ethernet switches, with a few
> interconnects, leaves you with two links to any device.

So, the lights on the pinball machine's playfield should have *two*
ethernet connections?  The irrigation valves should similarly have two?

> Certainly the setup and verification procedures will be *different*. I
> see modest-to-large advantages in a fair number of situations for the
> Ethernet approach, and small-to-modest advantages for the custom
> approach in (fewer others), and a majority where it's a wash.

I'd be interested in the modest-to-large advantages you see in
controlling individual irrigation valves.  Or, lights/actuators on
a pinball machine playfield.  Or, the lighted pushbuttons on a
large broadcast studio video mixer:
<https://www.shutterstock.com/video/clip-12972671-stock-footage-broadcast-tv-studio-production-vision-switcher-broadcast-video-mixer-pan-right.html>

(Do you really think there is one *giant* PCB hiding behind all of those
LPB's and a gazillion "output drivers" wired, in parallel, to service
all those lamps/buttons?  Or, do you think, perhaps, they are organized
in IDENTICAL subassemblies hiding behind the top cover and wired
together using some sort of message passing bus?  Do you think it is
Ethernet based?  Think about what the messages being passed around,
there, are likely to contain.)

[toc] | [prev] | [next] | [standalone]

#26508

On 5/4/2017 7:54 AM, Tim Wescott wrote:
> On Wed, 03 May 2017 23:14:09 -0700, Don Y wrote:
>
>> I want to push a bit stream through a series of *identical* devices and
>> have (identical) software running on each determine if that particular
>> device is being addressed, or not.
>>
>> It seems like the simplest way to do so is to require each device to
>> examine an address field in the packet and, if '0', assume the data that
>> follows is intended for its consumption.  If not, decrement the address
>> and pass the packet along.
>>
>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT signals)
>>
>> Of course, this means a failure of any device renders those that follow
>> it inaccessible.  That's acceptable.
>>
>> It also means there is a latency proportional to the device address
>> inherent in the protocol.  Also acceptable (the data source can take
>> that into consideration when creating the message stream). And, the
>> incremental latency can be made pretty small.
>>
>> Another downside is the cost of updating data on *all* (multiple)
>> devices as this requires N messages.
>>
>> An alternate message format (or, a cleverer encoding of the above) could
>> be used to allow a single COMPOSITE message to be propagated in which a
>> node encountering a '0' address field strips the data that is intended
>> for its use and then reconstructs a message bearing a '0' address field
>> with the BALANCE of the data that it then passes to the next device, in
>> series.  In effect, letting each subsequent device strip off "its" data
>> before passing the remainder along.
>>
>> [When no data remains, the message dissipates]
>>
>> As such, you could "address" any set of contiguous addresses by creating
>> an initial message of the form:
>>      <first_target_ID> <first_datum> ... <last_datum>
>> where the number of data present in the message implicitly defines the
>> *last_target_id* relative to the first_target_id.
>>
>> Any problems with this sort of kludged encapsulation?
>
> I've done this, it worked -- the customer went through some personnel
> changes and the project died before it could get shipped, but cest la vie.
>
> I wouldn't overthink things vis-a-vis the composite message -- just send
> lots of little messages and be happy.  Complexity leads to bugs.

I've run some simulations with different protocol proposals.
The "cascaded messages" scheme is a win when number of nodes is high,
individual messages short (e.g., "ON", "OFF", "LEFT", "RIGHT", etc.)
and update rate high (or, time between updates short -- e.g., to support
a short keep alive interval).

So far, I've only looked at bit-oriented protocols, not "character-oriented".
But, I think character oriented would probably make things worse for the
individual-message-per-node case.

E.g., in one case, I have ~190 nodes and ~5 different message types.
The most common messages are coded in two bits (00, 01) while the less
common messages are in three (100, 101, 110, 111/unused).  So, in the
"common case", I can refresh the entire set of nodes with a single
7[addr]+(190*2)[data]+9[CRC] bit packet ... 396b total.

If, instead, I deliver individual messages to each of the 190 nodes,
I spend 190[nodes]*(7[addr]+2[data]+4[CRC]) = 2470b -- a bit more than
6 times the bandwidth (assuming a "free" means of detecting individual
message extents in each case).

I.e., a 2400 "baud" (but bit-oriented) link would allow for one update
per second instead of 6.

> Use all ones in the address field as a 'broadcast' address.
>
> Or do the address decrementing by shifting down one bit, and consider the
> message "yours" if the least significant bit is zero.  That only allows
> eight devices, but if you foresee a lot of traffic with identical
> messages for selected sets of devices, this would move you on down the
> road.

It doesn't scale well to larger "networks".  I'm presently looking at alternate 
ways of encoding the "destination/skip-over" address as well
as the potential for using a tagged message format -- so the protocol
layer wouldn't need to know anything about the "content" of the message
set.  This would allow me to use exactly the same code in different
applications and just have an up-call from the protocol handler to the
message decoder -- letting the protocol handler know how/when/what to
propagate without having to consult with the decoder in making that
decision.  Otherwise, the protocol layer code would have to understand
the content of the message(s) to determine what portion to forward along.

[toc] | [prev] | [next] | [standalone]

#26494

Am 04.05.2017 um 08:14 schrieb Don Y:
> I want to push a bit stream through a series of *identical* devices
> and have (identical) software running on each determine if that
> particular device is being addressed, or not.
> 
> It seems like the simplest way to do so is to require each device
> to examine an address field in the packet and, if '0', assume the
> data that follows is intended for its consumption.  If not,
> decrement the address and pass the packet along.

Aha, so this week you're re-inventing cable position based addressing. :-)

Depending on the number of nodes, the likelihood of equal data being
sent to more than one node, and the length of said data,
encoding the target selection as a bit pattern that you shift, instead 
of a number that you decrease, might be more efficient.

It can be be even better to have two modes of operation for the whole
chain: either the network is learning its own layout, or it's working 
normally. Only the learning phase really needs the extra complication of 
e.g. an "take the first word of this message to use as their own address 
from now on, remove it from the packet, then transmit any remainder 
further down the daisy chain" mechanism.  Normal operation can then use 
a more straighforward addressing scheme.

[toc] | [prev] | [next] | [standalone]

#26495

Don Y wrote:
> I want to push a bit stream through a series of *identical* devices
> and have (identical) software running on each determine if that
> particular device is being addressed, or not.
>
> It seems like the simplest way to do so is to require each device
> to examine an address field in the packet and, if '0', assume the
> data that follows is intended for its consumption.  If not,
> decrement the address and pass the packet along.
>
> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
> signals)
>
> Of course, this means a failure of any device renders those that
> follow it inaccessible.  That's acceptable.
>
<snip>

It's way simpler to just have a 422/485 bus.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#26496

On 5/4/2017 4:47 PM, Les Cargill wrote:
> Don Y wrote:
>> I want to push a bit stream through a series of *identical* devices
>> and have (identical) software running on each determine if that
>> particular device is being addressed, or not.
>>
>> It seems like the simplest way to do so is to require each device
>> to examine an address field in the packet and, if '0', assume the
>> data that follows is intended for its consumption.  If not,
>> decrement the address and pass the packet along.
>>
>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
>> signals)
>>
>> Of course, this means a failure of any device renders those that
>> follow it inaccessible.  That's acceptable.
>
> <snip>
>
> It's way simpler to just have a 422/485 bus.

Then you have to have a way of making each device "unique".
This typically means a configuration activity that is probably
non-trivial.  And/or stocking different "part numbers" for
what are essentially the same component but with different
addresses, etc.

And, protocols to handle the case where two devices are
NOT unique (i.e., duplicate address).

Plus all the bus contention/arbitration possibilities, etc.
(if you want to get data *back* from the devices)

For example, with the cascaded scheme, you can wire all
of the lamps on the playfield of a pinball machine to power
and ground; then daisy chain a data line through a "smart
lamp driver" located adjacent to each individual lamp.

That *one* "lamp bus" signal would allow the processor to
turn any lamp on or off (dim, flash, whatever) regardless
of the number of lamps on the playfield.  The system
software would only need to know the lamp "order" of the
prototype as all future playfields (for that model) would
be wired in the same daisy-chain order.

When a lamp driver fails, it could be replaced with a
new component without any need for reconfiguration,
testing for duplicate bus addresses, etc.

The same power/ground could be distributed to all of the
"smart hammer drivers" sited adjacent to each of the
solenoids/actuators on the playfield.  That *one*
"hammer bus" signal would allow the processor to turn
any solenoid on or off (including supporting a pull-in
coil, maximum duration timer, shorted/open coil detector,
etc.) regardless of the number of drivers on the playfield.

[The lamp driver and hammer driver could be similar save for
current handling capacities and other "use related" issues
in their software; you probably don't care if a lamp
stays lit indefinitely -- but, a coil often has a duty cycle
limit!]

Likewise, you could have a "switch driver" that is distributed
around the playfield to sense contact closures arising from
the ball's motions.

You could do this with *other* busses -- including those that
require explicit addressing -- but with considerably more pain.

[toc] | [prev] | [next] | [standalone]

#26502

Don Y wrote:
> On 5/4/2017 4:47 PM, Les Cargill wrote:
>> Don Y wrote:
>>> I want to push a bit stream through a series of *identical* devices
>>> and have (identical) software running on each determine if that
>>> particular device is being addressed, or not.
>>>
>>> It seems like the simplest way to do so is to require each device
>>> to examine an address field in the packet and, if '0', assume the
>>> data that follows is intended for its consumption.  If not,
>>> decrement the address and pass the packet along.
>>>
>>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
>>> signals)
>>>
>>> Of course, this means a failure of any device renders those that
>>> follow it inaccessible.  That's acceptable.
>>
>> <snip>
>>
>> It's way simpler to just have a 422/485 bus.
>
> Then you have to have a way of making each device "unique".
> This typically means a configuration activity that is probably
> non-trivial.  And/or stocking different "part numbers" for
> what are essentially the same component but with different
> addresses, etc.
>

You have to have some way of managing this anyway.

in your example - do you somehow know that the third device in the
chain is always the "bluralizer"? I suppose that makes sense.

But these things are a truck roll anyhow, and 2.5 minutes sending a node 
address isn't that much more work.

I wrote a proposal once for a MODBUS system to automate addressing, but
it required a priori knowlege of order of devices on the bus, powering
them up in order  and nobody could guarantee that. Stuff was wound
every which way, so it was decided that explicit addressing was
preferred.

> And, protocols to handle the case where two devices are
> NOT unique (i.e., duplicate address).
>

In reality, that cannot be done for ostensibly "serial"
stuff. CAN is different[1]; but it's still a CM fail.

[1] I don't really recall what happens there.

> Plus all the bus contention/arbitration possibilities, etc.
> (if you want to get data *back* from the devices)
>
> For example, with the cascaded scheme, you can wire all
> of the lamps on the playfield of a pinball machine to power
> and ground; then daisy chain a data line through a "smart
> lamp driver" located adjacent to each individual lamp.
>
> That *one* "lamp bus" signal would allow the processor to
> turn any lamp on or off (dim, flash, whatever) regardless
> of the number of lamps on the playfield.  The system
> software would only need to know the lamp "order" of the
> prototype as all future playfields (for that model) would
> be wired in the same daisy-chain order.
>
> When a lamp driver fails, it could be replaced with a
> new component without any need for reconfiguration,
> testing for duplicate bus addresses, etc.
>

That's true. That's a sort of "degenerate" case where your
proposal makes sense.

It still smacks of "look! If we're real clever, we can
eliminate a whole wire!" which makes me eye-roll :)

> The same power/ground could be distributed to all of the
> "smart hammer drivers" sited adjacent to each of the
> solenoids/actuators on the playfield.  That *one*
> "hammer bus" signal would allow the processor to turn
> any solenoid on or off (including supporting a pull-in
> coil, maximum duration timer, shorted/open coil detector,
> etc.) regardless of the number of drivers on the playfield.
>
> [The lamp driver and hammer driver could be similar save for
> current handling capacities and other "use related" issues
> in their software; you probably don't care if a lamp
> stays lit indefinitely -- but, a coil often has a duty cycle
> limit!]
>
> Likewise, you could have a "switch driver" that is distributed
> around the playfield to sense contact closures arising from
> the ball's motions.
>
> You could do this with *other* busses -- including those that
> require explicit addressing -- but with considerably more pain.

Right.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web