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

Groups > comp.arch.embedded > #26496

Re: Serial protocol with physical decoding

Show all headers | View raw

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.

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