>>| Last time I have made something like this it is ended up as a
>>| token ring :-)
>>| So the 1st PIC's TX goes to the 2nd RX, then it's TX to the
>>| 3rd RX and so on (and the two end is to the host/master of
>>| course). The host sends a message with an address, and if a
>>| PIC is not addressed then it just passes the message [on]

It doesn't have to be a ring.  Daisy chain going out from master
to a reasonable number of nodes worked just fine.  As follows:

[use monospaced font to view]

+--------+    +--------+    +--------+         +--------+
! Master !    ! Node 1 !    ! Node 2 !         ! Node N !
!      Tx!----!Rx    Tx!----!Rx    Tx!---...---!Rx    Tx!
!      Rx!----!Tx    Rx!----!Tx    Rx!---...---!Tx    Rx!
+--------+    +--------+    +--------+         +--------+

>> Utterly insane idea here, but... this could be used to allow
>> discovery of network devices and unique addressing without
>> having to have *any* hardcoded unique ID number or address
>> switch.

Not insane.  It works quite well.  I finished implementing such
a scheme for game show special effects in late 1984.  Slave nodes
handled physical I/O tasks such as light control, score display,
contestant button presses, etc.  Scheme was fast enough that we
did marque chase light effects with it at (I think) 9600 baud.

Hardware was based on Z80's.  All the nodes had identical hardware
with 2 UARTS on board with EIA-232 (RS-232) transceivers.  Slave
nodes have a "goes towards master" connection and a "goes to next
node" connection.  Master can support multiple chains -- one chain
per UART port built onto master controller.

As a side benefit, EIA-232 signals are regenerated by each node
for each packet, so as long as cable from node N to node N+1 was
within spec, distance from master to end of chain could be quite
long (several hundred feet).

To give credit -- Hardware and basic node addressing scheme was
the idea of the guy I was working with on the project.

>> Rather, the first device in the ring after the master is number
>> zero, the second is number one, and so on. Each device, rather
>> than just passing packets not destined for itself unmodified,
>> *subtracts one* from their address.

Better idea is to special case address zero (since check for
zero value is very fast).

For packets outbound from master to slave node N...

Slave nodes are address 1 on up.  Slave UART interrupt routine
subtracts 1 from address.  If result is equal to zero, packet is
consumed by that node.  If address is non-zero, packet is queued
up for onward transmission to next node.

For packets inbound from slave node N to master...

Slave node creates packet (ACK, button press, etc) with address
zero.  UART handler increments address by 1 before transmission.
Each subsequent node does the same as packet goes toward head end.
When received by master, it know what node sent it by current
address value contained in packet.

>> Reserve some special address for packets from slaves back to
>> master, which will not be modified (0xFF?).
>>
>> Assuming every device responds to some kind of discovery packet
>> with a response saying what kind of device it is, you simply have
>> to probe address 0, then 1, then 2, and so on. All present devices
>> will respond with a response packet addressed to the master

Initialization & discovery are the only tricky parts.  You can do
it two ways.

Reserve a broadcast address value (0xFF is a good choice) just for
initialization purposes(*).  If a slave node is not initialized and
it receives such a packet, it initializes itself and reports back
to the master that it exists.  If slave node is already initialized,
it passes the packet on to the next node.

(*) You can have two broadcast addresses -- 0xFF and 0x00.  Use
the 0x00 as a general broadcast where packet is acted upon by node
_and_ packet is passed onwards to next node as well.  It's a trade
off between complexity and speed in each slave node packet handler.

Second method, and the one we used (as I recall), was master just
sent a packet to address 1, then address 2, etc until it no longer
received a response.  But then we didn't dynamically reconfigure
the daisy chain.  Specific nodes were built into set pieces and
wired up to lights, displays, buttons, etc.  Master software had
to "know" what funciton mapped to which slave node ID.

> Not a bad idea, in that way you can insert new devices into
> the chain with zero configuration of the device itself (only
> configuring the host).

Right.  And then have master do a reinitialize function.  And if
a node failed, you could have one of the union workers swap in a
new node board without having to worry about configuring it.

> And how would you validate the packet - if you need a CRC you
> would need to recalculate the CRC

We used a checksum.  Timely response was more important than
absolute accuracy (like VOIP calls).  I don't remember if the
address octet was covered by the checksum either.

						Lee Jones

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