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

Groups > comp.arch.embedded > #26486

Re: Serial protocol with physical decoding

Show all headers | View raw

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.

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