View previous topic :: View next topic |
Author |
Message |
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
Common SCL for several I2C busses |
Posted: Wed Mar 15, 2006 1:14 pm |
|
|
Colleagues,
Since many of you have been using I2C bus for a long time, I just wanted to run this idea by you. Is it possible to have two I2C busses that share a common SCL line? Like this:
Code: |
------
| |
| | SDA1
| RB1|--------------------
| | SDA2
| RB2|--------------------
| | SCL - common clock
| RB3|--------------------
| |
------
Master for 2 I2C busses
Pull-ups and slave devices not shown
|
Of course, PIC’s I2C hardware will not support it, but I could write custom bit-banging routines.
Nick |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Wed Mar 15, 2006 1:51 pm |
|
|
I don't see an issue with it. When bus 1 is active, the devices on bus 2 shouldn't repond at all since they won't see any valid start or stop conditions.
Now that I think of it, I'm not sure how the slave devices will respond to a clock toggling but the data line staying high (I assume). You know for a fact that the slaves will ignore data that's not meant for them. If the data line on the inactive bus idles high, that equates to an address of 0xff - and you'll only have problems if one of your slaves has this address (which I doubt).
To begin, try coding things so that i2c_start() and i2c_stop() put valid start and stop conditions on both busses simultaneously. Then your i2c reads and writes can be directed to one or the other. The inactive bus will then see:
valid start - address 0xff - data 0xff - valid stop
This should pretty much guarantee that the slaves on the inactive bus won't interfere/respond/get screwed up.
If this works, then try sending valid start & stop conditions to only one bus or the other and see if things keep working properly. My first impression is that they will, but I'm not 100% sure. In this case the inactive bus will see the clock toggling but the data line will remain high all the time. I have a sneaking suspicion that the slaves may inadvertently get sent part of a start condition or part of a stop and that may cause some flaky operation when you try to address them.
Hope this makes sense. |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Wed Mar 15, 2006 2:24 pm |
|
|
May I ask why you want to do this? |
|
|
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
|
Posted: Wed Mar 15, 2006 2:34 pm |
|
|
treitmey wrote: | May I ask why you want to do this? |
Some I2C slave chips don't have address select pins, or don't have enough of them. Sometimes I run out of addresses. But if the same slave addresses are on different busses, they will not collide, as long as I'm communicating on one bus at a time. This is the reason for this proposed topolgy.
Other reasons (which are not addressed by my topology) include:
- If you have fast and slow devices, and one wants to utilize the speed of the fast devices, you should have 2 busses: fast and slow.
- If some slaves are powered by+3.3V and some by +5V, one can consider using 2 separate busses with separate SCL and SDA. The first bus would have pull-ups to +3.3V and the second one will have pull-ups to +5V.
Last edited by kender on Thu Mar 16, 2006 4:36 pm; edited 2 times in total |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Wed Mar 15, 2006 3:06 pm |
|
|
I would share the data line and keep the clock separate. |
|
|
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
|
Posted: Wed Mar 15, 2006 3:44 pm |
|
|
Mark wrote: | I would share the data line and keep the clock separate. |
A year or so ago I saw an app note, which described how to share the SDA and multiplex SCL with a multiplexer chip. |
|
|
jds-pic
Joined: 17 Sep 2003 Posts: 205
|
|
|
|