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

Groups > comp.arch.embedded > #26502

Re: Serial protocol with physical decoding

Show all headers | View raw

Don Y wrote:
> 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.
>

You have to have some way of managing this anyway.

in your example - do you somehow know that the third device in the
chain is always the "bluralizer"? I suppose that makes sense.

But these things are a truck roll anyhow, and 2.5 minutes sending a node 
address isn't that much more work.

I wrote a proposal once for a MODBUS system to automate addressing, but
it required a priori knowlege of order of devices on the bus, powering
them up in order  and nobody could guarantee that. Stuff was wound
every which way, so it was decided that explicit addressing was
preferred.

> And, protocols to handle the case where two devices are
> NOT unique (i.e., duplicate address).
>

In reality, that cannot be done for ostensibly "serial"
stuff. CAN is different[1]; but it's still a CM fail.

[1] I don't really recall what happens there.

> 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.
>

That's true. That's a sort of "degenerate" case where your
proposal makes sense.

It still smacks of "look! If we're real clever, we can
eliminate a whole wire!" which makes me eye-roll :)

> 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.

Right.

-- 
Les Cargill

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