PICdude wrote:
> (2) N is a second master, and asks S directly for what it wants and S =20
> sends it directly to N.  M is not involved (nice), but I'd have to =20
> modify N's code to support multi-master.  So far (reading the Philips =20
> I2C spec) it seems like the multi-master arbitration is not trivial, =20
> and I'm concerned if M has any more processing capacity for this.  Pro =20
> =3D less I2C traffic.  Con =3D complicated.  Think option 1 is still =20
> better here, and I'd just speed up the I2C data.

The full multi-master specificaton is intended to deal with completely
asynchronous masters, and the possibility that they might start cycles
simultaneously.

If you impose some additional constraints, you can simplify it considerably=
..
For example, suppose M is doing a fairly steady stream of I2C cycles, but
you have enough bandwidth so that you can enforce a minimum time between th=
e
end of one cycle and the beginning of the next, say 10 us. Then, you could
allow N to grab the bus only within, say, 5 us of seeing the end of one of
M's cycles. If M sees an I2C "start" that isn't it's own within that window=
,
it simply waits until the end of N's cycle before resuming its own activity=
..
No need to implement bit-by-bit arbitration for simultaneous cycles (or clo=
ck
stretching).

> Thoughts?  Better ideas?

Is the data that N needs always a subset of what M is getting? How about
implementing N as a completely passive I2C "snooper" that simply grabs the
data it needs as it goes by?

-- Dave Tweed
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.