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

Groups > comp.arch.embedded > #26485

Re: Serial protocol with physical decoding

Show all headers | View raw

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

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