Re: I2C Questions -- Not In the FAQ
From: Tim Wescott (tim_at_wescottnospamdesign.com)
Date: 09/12/04
- Next message: Spehro Pefhany: "Re: Decoupling caps"
- Previous message: Spehro Pefhany: "Re: Mushroom Cloud Reported Over North Korea"
- In reply to: Anthony Presley: "I2C Questions -- Not In the FAQ"
- Next in thread: Paul Carpenter: "Re: I2C Questions -- Not In the FAQ"
- Reply: Paul Carpenter: "Re: I2C Questions -- Not In the FAQ"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 12 Sep 2004 09:42:04 -0700
Anthony Presley wrote:
> Hi all,
>
> I have a few questions about the i2c bus which I can't seem to find
> anywhere else. Any answers would be greatly appreciated.
>
> We're building a device based on a previous design, from another firm,
> which uses the MSP430F149, which does SPI, but not I2c. The existing
> design uses i2c components on the board, and the software is bit
> banging out the i2c protocol. We want to extend this to allow for
> offboard sensors using I2c. However, we really would prefer to have
> multiple masters where possible, as some of the sensors may be "alarm"
> related. As far as I know, we have a couple of options.
>
> 1. Add a Phillips I2c hardware controller onto the existing design --
> as well as on each of the sensors [which will have their own MSP430's,
> probably the cheapest of the same family]. This would allow us a I2c
> multi-master configuration, based on the hardware design.
> - In this case, how is unique addressing done? IE, we may have six
> of the same sensors on the bus, but want to send data to/from only
> one. I've read conflicting information about unique addressing, and
> whether it is or isn't possible.
> - In this configuration ... if I'm building my own I2c sensors, do I
> have to pay Phillips for a unique address, or can I assign my own?
>
> 2. Switch to an MSP430 which has I2c within the hardware, something
> like the F169. However, this is probably not desired. Similar
> consequences as [1] above.
>
> 3. Continue with the bit-banging in the software. This is probably
> the easiest option for me [I come from a software background].
> However, I'm a little confused how this would work in a multi-master
> configuration.
> - Using software-level i2c, how does one assign id's to the sensors
> [I assume in firmware, or in the EEPROM's]?
> - Using software-level i2c, can you do multi-master i2c? I ask, b/c
> it appears [to me] that the difference between a slave and a master is
> minimal. A slave and a master can both control the clock, from my
> reading, the difference being that the slave cannot initiate the START
> command [which could be done in software].
>
> A last question ... in a multi-master i2c configuration, such as the
> one shown at: http://www.esacademy.com/faq/i2c/general/i2carbit.htm,
> it appears that the clock, which is bi-directional, is not tied
> directly to either master -- ie, it's a 3rd party clock. How is this
> usually done?
>
> Thanks for any help.
>
> --Anthony
1a. The Phillips I2C controller can be a pain to interface to -- it is
supposed to automagically sense the difference between a Motorola
6800-type bus and an Intel bus, but it only works if the _very first
transaction_ is to the I2C controller. We tried using it with a '186
and finally threw up our hands and bit-banged the I2C.
1b. You can do unique addressing. Most I2C EEPROM chips and at least
some ADCs allow you to set some of the address bits in hardware by
strapping pins; I'm not aware enough of the market beyond that to say.
If you want to have six identical boards you may need to have jumpers
for addressing.
1c. Possibly. Not so much for the addresses, but I believe Phillips
holds the patents on I2C. You may be under their radar screen if you're
not building chips (I've even heard it suggested that just not using the
name "I2C" is sufficient). I am _not_ a lawyer, however, so anything
you do in this arena is your sole responsibility.
2. You undoubtedly have other constraints, but I heartily recommend the
new processor.
3a. You assign addresses however you want; just choose what you want to
respond to.
3b. The main difference is that a slave will have to respond to the
clock asynchronously and promptly -- you'll have to make sure that your
software is up to this, and you'll probably need to be able to interrupt
on the I2C clock. Being an I2C slave will put much more of a strain on
your processor (hence my answer to 2).
4. Action on the I2C clock is always initiated by the master, there's
no 3rd-party clock master.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
- Next message: Spehro Pefhany: "Re: Decoupling caps"
- Previous message: Spehro Pefhany: "Re: Mushroom Cloud Reported Over North Korea"
- In reply to: Anthony Presley: "I2C Questions -- Not In the FAQ"
- Next in thread: Paul Carpenter: "Re: I2C Questions -- Not In the FAQ"
- Reply: Paul Carpenter: "Re: I2C Questions -- Not In the FAQ"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|