Quoting Dave Tweed : > PICdude wrote: >> (2) N is a second master, and asks S directly for what it wants and S >> sends it directly to N. M is not involved (nice), but I'd have to >> modify N's code to support multi-master. So far (reading the Philips >> I2C spec) it seems like the multi-master arbitration is not trivial, >> and I'm concerned if M has any more processing capacity for this. Pro >> =3D less I2C traffic. Con =3D complicated. Think option 1 is still >> 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. Yep. Reminds me of CDMA/CD from my college networking class. > If you impose some additional constraints, you can simplify it considerab= ly. > 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 = the > end of one cycle and the beginning of the next, say 10 us. Then, you coul= d > allow N to grab the bus only within, say, 5 us of seeing the end of one o= f > M's cycles. If M sees an I2C "start" that isn't it's own within that wind= ow, > it simply waits until the end of N's cycle before resuming its own activi= ty. > No need to implement bit-by-bit arbitration for simultaneous cycles (or c= lock > stretching). Hmmm... though I'd generally avoid altering standard protocols, this =20 might work well. I don't have much spare time slots on the I2C bus =20 currently, but can speed it up (it's under 10Khz now I believe as it =20 will be used in a noisy environment at a long distance (>10ft)). Will =20 need to figure out some details, but it should be doable. >> 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 th= e > data it needs as it goes by? Nope, the data to M and N will be unique. Though I haven't mentioned it here yet, there may be a need later to =20 add yet another slave (somewhat like N), so I'm leaning towards any =20 system that would allow that to be done easily. There are really only 5 values that can be requested/sent repeatedly =20 (not including control data), so I'm thinking out another option that =20 would involve one request from M to S to send *all* values on the bus. =20 However, S would switch to a master temporarily and broadcast all =20 values (reducing I2C traffic by not sending several requests, and =20 allowing N to use that data also). I need to figure out how M would =20 switch to a slave to get that data, then switch back to a master. Yet another thought is to possibly make S the master, and broadcast =20 all values repeatedly, but also ask M what it needs to control (ie: =20 what parameters in S it needs to change). I need to think through these two options carefully still though. Cheers, -Neil. --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .