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

Groups > comp.arch.embedded > #26490

Re: Serial protocol with physical decoding

Show all headers | View raw

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]

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