I2C multiple addresses for slave

I am trying to implement a slave I2C interface using
a PIC16F876 but it can only accept a single address
as a slave, I have looked at the Atmega 168 and it
has an address mask register (TWAM) but I am
unsure if this will allow the device to respond to
more than one slave address.
Anyone with any knowledge on multiple addressing
I2C in slave mode?

Phil

"Phil" <please@sendmejunkmail.com> wrote in
news:c3a9gi$fi5$1@titan.btinternet.com: 

> I am trying to implement a slave I2C interface using
> a PIC16F876 but it can only accept a single address
> as a slave, I have looked at the Atmega 168 and it
> has an address mask register (TWAM) but I am
> unsure if this will allow the device to respond to
> more than one slave address.
> Anyone with any knowledge on multiple addressing
> I2C in slave mode?

Hmm. I suppose you could enable the general call address on the slave and
then have the master(s) use the GA for all communications. Then each of
your slaves would have to interrogate your own protocol addressing scheme.
Yuk. Basically, I2C was not designed for multicast operation. You get
broadcast or unicast. I have never seen the Atmega TWAM in my I2C travels
so I don't think I'd depend on such a feature if it were up to me. 

-- 
- Mark ->
--

"Mark A. Odell" <nospam@embeddedfw.com> wrote in message
news:Xns94AFA2730293CopyrightMarkOdell@130.133.1.4...
> "Phil" <please@sendmejunkmail.com> wrote in
> news:c3a9gi$fi5$1@titan.btinternet.com:
>
> > I am trying to implement a slave I2C interface using
> > a PIC16F876 but it can only accept a single address
> > as a slave, I have looked at the Atmega 168 and it
> > has an address mask register (TWAM) but I am
> > unsure if this will allow the device to respond to
> > more than one slave address.
> > Anyone with any knowledge on multiple addressing
> > I2C in slave mode?
>
> Hmm. I suppose you could enable the general call address on the slave and
> then have the master(s) use the GA for all communications. Then each of
> your slaves would have to interrogate your own protocol addressing scheme.
> Yuk. Basically, I2C was not designed for multicast operation. You get
> broadcast or unicast. I have never seen the Atmega TWAM in my I2C travels
> so I don't think I'd depend on such a feature if it were up to me.
>
> -- 
> - Mark ->

The Atmega 48 data sheet has:
"The TWAMR can be loaded with a 7-bit Salve (sic)
address mask. Each of the bits in the TWAMR can
mask (disable) the corresponding address bits in the
TWI Address Register (TWAR). If the mask bit is set
to one then the address match logic ignores the compare
between the incoming address bit and the corresponding
bit in TWAR."

I read this as if the mask reg is say 0000011x and
the TWAR is 0000100x then a match will occur
for slave addresses 00001xx will generate a match.

Phil

"Phil" <please@sendmejunkmail.com> wrote in
news:c3an38$6gh$1@hercules.btinternet.com: 

> The Atmega 48 data sheet has:
> "The TWAMR can be loaded with a 7-bit Salve (sic)
> address mask. Each of the bits in the TWAMR can
> mask (disable) the corresponding address bits in the
> TWI Address Register (TWAR). If the mask bit is set
> to one then the address match logic ignores the compare
> between the incoming address bit and the corresponding
> bit in TWAR."
> 
> I read this as if the mask reg is say 0000011x and
> the TWAR is 0000100x then a match will occur
> for slave addresses 00001xx will generate a match.

That may well be, my point is that I don't believe this (multicast) is
possible with the PIC's I2C implementation. It's not possible with the
Mot. 855T, the IBM 405GPr, the 8051-based I2C peripherals I've worked
with, etc. If the Atmega can do this and an you require multicast
addressing then you must ditch the PIC and use Atmegas. Be aware that this
is not a typical I2C feature. 

-- 
- Mark ->
--

"Mark A. Odell" <nospam@embeddedfw.com> wrote in message
news:Xns94B05CC399885CopyrightMarkOdell@130.133.1.4...
> "Phil" <please@sendmejunkmail.com> wrote in
> news:c3an38$6gh$1@hercules.btinternet.com:
>
> > The Atmega 48 data sheet has:
> > "The TWAMR can be loaded with a 7-bit Salve (sic)
> > address mask. Each of the bits in the TWAMR can
> > mask (disable) the corresponding address bits in the
> > TWI Address Register (TWAR). If the mask bit is set
> > to one then the address match logic ignores the compare
> > between the incoming address bit and the corresponding
> > bit in TWAR."
> >
> > I read this as if the mask reg is say 0000011x and
> > the TWAR is 0000100x then a match will occur
> > for slave addresses 00001xx will generate a match.
>
> That may well be, my point is that I don't believe this (multicast) is
> possible with the PIC's I2C implementation. It's not possible with the
> Mot. 855T, the IBM 405GPr, the 8051-based I2C peripherals I've worked
> with, etc. If the Atmega can do this and an you require multicast
> addressing then you must ditch the PIC and use Atmegas. Be aware that this
> is not a typical I2C feature.

