# Help with device identification in a chain

So I'm working on a new project where I'm trying to identify devices on a closed protocol "network" of sorts. I'm trying to determine how many devices are out there and unique id's of each device. I'll probably have an eprom or something similar to store the unique identifier. The question I would have for the forum would be: is a daisy chain the best way to identify the devices? (as shown below)

I was thinking I could try to also route individual control lines to the devices but I won't necessarily know how many total devices are out there. I will be able to connect the final device back to a return line (physically using a jumper and identified here by the blue dot).

So again, my question is: is there a better way to do this?

Thanks!

-
It might be helpful to know more about Device 1 2 and 3. If they have a defined protocol already, you would have to hook them up exactly as the device wants. –  Kellenjb Oct 14 '10 at 3:16
Hi, Chris. How many devices are we talking about? I know you say you won't know the total, but are we talking 10, 1000, or more? Also, what kind of environment will you be in-- clueful users, or not so much? How important is robustness? –  pingswept Oct 14 '10 at 3:24
whats the PHY? I2C? SPI? something else? –  Mark Oct 14 '10 at 3:46
The phy hasn't been determined yet, this is still early in the process. It'll max out at 4 at a time right now I think but could be more in the future. The other thing is that there is potential that the 4 devices will be different every time. These will basically be swappable devices. –  Chris Gammell Oct 14 '10 at 14:20

It would help to know what phy layer you're using. But, here's some general information:

If you're using I2C, your bus should look something like this:

(taken from societyofrobots.com)

At runtime, you can detect the I2C addresses by scanning the bus by sending a START condition to every address and checking for an ACK.

If you're using SPI, you'll need a chip select line per device. If you run out of pins, you could use some kind of multiplexer. You may be able to scan the bus by asserting each chip select line in turn and attempting to communicate.

-
I think I'd trend towards the SPI solution because of the nature of the devices I'm working on. I'll be able to hardwire to a point but then it'd be unknown past that point (the devices will change out once in a while) –  Chris Gammell Oct 14 '10 at 14:27
Another thing I thought of. Since I'm trying to make the devices swappable, I was also hoping they'd be the same board (layout with only the programmed unique ID being different). That's another issue because the CS lines wouldn't necessarily only be running to one of the devices. I'm really concerned that I'm setting myself up for a "self organizing network" which is waaaay more complicated than I want. –  Chris Gammell Oct 14 '10 at 14:39
If you have an MCU in each device, you might be able to do without the chip selects. All devices monitor the data+clock lines and only respond when addressed (eg. first byte received). Each device would need to have a unique address. If you're trying to cut down on wires (at the expense of speed), have a look at Maxim's 1-wire microlan bus. –  Toby Jaffey Oct 14 '10 at 14:45

