Sign in

Not a member? | Forgot your Password?



Search Comp.Arch.Embedded



Search tips

Free PDF Downloads

Advanced Linux Programming

What Every Programmer Should Know About Memory

Introduction to Embedded Systems

C++ Tutorial

Embedded Systems - Theory and Design Methodology

Recent Blogs on EmbeddedRelated

April is Oscilloscope Month: In Which We Discover Agilent Offers Us a Happy Deal and a Sad Name
posted by Jason Sachs


Little to no benefit from C based HLS
posted by Christopher Felton


Unit Tests for Embedded Code
posted by Stephen Friederichs


DSPRelated and EmbeddedRelated now on Facebook & I will be at EE Live!
posted by Stephane Boucher


Using a RTLSDR dongle to validate NRF905 configuration
posted by fabien le mentec


Introduction to Microcontrollers

Chapter 1: Beginnings

Chapter 2: Further Beginnings

Chapter 3: Hello World

Chapter 4: More On GPIO

Chapter 5: Interrupts

Chapter 6: More On Interrupts

Chapter 7: Timers

Chapter 8: Adding Some Real-World Hardware

Chapter 9: More Timers and Displays

Chapter 10: Buttons and Bouncing

Chapter 11: Button Matrix & Auto Repeating

Chapter 12: Driving WS2812 RGB LEDs

See Also

ElectronicsDSPFPGA

Find us on Facebook





Discussion Groups | Comp.Arch.Embedded | I2C multiple addresses for slave

There are 10 messages in this thread.

You are currently looking at messages 1 to 10.


So far in April, you have voted 0 times ou of a total of 0 votes by the community.
Please help us clean the archives from unuseful discussion threads by using the voting system! Details here.

I2C multiple addresses for slave - Phil - 2004-03-17 14:38:00

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



_____________________________
 Free pdf download: Advanced Linux Programming.

Re: I2C multiple addresses for slave - Mark A. Odell - 2004-03-17 15:58:00

"Phil" <p...@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 ->
--

_____________________________
 Free pdf download: What Every Programmer Should Know About Memory.

Re: I2C multiple addresses for slave - Phil - 2004-03-17 18:30:00

"Mark A. Odell" <n...@embeddedfw.com> wrote in message
news:Xns94AFA2730293CopyrightMarkOdell@130.133.1.4...
> "Phil" <p...@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




_____________________________
 Free pdf download: Advanced Linux Programming.

Re: I2C multiple addresses for slave - Mark A. Odell - 2004-03-18 09:07:00

"Phil" <p...@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 ->
--

_____________________________
 Free pdf download: Introduction to Embedded Systems.

Re: I2C multiple addresses for slave - Phil - 2004-03-18 15:18:00

"Mark A. Odell" <n...@embeddedfw.com> wrote in message
news:Xns94B05CC399885CopyrightMarkOdell@130.133.1.4...
> "Phil" <p...@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



_____________________________
 Free pdf download: What Every Programmer Should Know About Memory.

Re: I2C multiple addresses for slave - Jim Granville - 2004-03-18 16:15:00

Phil wrote:

> "Mark A. Odell" <n...@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



_____________________________
 Free pdf download: What Every Programmer Should Know About Memory.

Re: I2C multiple addresses for slave - Gary Kato - 2004-03-18 17:06:00

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


_____________________________
 Free pdf download: What Every Programmer Should Know About Memory.

Re: I2C multiple addresses for slave - Jim Granville - 2004-03-18 18:09:00

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



_____________________________
 Free pdf download: Advanced Linux Programming.

Re: I2C multiple addresses for slave - Phil - 2004-03-19 08:08:00

"Gary Kato" <g...@aol.com> wrote in message
news:2...@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



_____________________________
 Free pdf download: Introduction to Embedded Systems.

Re: I2C multiple addresses for slave - Ulf Samuelsson - 2004-03-19 11:29:00

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



_____________________________
 Free pdf download: Advanced Linux Programming.