I had a talk with the ATMEL apps eng and he said that this
is indeed the case with the ATmega 48/88/168, I did not
want to use a PIC in the first place but the customer wanted
me to use a PIC. Anyway it seems that the new ATMEL device
is a step forward and maybe others will have a need for such
a feature, obviously ATMEL thinks so.

Phil

Phil wrote:

> "Mark A. Odell" <nospam@embeddedfw.com> wrote in message
<snip>>That may well be, my point is that I don't believe this 
(multicast) is
>>possible with the PIC's I2C implementation. It's not possible with the
>>Mot. 855T, the IBM 405GPr, the 8051-based I2C peripherals I've worked
>>with, etc. If the Atmega can do this and an you require multicast
>>addressing then you must ditch the PIC and use Atmegas. Be aware that this
>>is not a typical I2C feature.
> 
> 
> I had a talk with the ATMEL apps eng and he said that this
> is indeed the case with the ATmega 48/88/168, I did not
> want to use a PIC in the first place but the customer wanted
> me to use a PIC. Anyway it seems that the new ATMEL device
> is a step forward and maybe others will have a need for such
> a feature, obviously ATMEL thinks so.

Cygnal support the General Call feature of i2c, where a device
can respond to two addresses, its own, and the General Call addr.

i2c expects a single slave to control the ACK, so multiple ACKs
from many slaves could cause problems.

  I could see that an Addr mask scheme ( as in CAN, and the
SADEN in multi-drop UART systems ) would allow a small uC
to 'emulate' common serial EE memories, which do have
multiple slave options.
  To operate fully, this should be also able to check WHICH
of the possible addresses was used, and hat needs smarter
silicon...
-jg

>i2c expects a single slave to control the ACK, so multiple ACKs
>from many slaves could cause problems.

Would it be a problem? I had thought I2C could have several devices pull the
lines low at the same time with no ill effects and that a slave could hold SCL
low while it figures out if it wants to ACK or not. An ACK is also low. I would
think that it wouldn't be a problem with several slaves trying to ACK as the
slowest one would determine when the actual ACK clock would happen. And as long
as one slave ACK'd, that would be good enough. I don't know, I'm just
wondering.

Gary Kato wrote:
>>i2c expects a single slave to control the ACK, so multiple ACKs
> 
>>from many slaves could cause problems.
> 
> Would it be a problem? I had thought I2C could have several devices pull the
> lines low at the same time with no ill effects and that a slave could hold SCL
> low while it figures out if it wants to ACK or not. An ACK is also low. I would
> think that it wouldn't be a problem with several slaves trying to ACK as the
> slowest one would determine when the actual ACK clock would happen. And as long
> as one slave ACK'd, that would be good enough. I don't know, I'm just
> wondering.

  I'd agree that in the simplest silicon, it should simply wire-OR.
However, on many uC, the i2c is a reasonably complex clocked state 
engine, and this may take it into untested realms.
  We have seen race issues in i2c HW with flags between the two clock
domains. My antennae would say 'proceed, but with caution' :)
-jg

"Gary Kato" <garykato@aol.com> wrote in message
news:20040318170603.08983.00001744@mb-m13.aol.com...
> >i2c expects a single slave to control the ACK, so multiple ACKs
> >from many slaves could cause problems.
>
> Would it be a problem? I had thought I2C could have several devices pull
the
> lines low at the same time with no ill effects and that a slave could hold
SCL
> low while it figures out if it wants to ACK or not. An ACK is also low. I
would
> think that it wouldn't be a problem with several slaves trying to ACK as
the
> slowest one would determine when the actual ACK clock would happen. And as
long
> as one slave ACK'd, that would be good enough. I don't know, I'm just
> wondering.
>

You are correct, after all in the General Call all slaves will
ACK the message by pulling the line low.

Phil

> I had a talk with the ATMEL apps eng and he said that this
> is indeed the case with the ATmega 48/88/168, I did not
> want to use a PIC in the first place but the customer wanted
> me to use a PIC. Anyway it seems that the new ATMEL device
> is a step forward and maybe others will have a need for such
> a feature, obviously ATMEL thinks so.
>
> Phil


Put an ATmega48 in front and communicate with PIC using SPI :-)

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.