>customer problem with MMA8452
Basically when data is read at full speed the MMA8542 is sending back 0's, but
when with a i2c bus pirate, driving the i2c data other than 0 is read.
The user had a scope and could capture pictures of the transfers. In the bus
pirate case there are lots of delay between the read command byte going out and
the data being read.
Looking at the MMA8452 is claims 400KHz operation, but then in the spec says
time low and high on the SCL have to be 4-5 usec. This is more consistent with
100 KHz operation. But even then it seems like there is a requirement to slow
down between register address and data. Its hard to know how slow it needs to
be as they don't spec it, and it makes the device not truly i2c compatible.
So what to do. You'll have to get in to I2C.bas and besides #define
I2Cspeed100, you will need to insert some delay between bytes in I2CIN in the
while 1 loop. Most likely you'll also have to do this on the I2COUT side as
Many of these non-standard devices use a 8 bit slow micro to implement the i2c
and they just can't keep up with i2c hardware or a fast bit-banged cpu.
We've used a number of i2c devices running at 400 KHz, including my new favorite
DAC the MCP4725. In the past we also used a number of serial EEPROMs running at
The same occurs on the SPI side, only worse. SPI is not so much of a standard
as it implies CS (sometimes), SCK, MOSI, and MISO (sometimes). In some cases
they can run at full speed. But in others they can't, for instance an ADC
LTC1598 uses the SCK to drive the A/D clock so it needs to run 100 KHz or
Welcome to the world of "non-standard" devices. This is a good reason why we
pulled the built in routines out of the BASIC firmware and put them in
open-source libraries. It gives you the opportunity to adapt.
Questions on control of serial busses
1 post • Page 1 of 1