strategy for enumeration in random I2C Bus system

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi i was thinking of good way to enumerate devices in an I2C Bus System with an unkown number of participants. To me it sounds like a problem which is done already.

 

So my setup is that I will have a random number (n) of slave devices(ATtiny1626) which will be connected in a random order. Connected via the TWI bus.  All devices will have an unknown but unique 16bit identifier which has to be enumerated by the master. My approach to enumerate the devices would be connected via the identifier to a response time with 1us time slots.

 

So that a device A with the identifier 15 would wait 15us to claim the bus and a device B with the identifier 325 would wait 325 us. And the master would have to wait a maximum time of n*65536-sum(ni) us to get all devices.

 

  1. First the master would send a broad message to request  the first device.
  2. After 15 us our device  A would respond and get the unique I2C Address 1.
  3. The master would send again a request for devices. Device A has already an I2C Address and wouldn't respond to that request.
  4. But after 325us our Device B will respond to that request and will be enumerated with the I2C address 2.
  5. Untill the master waits one time for 65536us in which no device responds and the master can be sure that there are no devices left. 

German electrical engineer living in the Philippines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That sounds like a complex strategy. How many I2C devices are you talking about and how often do they change ?
1us is in i2c-timing a very short time.

If anyway possible i would advice to setup the I2C adress by hardware pins as this is the 'standard method' (see e.g. PCF8574 datasheet)

If that is not possible, I would split up the communication between 'Normal' and 'Service' routines.
The 'Service' will make sure all have a unique I2C adress and programs this in EEPROM of the slave
Once thats done, the 'Service' is not needed anymore until hardware has been changed.
The 'Normal' communication will then be 100% standard I2C, you could start by scanning the present twi adresses

For the 'Service' you could think of (just some ideas):
- A multi-master I2C bus, 
- Set the un-programmed devices on a fixed 'detection' I2Cadress, make a slave-command where the UniqueId (0..65535) can be programmed to repsond. During 'Service', you need to scan the UniqueId range once.
- A detect-button on the I2C slave device
- More other 'service' strategies possible, main importance to execute that only after i2c slaved have changed

Also mind that I assume you want to know which module is connected where.
Patrick

Last Edited: Fri. Feb 25, 2022 - 08:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you looked at what the I2C Specification says about this?

 

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

 

Specifically, section 3.1.13 seems applicable.

 

As NXP are the owners of the spec, perhaps they have a forum for this ... ?

 

flexbex1 wrote:
1. First the master would send a broad message to request  the first device.

But how do you know which is the "first" device?

 

All the connected devices will see & ACK the broadcast ("general call") address ...

 

Have you looked at how the Maxim (formerly Dallas) 1-WireTM bus handles this ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mhh thanks. But that won't help me. Because it still didn't explain how the devices would get  an address. 3.1.13 explains more how to do broadband general system calls. But the 1626. Can do that quite easily. It could respond to address masks and or all calls. So that won't be an issue. On how I planned to handle it. Refer to my second part

 

 

So that a device A with the identifier 15 would wait 15us to claim the bus and a device B with the identifier 325 would wait 325 us. And the master would have to wait a maximum time of n*65536-sum(ni) us to get all devices.

 

  1. First the master would send a broad message to request  the first device.
  2. After 15 us our device  A would respond and get the unique I2C Address 1.
  3. The master would send again a request for devices. Device A has already an I2C Address and wouldn't respond to that request.
  4. But after 325us our Device B will respond to that request and will be enumerated with the I2C address 2.
  5. Untill the master waits one time for 65536us in which no device responds and the master can be sure that there are no devices left. 

 

German electrical engineer living in the Philippines.

Last Edited: Sat. Feb 26, 2022 - 12:12 PM