Bean's SX28 8x8 PWM Code and SX28 Addressable

[David Cary]

> your limit per serial wire depends on how you approach it.

That's certainly true.
But I am mystified as to why so many people "hardcode" addresses into
firmware -- that requires a custom version of the code for every chip
on the serial network.
I am also mystified as to why so many people "use a dip switch", which
requires a bunch of pins to read the dip switch.

Why don't these people use "scalable" networking protocols that scale
up to an unlimited number of chips?
Protocols that work fine with identical firmware in every chip, and
only require a maximum of the "serial data in" pin plus 2 or so other
pins on the master and each slave, even if there are dozens of slaves?

Off the top of my head, here are 3 such protocols:
(Pick whichever one protocol is the easiest for you to implement).
(Please tell me about other "scalable" "simple" networking protocols,
especially non-proprietary open standards).

* daisy-chain serial SPI: (4 wires per slave; automatic baud rate
synchronization) approach used by, among other things, JTAG scan.

* decrement packet address: (2 wires per slave) each chip has a
serial-in and a serial-out pin. The host serial-out pin is connected
to the first slave serial-in pin. Each slave serial-out pin is
connected to the serial-in pin of the next slave in the chain. (The
last serial-out pin is typically connected to the serial-in pin of the
master, for loopback test purposes). When a chip receives a packet of
data on the serial-in line, it checks the destination address. If the
destination is address "00", it accepts that data as a command, turns
on lights, spins motors, activates the death ray, etc. etc. If the
destination address is any other address, the chip forwards the packet
to the next chip almost exactly. Every byte of the message is copied
the same, except for the address byte(s), which are decremented. If
the received address was "99", the chip sends "98"; if the received
address was "01", the chip sends "00". (With a bit of clever
programming, each chip does not have to wait until the entire packet
is received, but instead can start transmitting at near-wire-speed as
soon as the address byte is received). After forwarding the entire
packet, the slave immediately forgets it (in particular, it does *not*
accept that packet as a command).

* daisy-chain select, common data: (3 wires per slave) The host
serial-out pin is directly connected to every slave serial-in pin. In
addition, each chip has a select-in and a select-out pin. The host
select-out pin (which the host normally holds high) is connected to
the first slave select-in pin. Each slave select-out pin (which the
slave normally holds high) is connected to the select-in pin of the
next slave in the chain. When the slave-select line of a slave is
high, it "sleeps", ignoring the serial data line. When a slave sees
its select-in pin pulled low, it wakes up, accepts first command on
the common serial line (even if the command is "no-operation"), and
then pulls its own select-out pin low and goes back to sleep, ignoring
further commands until it is woken up again. When that slave sees its
select-in pin pulled hi, it immediately drives its own select-out pin
high and goes back to sleep. At some later time, when the slave sees
its select-in pin pulled low, it (as always) wakes up and accepts
exactly one command on the common serial line, then pulls its own
select-output line low. (Even while sleeping and ignoring most
commands on the common serial line, perhaps the slave might wake up on
the special "On my mark ... NOW!" synchronized start command addressed
to every slave).

Perhaps one of these protocols could be used to automatically assign
addresses whenever slaves are added, removed, or re-arranged, even if
some global broadcast net (transmitting addressed packets) were used
to transfer most data.

The "daisy-chain SPI" protocol has a name; do these other protocols have a name?
Is there a general name for this entire category of protocols, a
better name than "scalable" "simple" networking protocols?

--
David Cary
http://carybros.com/
http://opencircuits.com/
http://wikiindex.org/Pica-wiki
PIC/PICList FAQ: http://www.piclist.com
http://www.piclist.com/member/DAV-MP-E62a
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
http://www.piclist.com/techref/postbot.asp?by=thread&id=%5BSX%5D+Bean%27s+SX28+8x8+PWM+Code+and+SX28+Addressable
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Michael Rigby-Jones]

> -----Original Message-----
> From: piclist-bounces@... [mailto:piclist-bounces@...] On
Behalf

> Of David Cary
> Sent: 24 March 2008 05:34
> To: piclist@...
> Subject: [SX] Bean's SX28 8x8 PWM Code and SX28 Addressable
>
> > your limit per serial wire depends on how you approach it.
>
> That's certainly true.
> But I am mystified as to why so many people "hardcode" addresses into
> firmware -- that requires a custom version of the code for every chip
> on the serial network.
> I am also mystified as to why so many people "use a dip switch", which
> requires a bunch of pins to read the dip switch.
>
> Why don't these people use "scalable" networking protocols that scale
> up to an unlimited number of chips?
> Protocols that work fine with identical firmware in every chip, and
> only require a maximum of the "serial data in" pin plus 2 or so other
> pins on the master and each slave, even if there are dozens of slaves?
>
> Off the top of my head, here are 3 such protocols:
> (Pick whichever one protocol is the easiest for you to implement).
> (Please tell me about other "scalable" "simple" networking protocols,
> especially non-proprietary open standards).
>
> * daisy-chain serial SPI: (4 wires per slave; automatic baud rate
> synchronization) approach used by, among other things, JTAG scan.
>
> * decrement packet address: (2 wires per slave
>
> * daisy-chain select, common data: (3 wires per slave)

Unless I have misunderstood, all of these would appear to suffer from
increasing latency the further away from the host the slave is in the
network.  With a large number of slave devices this could be
unacceptable.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Wouter van Ooijen]