You might want to look at LIN ( http://en.wikipedia.org/wiki/Local_Interconnect_Network ) which can use something called SNPD to detect and assign addresses to nodes at run-time. There are three methods presented in the Wikipedia article, and any would work, but some are apparently patented, so be careful.

The LIN protocol itself is a fairly simple SCI-based protocol with some added reliability features, but the SNPD techniques could be applied to any serial data transfer.

-

Send a command to the first device to send its address, followed by a counter (zero to start) Each device will read in the command and output the command.

Then read in the counter, increment it, and output the counter.

As each device gets the command, it appends its address to the response.

If the devices are numbered 1, 2, 3, then the resulting response will be:

DISCOVER CMD
COUNT = 3

-

If you don't have to do too much fast talking look at Dallas One-Wire for your bus.

1 wire ( and an implicit ground)

addressable, 250 off per bus, routeable, and the interface devices are very cheap.

Really useful as a system management bus because it is so expendable. I've got a family of systems that use 1-wire for system management and device discovery, then something else (like) jindi for communications.

I wholeheartedly recommend something with a meta-protocol so you can change things later.

-

You really can't even make a choice here without determining the PHY layer but some ideas:

If the system really is daisy chained as drawn then bring up each device in order. Factory program to the "broadcast address" if the PHY has one (like I2C does). Then just have each device pick an address and send that address to the next device as it moves down the chain.

If use 8bit UIDs, you get bonus points, at least from me, if you spell something comical in ASCII with the addresses:

Master: "Hey device 1, choose an address" Device 1: "M", hey device 2 choose an address Device 2: "y" Device 3: "B" Device 4: "o" Device 5: "s" Device 6: "s" Device 7: "S" Device 8: "u" Device 9: "c" Device 10: "k" Device 11: "s"

Alternatively if your design has a fixed number of devices: I had a design that used a backplane that allowed up to 4 cards to be plugged in. What i ended up doing what placing a I2C based GPIO expander on the backplane (actually it was a fan control IC i needed anyway, i just picked one with and I2C interface and some GPIOs on it).

I routed a GPIO through each card edge connector to the reset pin of the DSP on each plug in card. All DSPs were factory programmed to 1 address. The system controller brought the slots out of reset 1 at a time, an I2C command was sent, if something ACKed it was assumed the slot was populated and a command was sent for it to change its I2C address to a UID for that slot. This was done for each slot with a reasonable reply time out.

If its a shared bus that capable of slave initiating transfers, aka multi-master. Just have the slave device assert control of the bus and ask the master for an address, master just gives it the next address in line, think DHCP. Same bonus points as above.

If the PHY is single master and you have a completely unknown number of devices....daisy chain a GPIO through them and use that to control if they respond to a factory programmed address? Then when the slave gets its address, it de-asserts the next device in line? This way you only need 2 GPIO pins per device and 1 for the master and you can bring devices up one at a time. Should work i think.

Anyway, honestly all speculation till you choose a PHY and can tell us more about how the overall system is connected.

-

Ways for the main CPU to discover how many devices are connected to it -- and the ID of each one -- include:

• daisy chain systems don't require a unique "address" -- each device is implicitly addressed by its distance (hop count) from the main CPU. Once you've figured out there are 7 devices, you can address each on at location 1, 2, 3, 4, 5, 6, and 7.
• Systems with a global clock line, such as daisy-chained SPI: the main CPU shifts in a unique pattern followed by lots of "0" bits, and counts how many clocks it takes before that pattern returns to the main CPU: if it clocked out N clock bits, and each device has a 16 bit register, then there must be N/16 devices on the chain.
• Systems with no global clock line, only local busses, such as token-ring networks: Each message from the main CPU to a peripheral device includes a destination address. When a device gets a message addressed to "1", it operates on that message. Otherwise, it passes the message to the next device unchanged -- except it decrements the address. When the main CPU sends out a message with an impossibly large destination address, none of the devices claim it, and the main CPU can tell how many devices are on the bus by how many times that address was decremented going all the way around the loop (the hop count).
• device select systems don't require a unique "address" -- each device is implicitly addressed by which of the device select lines from the main CPU activate it. For each device select line, activate the device select line and send a simple "who are you?" message, and see if there is any device at the end of that line to give a response.
• bus systems that have only "global" ("common") signals where every device has a unique hard-wired address.
• Some systems, such as CANbus and some RFID protocols, allow the main CPU to detect that there are a hundred devices attached to it, and the unique ID of each one, after only a few hundred commands, even when there are millions of possible addresses -- singulation protocols. This allows every peripheral device to have a unique address, even when millions of them have been manufactured, and still allows the main CPU to rapidly discover the relatively few devices that are actually talking to it.
• Some protocols, such as I2C, do not support a rapid singulation protocol, but allow scanning: the main CPU can send a "Hello, , can you hear me?" to every possible address. (This may take a very long time if there are millions of possible addresses).
• bus systems where each device is (eventually) assigned an address, which can be different each time you turn it on: such as DHCP. This is probably unnecessary complexity for your application.

Many people claim that "If you're using SPI, you'll need a chip select line per device." If that is true, then what is a good name for that other protocol that does not require a chip select line per device, only a fixed 4 pins on the main CPU even with dozens of peripheral devices -- i.e., the protocol used by devices that Wikipedia calls "daisy-chain SPI" ?

Rather than re-inventing yet another square wheel, you might want to check out the list of common embedded systems protocols, so you avoid most of the gotchas that often bite people who design protocols from scratch. Perhaps you are lucky and can use one of those protocols as-is, or with relatively minor tweaking.

-
The term "SPI" has come to encompass just about any clocked-serial interface where a single master device has exclusive control of the clock, and where the state of a data line is irrelevant except on a particular clock edge (for some devices, the relevant edge is rising; for others, falling). Most things that are called SPI devices require individual chip selects, but there are many devices which can be adapted to communicate with an SPI bus (e.g. 74HC595 or 74HC165 chips) that can be daisy-chained. I'd regard a chain of six 74HC595's with a common latch signal as a single SPI-ish peripheral. –  supercat Sep 8 '11 at 17:54