Richard Zinn wrote:

> It sounds like I should just go for it.  How bad is it to send a start
> bit, but without following it with a valid command (a command that
> addresses the right chip)?  

This shouldn't do any bad. As long as the device doesn't receive a correct
command, it is supposed to just ignore it.

> Or is the concern that I might get so unlucky as to actually send a valid
> command along with the right address with my SPI communication and screw
> things up on my I2C chip... 

That's exactly my concern. I haven't thought it through completely, but it
seems there are some circumstances where this might be possible. That it
works (or seems to work) in an application is also not necessarily
conclusive, because this is probably an unlikely event and may only happen
very rarely -- or not at all, even if it should be possible.

How easy it is to analyze depends on your SPI devices. If the clock
polarity is such that a start bit can't happen, you are safe. If it is such
that it generates start bits, you may check whether the SPI data you will
receive could create a valid I2C command. It would be easier to analyze if
the SDA pin were multiplexed with the SDO pin, but I think on most if not
all devices it is multiplexed with the SDI pin -- which carries less
predictable bit patterns.

I'm not sure why Bob switches clock and data; it seems to me that this
makes it impossible to use both hardware I2C and hardware SPI. OTOH, as
said before, SPI in firmware is rather simple to implement.

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