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

Groups > comp.arch.embedded > #26508

Re: Serial protocol with physical decoding

Show all headers | View raw

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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web