Uniquely identifying removable hardware components

Ok, so my application comprises a series of servo motors, up to 8, controlled via an Arduino Uno. Each motor attaches to a Darlington driver, which connects to a 74LS595 shift register. The shift registers cascade from the Arduino, pretty much as depicted in the attachment. Note: The attached image depicts two servos coming from each shift register, but my project will only be using one servo per register. Imagine though that each shift-regsiter/driver/motor instance is a seperate piece of hardware that connects to the preceding one via a plug/socket, which chains up the digital pins, common ground and voltage rails. At any given time there will be between one and 8 instances connected together. I should also mention that my project uses three more Arduino pins for a second set of cascaded 74LS595’s to control LED’s. So each module will have 2 shift registers, a driver and motor attached to one of them, and a series of LED’s connected to the other.

The device has a switchable configuration mode, in which it does a count of how many devices are attached, and this could be achieved by sacrificing one bit on each register to be held permanently high or low, in contrast to the other 7 bits when in config mode. It’s just a simple pattern match to detect how many “units” are present. Whatever method for detecting is used, the count is then saved to EEPROM. When flicked over to normal operation, and each time the device is reset/powered on, this count is read back from EEPROM and another device-count-calculation is performed. If the numbers don’t match, then we must go back into config mode.

It’s important that I know how many devices are attached when we enter normal operation. It’s even more important to know when this changes as the device will think it’s behaving normally but in reality it’s failing one of its prime purposes.

Here’s the thing, I don’t have a problem with any of the above, but what I can’t detect by this method is whether or not the add-on devices have been reassembled in a different order. For example; 1) user switches on in normal mode and is advised config needs to be done before normal operation, 2) user performs automated config, 3) user resets and enjoys device in normal mode, 4) (and here’s the problem) user switches device off and pulls modules apart, reassembling in different order but the same original number of modules, 5) user turns device back on and Arduino is none the wiser.

So my question is this: How can I uniquely identify each module, so that when I’m in config mode I can store not only the device count, but each individual identifier too. If I could do this I could detect their assembled order and either recalibrate or better yet, have the device gracefully adapt to the new order.

Perhaps you could have EEPROM on each device and assign it a sequential ID when the device bus is scanned. If you then read back the device IDs you can determine if they are still in sequential order or not.

It sounds like you might need more intelligence on each device than a shift register. Perhaps a small AVR chip like the ATtiny84 (14-pin) or ATtiny85 (8-pin) processors. The SPI bus interface acts much like a shift register but the processor can interpret the arriving bytes any way you like.

Hi John,

I like your EEPROM idea, and that is the way I was thinking also, but I don't see how that might work with my cascading model, unless I can access the EEPROM for read/write via the shift register.

I may need a cpu on each module after all. I came across this article about networking multiple ATMEGA328P's. It will add cost and complexity, and unfortunately circuit space too which is at a premium, but it might be the only way to achieve it?

Have you considered using i2c expanders instead of shift registers?

For example pcf8574. It has 8 outputs, which could drive your Darlingtons or leds. But it also has 3 address inputs which uniquely identify it on the i2c bus. Up to 8 of these chips can be attached to the same bus. The Arduino can query the bus to find which of the 8 chips are present.

Cable length could be an issue. How far apart will your modules be to each other and the Arduino?

my application comprises a series of servo motors, up to 8, controlled via an Arduino Uno. Each motor attaches to a Darlington driver,

Servos don't normally attach like this, only normal DC motors. Are you trying to make them into a servo?

The schematic would suggest you are using stepping motors not servos.

Yes, I assumed the OP is confusing the terms "servo" and "stepper".

You don't need Mega at each node. Small MCU like ATTiny should handle it easily. If you use it instead of the shift register no extra space is needed and with a cheap ATTiny (you need very little resources so go for cheapest with enough legs) cost increase will be small. It will "only" need some time to program it.

Thanks for all the replies.

PaulRB:
Yes, I assumed the OP is confusing the terms "servo" and "stepper".

I absolutely meant steppers, not servos. D'Oh!

I've rethought the whole thing and decided that the I2C protocol is the way to go. I'll use an ATMega384 as the master and then up to 8 ATTiny84's as the slaves. Each slave will have a shift register for the LED's, as well as a driver/stepper motor. I should have enough lines on the ATTiny84 to do all this as well as participate on the I2C network. There's a lot more dev required, but I'm going to end up with a more robust product.

