CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Common SCL for several I2C busses

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
kender



Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger

Common SCL for several I2C busses
PostPosted: Wed Mar 15, 2006 1:14 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Mar 15, 2006 1:51 pm     Reply with quote

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

View user's profile Send private message Visit poster's website

PostPosted: Wed Mar 15, 2006 2:24 pm     Reply with quote

May I ask why you want to do this?
kender



Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger

PostPosted: Wed Mar 15, 2006 2:34 pm     Reply with quote

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

View user's profile Send private message Send e-mail

PostPosted: Wed Mar 15, 2006 3:06 pm     Reply with quote

I would share the data line and keep the clock separate.
kender



Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger

PostPosted: Wed Mar 15, 2006 3:44 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Mar 16, 2006 7:25 am     Reply with quote

if you can't spare the pins on the PIC to synthesize an additional SW-driven i2c port, use an external i2c switch/mulitplexer, e.g. Philips PCA9546A
http://www.standardics.philips.com/products/pca/pdf/pca9546a.pdf

this device also provides a level-translating function.

lots of variants of the above are listed here:
http://www.standardics.philips.com/products/pca/all/

jds-pic
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group