0
\$\begingroup\$

So I have a interesting problem that someone could give their input. I'm working on a project where I have 100 "devices" each with its own EEPROM. The "devices" can be connected together in a stack up to 5. enter image description here

If EEPROM has 3 or 4 bit address - eventually they will clash. If I could find EEPROM with 8 bit address I could achieve this, but I have spent many hours looking for programmable 8 bit address on EEPROM without any luck.

One thing that I think might work would be some counter logic on the clock that would cascade the data packages down the line - I would lose speed and would be limited to fixed sized "packages". But that would be fine as speed is not required in this application.

Am I trying to solve a problem that already has a obvious solution? Maybe I'm just overcomplicating things and should add some super cheap microcontroller.

\$\endgroup\$
7
  • \$\begingroup\$ Are the EEPROMs directly connected to the bus? Is there an abstraction between "device" and EEPROM? What do you mean with ""devices" can be connected together in a stack up to 5." -> what is the implication? \$\endgroup\$
    – Velvet
    Mar 7 at 9:03
  • \$\begingroup\$ I'm still designing the thing. So there can be anything I need. All this could be solved with 8bit EEPROM address, but at this moment I'm not able to locate such a part. Additionally it has to be relatively cheap - I would like to stay under 50 cents as there are more costs to the "device". And eventually making thousands of them would add up. \$\endgroup\$ Mar 7 at 9:07
  • \$\begingroup\$ @Velvet sorry forgot to address your last question. Think of standalone cubes that mag lock on top of each other. So each cube can only communicate thru the previous one in the chain. And I would like to keep the amount of connections on the low side, ideally just power/ground data/clock \$\endgroup\$ Mar 7 at 9:27
  • \$\begingroup\$ Well, how each board would know it's EEPROM address? With stack of 5, 3 bits is enough for each stack. But each stack needs isolating from other stacks. What would these boards in a stack even contain and why do you need an EEPROM on each of them? What problem the EEPROM solves? And you can't have 256 EEPROMs on a physical bus, and I2C addresses are 7-bit anyway, unless you use the rarely-used feature of 10-bit/2-byte I2C addresses, which causes more problems than it solves. \$\endgroup\$
    – Justme
    Mar 7 at 10:26
  • \$\begingroup\$ There is some confusion. At any given time there are only maximum of 5 devices on the bus. But those devices can be swapped in and out with any of the 100 other devices. \$\endgroup\$ Mar 7 at 10:58

4 Answers 4

1
\$\begingroup\$

If you simply have a bus with master and only 5 slave devices from a pool of 100 devices, here is one example how it could be done.

Just put all EEPROMs in the same address, and program them with different contents to identify which chips are present.

Erase all EEPROMs first so they are empty and contain all bits 1.

Then set unique bits on each device to 0 based on their ID.

For example, program byte 0 of device 0 to e.g 0x00, byte 1 of device 1 to 0x00, etc.

Then when the master reads all EEPROM chips e.g. 100 bytes starting from memory address 0, if a byte at some address is 0xFF the device is not present and if a byte at some address is 0x00 then it is present. With 5 devices only 5 bytes will be 0x00.

\$\endgroup\$
4
  • \$\begingroup\$ Oh. This sounds interesting. I never considered what actually happens when the devices clashes. I guess if all 5 devices send out ACK at the same time and then send information for the byte at specific address it should work. This is actually genius. This won't allow to write data when the device is in the stack, but it will allow to identify if it is there. \$\endgroup\$ Mar 7 at 13:02
  • \$\begingroup\$ Exactly. You could write protect the EEPROM unless it is being programmed. And all devices will on a properly working bus react correctly to the bus events, so there is no reason why they would not work. For the purpose of ID, this will work. For reading any other device or ID-specific data, there is not much storage space as you would be wasting 99% of it if you allocate 1% per device. Even 16 bytes for 128 devices requires 2048 bytes or 16 kbits of EEPROM. \$\endgroup\$
    – Justme
    Mar 7 at 13:11
  • \$\begingroup\$ My final solution will have a microcontroller, one of the cheap 10 cent ones. But I will use this method to identify and communicate with the device. All will have the same I2C address. I will query for all 100 devices and listen if any of them respond. After that I can exchange information by broadcasting my own internal "id" and only the matching device will respond. At least it works in my mind! \$\endgroup\$ Mar 7 at 19:00
  • \$\begingroup\$ @somerandomusername If you have a MCU there, why not let them send their ID in the same way that I described. You should have givem more info instead of asking about what kind of EEPROMs exist. Or just broadcast your own internal ID and let the MCU that matches with it respond. You don't seem to need even the EEPROM for anything. \$\endgroup\$
    – Justme
    Mar 7 at 19:20
2
\$\begingroup\$

Yes, a microcontroller wouldn't be a bad investment here; helping you financially, it could well also absorb the functionality of the eeprom altogether and carry the eeprom content in its internal memory. (You can do nice things like ordering all microcontrollers pre-programmed with an i2c bootloader and maybe some automatic test mode from the factory, and then program the actual software+eeprom contents at the end of your production line)

I'm not sure, but your problem does sound a bit like what SMbus was invented for, so maybe look into that. It's an arbitration / address assignment layer with predefined control packets, built stop of i2c.

\$\endgroup\$
1
  • \$\begingroup\$ While @Justme answer solved this problem I probably will go with microcontroller solution. It will allow to be bit more flexible if I decide to add more features to my "devices". And there are quite a lot of cheap and capable microcontrollers that cost the same as low end EEPROM's \$\endgroup\$ Mar 7 at 13:05
1
\$\begingroup\$

Use a i2c gpio extender (PCF8574) - write data to the 8574 to select a bank of EEPROMs via a chip enable (CE). Or use the 8574 to enable a sub i2c bus. As @Velvet says - use an abstraction between the device and EEPROM.

\$\endgroup\$
1
  • \$\begingroup\$ I forgot to mention that I have a restriction of 4 wires that can go from device to device. Two for power/ground and two for I2C. \$\endgroup\$ Mar 7 at 9:32
1
\$\begingroup\$

Evidently, you've never heard of the Dallas 1-Wire protocol. It allows the connection of an arbitrary number of devices to a bus, and the bus master can discover the unique identifier of each connected device.

You can in fact purchase 1-wire EEPROMs for about $0.25 each.

\$\endgroup\$
1
  • \$\begingroup\$ No, this is the first time I have read about it. Will definitely look into this. \$\endgroup\$ Mar 7 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.