I2C Questions -- Not In the FAQ

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

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

On 12 Sep 2004 09:03:22 -0700, anthony@zoraptera.com (Anthony Presley)
wrote:
>I have a few questions about the i2c bus which I can't seem to find
>anywhere else.  Any answers would be greatly appreciated.

Hi, I made several I2C bit-banging hardware and software myself, I'll
try to help you here:

>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.

I don't understand you here. Do you want your sensor to be a master?
Normally the main board is the master and the sensor the slave. Or do
you have several main boards? Do you want several masters to scan
alarm sensors?

>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.

I2C messagges contains two fields: the device code (the identification
af the chip) and an address.

Most I2C devices have 3 select lines that give you the possibility to
have 8 different adresses within the same devicecode. Download the
.pdf files from Philips, they explain it clearly. In the I2C message,
the device code and the addresss is given, so you can have 8 devices
with the same device code (the same chips) and still unique
addressing. You do not need a multimaster system for this.

>  - 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?

You do not have to pay any royalties to Philips as far as I know. Why
don't you give Philips in the Netherlands (only 30km from where I
live) a quick call? Or check their website.
But you cannot easily assign a new devicecode to an existing chip, it
is fixed. You can only set addresses as far as the chips support it.
Read the datasheet of the devices you want to use for addressing. Some
chips have more possibilities.

>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.

See the Philips I2C documentation.

>  - Using software-level i2c, how does one assign id's to the sensors
>[I assume in firmware, or in the EEPROM's]?

See above, devicecode and address. The address is usually done with io
lines, but there are other solutions too. And when you make the slave
yourself, you can do what you want.

>  - 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 slave does not control the clock, it can only stretch it.

>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?

See above, the master controls the clock.

If you answer, please send a copy to pieter@hoeben.com as I do not
often read in this group and may miss new questions of you.

Regards, feel free to ask any questions.

Pieter Hoeben
http://www.hoeben.com

Hi,

"Anthony Presley" <anthony@zoraptera.com> schrieb im Newsbeitrag 
news:a55ad738.0409120803.2fa5b6a0@posting.google.com...

> 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.
>

Please be aware that implementing all aspects of a multymaster bus can be a 
tricky and difficult task especially if you bit-bang your signals instead of 
using a hardware device.

> 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,

So the controllers would run in slave mode while the main device is the 
(multy)-master?


> 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

When operating, there is only one master device - the device that sends the 
clock.
As mentioned by other people before there are usually several address 
choices available by setting / clearing certain pins in hardware.


> 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.
>

This is correct.

> 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.

If you run out of luck (i.e. hardware capabilities) it won't work at all.
There are several important tasks to consider in a multymaster environment:
a) You need to keep track of the arbitration i.e. during the addressing 
phase the device writing more zeros (or is slower) wins the arbitration.
This is to assure that no two masters address the bus at a time. For this 
you need to be able to read back the state of the i2c pins.

b) You need to observe the bus to avoid talking during ongoing traffic. (not 
only during address phase)

c) You need to define in your software what needs to be done if arbitration 
is lost or if the bus is busy.

If I were you I would spend a chip select line for each sensor which is 
controlled via a simple i2c io expander like the PCF8574.
Each sensor can implement its slave device which is only activated if its 
corresponding chip select is enabled.
Advantages:
* You get by with a single-master software
* No multiple address assignment issues.
* easy to debug.
* The master operates the io expander and the sensors through the same i2c 
bus - no additional pins are needed.
* easy to extend to more sensors by adding a second io expander.


/Roland

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.
> 

You already got excellent responses. Some additional thoughts:

1. Life on I2C (or TWI, as others call it to avoid lawyers) is
    much simpler for a master, as it controls (mostly) the timing.
    The protocol contains a thing called clock clamping, where a
    slave is able to hold the bus if it's going too fast.

2. For a multi-master bus, a master must be able to function as
    a slave (see above). The mastership transfer includes that
    a proposing master must be able to detect clamping of the
    data line and back off if detected.

3. IMHO, a working slave needs some hardware assistance: the
    time for bus clamping may be too short to be provided for
    in software, if the processor has anything else to do. Maybe
    the minimal hardware is the shift register + clock clamp
    present in the smallest AVRs. A similar thing could be
    constructed from a PLD.

Been there - done that.

HTH

Tauno Voipio
tauno voipio (at) iki fi

On Sunday, in article <10k8v2lotf64c52@corp.supernews.com>
     tim@wescottnospamdesign.com "Tim Wescott" wrote:

>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.
>> 
.....
>> 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?
....

>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.

Alternatively you derive a separate reset line for the PCF8584 and a gated
write signal for that device ONLY when it is selected.

The other problem of the clock is LESS than or EQUAL 12MHz is very important.
Observe the min time from reset and clock cycles to accessing device.

Done both the types of fixes to get around the issue, and did not cause much
problem. Separate RESET can be done by a simple D or RS type at its simplest.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

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.

  You should look for some HW support in Multi-master, and the PCF8584 is
likely to be more expensive than something like a P89LPC916, which
it the smallest (SO16) uC philips show that has both SPI and i2c.
  Not surprisingly, Philips put i2c support into some of their
smaller uC.
  So either add a tiny uC as SPI-i2c, or find one in your favourites
that has i2c in HW.

  There are also some uC designed for Monitor use, that include a
i2c dual port memory scheme, but they tend to have ordinary ADC specs,
and larger packages.

-jg