PaulRB:
Cable length could be an issue. How far apart will your modules be to each other and the Arduino?

The modules will plug into each other, max length will literally be about 1 foot away from the ATMega.

johnwasser:
Perhaps you could have EEPROM on each device and assign it a sequential ID when the device bus is scanned. If you then read back the device IDs you can determine if they are still in sequential order or not.

Yep, this is the way to go I think. During config mode I will use the ATTiny EEPROM and write a randomly generated ID string to each, then store them and their order into the ATMega EEPROM. In normal operation, I will read these back and compare.

That sounds way more complicated than it needs to be, or else I am missing something!

Why the tiny84s just to run shift registers? Why not use i2c expanders like I suggested? What does all this configuration data stored in eeproms indicate?

With your tiny84/shift register plan, how will the Arduino be able to tell what order the modules have been assembled in? I can see how it can tell how many and which modules are connected, but not the sequence.

Probably some daisy chain communication protocol would be better than “normal” I2C: this way you will have order of modules hardwired in the protocol.

PaulRB:
That sounds way more complicated than it needs to be, or else I am missing something!

Why the tiny84s just to run shift registers? Why not use i2c expanders like I suggested? What does all this configuration data stored in eeproms indicate?

With your tiny84/shift register plan, how will the Arduino be able to tell what order the modules have been assembled in? I can see how it can tell how many and which modules are connected, but not the sequence.

Hmm, I suspect you are correct. I was still thinking along the line of cascaded shift registers, but I see nothing in I2C that will offer up a position within the network. How would I2C expanders change that?

It is mission critical that modules can be added or removed. When a configuration change is made it is critical that this is detected and that the user places the device back into config mode to reassess the current order.

As long as I can control the motor and instruct a series of LEDs for each module from the master, have each module identifiable and gracefully removable, I'm not tied to any particular chip. Just a matter of finding a combination that works.

Is there only 8 of such modules or do you want to have "unlimited" number of them with up to 8 connected?

Smajdalf:
Is there only 8 of such modules or do you want to have "unlimited" number of them with up to 8 connected?

From 1 to 8 modules

sfkHooper:
Hmm, I suspect you are correct. I was still thinking along the line of cascaded shift registers, but I see nothing in I2C that will offer up a position within the network. How would I2C expanders change that?

It is mission critical that modules can be added or removed. When a configuration change is made it is critical that this is detected and that the user places the device back into config mode to reassess the current order.

As long as I can control the motor and instruct a series of LEDs for each module from the master, have each module identifiable and gracefully removable, I’m not tied to any particular chip. Just a matter of finding a combination that works.

Actually, I’ve just realised that it doesn’t matter what order the modules are reassembled, as long as they can be uniquely identified during config mode, and then addressed via that identification later on. During normal operation, the master needs to be able to tell a stepper motor to move into a certain position (speed is not critical) and light a corresponding LED, at certain times throughout the day. This is all setup during config. I was concerned that the order of modules could be mixed up and then the master would end up telling the wrong module to move and light up. Given the application, this could be potentially disastrous. But if the modules have a retrievable ID, then it doesn’t matter what order they are reassembled in.

So I’m back to thinking I2C really is the way to go.

it doesn't matter what order the modules are reassembled

That's a relief, I don't have a simple solution for that.

control the motor and instruct a series of LEDs for each module

How many leds per module? If only 4, then one pcf8574 can handle motor and leds for each module. More than that, need to look at other chips.

tell a stepper motor to move into a certain position

Problem! Steppers can't do that. Servos can. Steppers can only do that if you add some kind of limit switch so you can find a known position.

The number of connected modules can be detected by shifting out known patterns, and reading back from the end of the chain, until the first pattern is received. A special terminator can be attached to the last module, that feeds the shift register output into another (added) line, that can be read back by the Arduino from the first module.

If the modules shall be distinguished, you can add another parallel-in shift register, whose inputs can be set to a unique pattern for each module. Then read out these patterns, to learn about the number and sequence of the connected modules. The clock for these registers can be one of the other shift clocks, no further output pin required.

If only 8 modules exist they can be distinguished by hardware I2C address (if pcf8574 is used). If their order is not needed it is enough. If order is needed and there are pins left you can connect pin 0 of next module to pin 7 of previous module. Toggling the pins can determine the order.
Also this says only 2 pins are needed for driving stepper if Darlington array is used wisely.