> I read what Clive wrote, too, and that gives me another idea.
> (BTW this internet brainstorming is exactly what this list is best
> at!)

Often what the net is best at... :)

> Have all the slaves set their address to the general call address.
> Have the first byte of the message be a slave address.  If its the
> all-call address again, then its a broadcas message, and the rest of
> the data is up to you.

This makes sense, my protocol had something simliar whereby the contents of
any broadcast could be selectively attended to or ignored depending on some
scoping bits...

> You still have to deal with a mode switch message to be able to read
> from the slaves (slave transmit), because you must have only one slave
> see its address if its going to drive SDA back to the master.

I thought about this for a while yesterday, and the best approach I came up
with for the slave transmit (master read) side was to:
- have two modes defined, beCommon and beUnique.
- slaves set their I2C address to the pre-defined Common address, or a
unqiue address, according to their mode.
- Default mode is beCommon.  Reset slaves automatically beCommon.
- broadcasts are sent to the common address
- one special broadcast is "AllSlavesBeUnqiue", which all listeners are
required to obey by switching their address to their unique address
- I can now address N slaves directly, at the end of each section I can
individually instruct them (perhaps) to beUnique again.
- unaddressed slaves time out after N ms to return to beCommon
- N for the timeout is intentionally set short, perhaps about the length of
time of a single master-read slave trasnmit session.  If the master wishes
to address multiple devices, it must re-issue the beUnique command.  This
should keep slaves from missing broadcasts, at the cost of a high rate of
reissuance of the beUnique command

This is pretty much the approach you suggested, except

> > Would you care to elaborate on your 10-bit addressing approach?
> Well, I was thinking you could use one of the two MSBs in the first
> byte of the 10 bit address to flag a unique or all-call mode message.
> You cheat by "peeking" at the MSBs before updating the SSPADD for the
> LSBs.

Heh.  The catch here is my goal (being lazy) is to rely on the automatic
address matching of the 16c6x slave mode hardware.  I *think* it's the case
that in 10 bit mode I will always be interrupted (assuming their enabled) in
order to load the LSB of the address in software, so if I can live with
that, your approach should work fine; though I believe there is some
complexity similar to in the beUnqiue/beCommon approach (e.g., each slave
must decide to load a unqiue, or the common, address, each time it is
interrupted...).

Have to do some thinking about which approach is best... my instinct is that
the 10 bit approach might be better since it doesn't rely on timeouts and
the bus blackouts that implies...

Thanks again for the wisdom!  It's great to have the Group Mind Voice of
Sanity out there... :)
Aaron
------------
Aaron Thieme
Product Engineer
SP Controls, Inc.
www.spcontrols.com
aaron@spcontrols.com
(415) 642-2600 x101

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu