I2C multiple addresses for slave

Started by Phil March 17, 2004
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.