On Jan 23, 2008 2:04 PM, Andy Green <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi folks - > > This isn't our current problem but a something I noticed that could make > different mischief if not watched out for. > > (Chip data is here: > http://www.st.com/stonline/products/literature/ds/12726.pdf ) > > The chip supports I2C and SPI on the same pins, they use the SPI CS to > select I2C mode when it is disabled for SPI. > > We wired two chips up on the same SPI interface and used the CS pin to > enable one or the other. The problem is that the "disabled" one is not > unexpectedly NOT disabled, it is in I2C mode. > > It's possible, but unlikely, to trash the registers in the "disabled" > one when you talk to the other, depending on what data you are sending > out, because it is interpreting what you send on SPI as valid I2C data. > > Maybe it's a bit more possible to get the "disabled" one addressed on > I2C accidentally and in "read" mode, where it starts driving the same > SPI data line the other chip or the CPU is driving. > > There's no workaround by talking to them in I2C instead either because > they both have the same SCL and SDA hooked up and share the same I2C > address. If we use CS to push one into SPI mode it's the same kind of > problem that we started with. > > Not the problem we are seeing at the moment, nor is it likely to make > much trouble, but still a bit of a funny.
Funny. I wonder why the SDO pin wasn't used to tell them apart in I²C mode. regards Philipp