>> Off the top of my head, here are 3 such protocols:
>> (Pick whichever one protocol is the easiest for you to implement).
>> (Please tell me about other "scalable" "simple" networking protocols,
>> especially non-proprietary open standards).
>> (snip)
> Unless I have misunderstood, all of these would appear to suffer from
> increasing latency the further away from the host the slave is in the
> network.  With a large number of slave devices this could be
> unacceptable.

Here I go again: for a customer I once designed a chain-of-nodes
'network'. each node can is essence block the communication to the next
no, or let is pass. Letting it does not add a significant delay. After
startup all nodes block, and the head-end gives out the addres to the
first node, the first node unblocks, the head-end assigns the next
address, etc. Worked well up to ~100 nodes. The network was larger, the
head-ends were also chained.

Wouter

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[David Cary]

Dear piclisters,

> Michael Rigby-Jones
>
> Unless I have misunderstood, all of these would appear to suffer from
> increasing latency the further away from the host the slave is in the
> network.  With a large number of slave devices this could be
> unacceptable.

You are right.
At best, those protocols have a latency of one or two character-times per slave.
Off the top of my head, here are 2 scalable protocols with even less
latency (after the initial boot-up time):
(Please tell me about other "scalable" "simple" networking protocols,
especially non-proprietary open standards).

* packet blocking: (2 wire per slave)
The host serial-out pin is connected to the first slave's serial-in
pin and a (practically zero-latency, compared with normal line delay)
noninverting line driver.
The output of the first slave's driver goes to the second slave's
serial-in pin and its driver... and so on.
Each slave can "block" its own line driver (forcing the driver output
to line idle, blocking communication to downstream slaves).
At power-on, all slaves block.
During bootup, the host gives out some address ("your address is now
A1"; "A1: now unblock") to the first slave, the first slave unblocks,
the host sends an address ("If you don't already have an address, your
address is now A2"; "A2: now unblock") to the second slave, and so on.
Eventually all the slaves are unblocked, and every slave can listen to
everything the master says.
>From then on (until the next reboot), the host sends packets addressed
to a specific slave (or to the special "Everyone" address).
When the host sends the "slave #FF, turn on your LED", every slave
simultaneously receives the message, but only slave #FF recognizes and
acts on the message.
(Is this "packet blocking" the same as what Wouter van Ooijen described?)

* daisy-chain select, common data: (3 wires per slave)
The host serial-out pin is directly connected to every slave serial-in pin.
In addition, each slave has a select-in and a select-out pin.
The host select-out pin is connected to the first slave select-in pin.
Each slave select-out pin is connected to the select-in pin of the
next slave in the chain.
At power-on, everyone holds their select-out pin high.
When the slave-select line of a slave is high, the slave "sleeps",
ignoring the serial data line.
During boot-up, the host pulls its select-out line low, and
gives out some address ("your address is now A1"; "A1: now pull your
select-out line low") to the first slave; the first slave pulls its
select-out line low, the host sends an address ("If you don't already
have an address, and your select-in line is low, your address is now
A2"; "A2: now pull your select-out line low") to the second slave, and
so on.
Eventually all the slaves have their select-in pin pulled low.
>From then on (until the next reboot), the host sends packets addressed
to a specific slave (or to the special "Everyone" address).
When the host sends the "slave #FF, turn on your LED", every slave
simultaneously receives the message, but only slave #FF recognizes and
acts on the message.

(So, how do the slaves communicate back to the host?)

p.s.:
With any daisy-chain network, it's probably good for both ends of the
daisy chain to connect back to the host.
That makes it easy for the host to check for breaks in the chain.

--
David Cary
http://carybros.com/
http://opencircuits.com/
http://wikiindex.org/Pica-wiki
PIC/PICList FAQ: http://www.piclist.com
http://www.piclist.com/member/DAV-MP-E62a
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
http://www.piclist.com/techref/postbot.asp?by=thread&id=%5BSX%5D+Bean%27s+SX28+8x8+PWM+Code+and+SX28+Addressable
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist