Sharing I2C bus

Author
DarioG
Allmächtig.
  • Total Posts : 54081
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: Oesterreich
  • Status: offline
2010/01/30 13:26:18 (permalink)
0

Sharing I2C bus

I need to use more than one (say 2..4) I2C devices which are sold with only one address available.

I was thinking of using 2 more pins from the PIC and go with them - for 2. And if ever more than 2 become needed m I can make up a I2C bus out of another (slave) PIC.

But then, I've been thinking if one can share the Data Pin and only use a separate Clock for each one: can you see possible conflicts or drawbacks about this?

GENOVA :D :D ! GODO
#1

16 Replies Related Threads

    dhenry
    Super Member
    • Total Posts : 4994
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Location: Colorado
    • Status: offline
    RE: Sharing I2C bus 2010/01/30 13:42:20 (permalink)
    0
    In these situations, we just use an I2C mux.
    #2
    Stefan Uhlemayr
    Super Member
    • Total Posts : 4292
    • Reward points : 0
    • Joined: 2005/05/12 12:25:46
    • Location: Germany
    • Status: offline
    RE: Sharing I2C bus 2010/01/30 13:43:53 (permalink)
    0
    ORIGINAL: DarioG

    I need to use more than one (say 2..4) I2C devices which are sold with only one address available.

    I was thinking of using 2 more pins from the PIC and go with them - for 2. And if ever more than 2 become needed m I can make up a I2C bus out of another (slave) PIC.

    But then, I've been thinking if one can share the Data Pin and only use a separate Clock for each one: can you see possible conflicts or drawbacks about this?
    The easiest way would be the usage of a PCA9546, which would allow you to connect up to 4 slaves with same address to your PIC - without wasting any pic-pin and without any troubles with "strange" software...

    Hope this helps, Smile
    Stefan

    EDIT: Dan, you're too fast for me.....grin
    post edited by Stefan Uhlemayr - 2010/01/30 13:45:10
    #3
    DougRice
    Super Member
    • Total Posts : 530
    • Reward points : 0
    • Joined: 2008/10/08 23:44:59
    • Location: 0
    • Status: offline
    RE: Sharing I2C bus 2010/01/30 13:46:11 (permalink)
    0
    Dario

    The Start and Stop are conditions when SDA changes when SCL is high.

    Would this mean that your alternative SCL would need to be low when not being used.

    If it was high, then the alternative chip would get lots of false start and stop conditions.

    It seems like an evening and a bread board awaits a free 16F88 chips with debug code to see what happens!

    best wishes,

    Doug
    #4
    dhenry
    Super Member
    • Total Posts : 4994
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Location: Colorado
    • Status: offline
    RE: Sharing I2C bus 2010/01/30 13:59:25 (permalink)
    0

    ORIGINAL: Stefan Uhlemayr

    Dan, you're too fast for me.....grin

    Well, you did do more work after all.

    FYI, TI also has equivalent devices.
    #5
    Ian.M
    Super Member
    • Total Posts : 13114
    • Reward points : 0
    • Joined: 2009/07/23 07:02:40
    • Location: UK
    • Status: offline
    RE: Sharing I2C bus 2010/01/30 14:06:56 (permalink)
    0
    As DougRice also points out, you will be issuing 'runt' pairs of START and STOP events with every data byte sent.  This is not supposed to have  any effect on a device that is already stopped but I remember hearing it can cause problems.  Thorough testing with the devices to be used will be essential. 

    Obviously you will also have to bit-bang the I2C protocol.

    As I2C multiplexors are available with up to 8 selectable ports, I wouldn't bother with the complex bit-banged shared data approach  unless this is for high volume production and you have to trim the last $0.01 possible from the BOM.


    #6
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    RE: Sharing I2C bus 2010/01/30 14:21:48 (permalink)
    0
    Thank you everybody!

    Well, yes of course bit-banging - those are pressure sensors and temperature/humidity ones, so slow and read once in possiblt 1..5 seconds.

    Now next question would be "what if I share CLK and use different Datas..." I'll think about it.

    As for the mux, I'll take a look at them. Actually, I used to believe that those things were more expensive, but will see (a PIC all in all would not cost much...)

    And, to tell the truth, those Pressure Sensors (from Sensortecnichs.de) are available with different addresses if more thna 200 are bought. The Sensirion, OTOH, are not...

    GENOVA :D :D ! GODO
    #7
    NKurzman
    A Guy on the Net
    • Total Posts : 16568
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    RE: Sharing I2C bus 2010/01/30 18:33:23 (permalink)
    0
    I common the clock, and have a separate Data for each.  It works well.
    The Bus rules apply you can add as many device as long as the bus stays in spec. 
    It can cheaper than mux chips, but usually slower.
    #8
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 06:27:42 (permalink)
    0
    Thank you, yeah, basically I don't  need speed so I'd like to avoid using a bus-mux, also because in the future we can obtain the differently-addressed devices...

    But you suggest sharing clock and using separate Datas. I will consider the 2 options.

    GENOVA :D :D ! GODO
    #9
    markp
    Super Member
    • Total Posts : 397
    • Reward points : 0
    • Joined: 2006/01/26 13:54:56
    • Location: 0
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 07:52:34 (permalink)
    0
    ORIGINAL: NKurzman

    I common the clock, and have a separate Data for each.  It works well.
    The Bus rules apply you can add as many device as long as the bus stays in spec. 
    It can cheaper than mux chips, but usually slower.

     
    If you common the data and have separate clocks the slaves will see start and stop conditions as noted in previous posts. The I2C spec actually says a start followed by a stop (i.e. 'null message') is an invalid format, so this should be avoided.
     
    If you common the clock and have separate data lines this should work. Basically the slaves will see 1's as the address and not respond, however I would suggest issuing a start condition to all slaves as well as the one being accessed. By issuing a start (or repeated start) condition the slaves' logic will be reset so they all see the beginning of the address phase in the right place. The slaves not being accessed will see 1's for the address and not respond for any of that cycle, the slave being accessed will see its correct address and will respond.
     
    Mark.
    #10
    Ian.M
    Super Member
    • Total Posts : 13114
    • Reward points : 0
    • Joined: 2009/07/23 07:02:40
    • Location: UK
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 08:36:24 (permalink)
    0
    Or since the sensors are identical, you *could* access them simultaniously at the expense of *some* code complexity! wink
    #11
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 10:45:29 (permalink)
    0
    Thank you Mark and, btw, what do you mean exactly Ian? Smile

    GENOVA :D :D ! GODO
    #12
    Stefan Uhlemayr
    Super Member
    • Total Posts : 4292
    • Reward points : 0
    • Joined: 2005/05/12 12:25:46
    • Location: Germany
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 11:33:27 (permalink)
    0
    ORIGINAL: DarioG

    Thank you Mark and, btw, what do you mean exactly Ian? Smile
    Well, I'm not Ian, but may answer, too wink:
    Having seperate data-lines you *may* access all slaves simultaniously. Put the data-lines according to your needs for every slave and after that you simply toggle the clock-line. Well, exactly this is the "strange" code I've mentioned above - the usage of the mux would simplify your task pretty much. And the argument not to use it just "because in the future we can obtain the differently-addressed devices..." isn't really one, as you may want to redesign your board in this case, too (for getting the pic-pins wasted for the seperate data-lines free...). Well, the price for the mux (1.70EUR - single part @ Digikey) is the only advantage of this "strange" mode... Smile

    Greetings,
    Stefan
    #13
    Ian.M
    Super Member
    • Total Posts : 13114
    • Reward points : 0
    • Joined: 2009/07/23 07:02:40
    • Location: UK
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 12:00:06 (permalink)
    0
    For any small number of units (e.g. less than 100) the reduction in code complexity by using a multiplexer should save enough days of development to cover the cost of the additional chip.  If you add  tracks  under and around the multiplexer to bypass it and cut them (drill through?) if the multiplexer is fitted you are covered if you wish to use individually addreesed sensors later.

    Stefan covered the simultanious access stuff  nicely.  It relies on them all having exactly the same read sequence with only the data returned being different.  Clock the same command out to all of them and take the byte returned on the port for each bit of their response and shift it one bit at a time into different receive data variables, one for each sensor.  Obviously it helps if the data lines are connected to consecutive port bits either starting at bit 0 or bit 7.
    #14
    markp
    Super Member
    • Total Posts : 397
    • Reward points : 0
    • Joined: 2006/01/26 13:54:56
    • Location: 0
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 12:42:50 (permalink)
    0
    ORIGINAL: Ian.M
    Stefan covered the simultanious access stuff  nicely.  It relies on them all having exactly the same read sequence with only the data returned being different.  Clock the same command out to all of them and take the byte returned on the port for each bit of their response and shift it one bit at a time into different receive data variables, one for each sensor.  Obviously it helps if the data lines are connected to consecutive port bits either starting at bit 0 or bit 7.

     
    You get into problems there if one of the slave sends a NAK bacause it is busy for some reason. Would you repeat the whole thing even for those slaves that were ready and who will now see another cycle? The cycle itself may be destructive, e.g. auto-increment registers. Clock stretching would still be OK I think. It is best to have separate cycle access for each slave IMO then you can't go wrong.
     
    Mark.
    #15
    Ian.M
    Super Member
    • Total Posts : 13114
    • Reward points : 0
    • Joined: 2009/07/23 07:02:40
    • Location: UK
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 13:28:35 (permalink)
    0
    Send a STOP to the device that NAKed then float and mask out that data line till the data transfers from the others are done.  You can then take whatever corrective action is required.  I still don't like the level of cheese-paring in the design though.

    #16
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    RE: Sharing I2C bus 2010/01/31 16:03:04 (permalink)
    0
    Ah ok Stefan!! But I assumed that Ian meant "using only 2 wires" ... and I was wondering which could've been the "magic" !!

    thank you everybody. We'll probably make room for a hub, and a chance to skip it if not needed.

    GENOVA :D :D ! GODO
    #17
    Jump to:
    © 2018 APG vNext Commercial Version 4.5