MMA7760 unable to be used with MRAA subplatform with latest UPM

[deadprogram]

I am unable to run the mma7760.py sample python code on the Gateway using the Firmata subplatform, even after changing the i2c bus to 512 as follows:

from __future__ import print_function
import time, sys, signal, atexit
from upm import pyupm_mma7660 as upmMMA7660
from mraa import addSubplatform, GENERIC_FIRMATA

def main():
    addSubplatform(GENERIC_FIRMATA, "/dev/ttyACM0")

    # Instantiate an MMA7660 on I2C bus 0 + 512
    myDigitalAccelerometer = upmMMA7660.MMA7660(
                                            512,
                                            upmMMA7660.MMA7660_DEFAULT_I2C_ADDR);
...

Running this code, I receive the following output:

mma7660_read_byte: mraa_i2c_read_byte_data() failed.
Traceback (most recent call last):
  File "mma7660.py", line 76, in <module>
    main()
  File "mma7660.py", line 52, in main
    myDigitalAccelerometer.setModeStandby()
  File "/usr/lib64/python2.7/site-packages/upm/pyupm_mma7660.py", line 388, in setModeStandby
    return _pyupm_mma7660.MMA7660_setModeStandby(self)
RuntimeError: UPM Runtime Error: setModeStandby: mma7660_set_mode_standby() failed

Testing the same hardware/code minus the subplatform parts on an Edison with mraa 1.5.1/upm 1.0.2, and it works... am I doing something else wrong here, or ?

[deadprogram]

Same results with the JS example.

[Propanu]

@deadprogram this may be related to the I2C bus speed on the Arduino 101 being set to standard (100 kHz) instead of fast (400 kHz) which is required for some of the sensors. We are currently investigating this to see if we can provide an updated Firmata sketch binary to use with IMRAA.

[Propanu]

@deadprogram is this still an issue with MRAA 1.6.1 and UPM 1.2.0? There were some improvements done to the way MRAA handles I2C transfers to Firmata subplatforms.

[deadprogram]

I will test @Propanu thanks for the update.

Also, reminder to please make sure that the 01org repos are updated so I can test this on the Gateway.

[deadprogram]

Hi @Propanu I can confirm that this is still an issue with MRAA 1.7.0.

[malikabhi05]

Seeing some very weird things on Firmata:

i2c.readReg(0x07) 2L i2c.readReg(0x07) 2L i2c.readReg(0x07) 0L i2c.readReg(0x07) 1L i2c.readReg(0x07) 1L i2c.readReg(0x07) 0L i2c.readReg(0x07) 1L i2c.readReg(0x07) 1L i2c.readReg(0x07) 2L i2c.readReg(0x07) 1L i2c.readReg(0x07) 1L i2c.readReg(0x07) 1L i2c.readReg(0x07) 0L i2c.readReg(0x07) 2L i2c.readReg(0x07) 0L i2c.readReg(0x07) 1L i2c.readReg(0x07) 1L i2c.readReg(0x07) 1L i2c.readReg(0x07) 2L i2c.readReg(0x07) 2L

These are all reads from the mode register of the sensor. The register [bit 0 is the mode bit to be precise] seems to be oscillating between 0 and 1 (between standby and active mode). Something similar seems to be happening for the sleep register. Firmata seems to be reading these registers incorrectly.

[malikabhi05]

Using mraa_i2c_read_bytes_data() call somehow seems to do the trick for me and gives me the expected values. Tried changing the delay and other things in the firmata implementation in mraa but that didn't make any difference at all.

[malikabhi05]

patched the driver : f37236fa01469050714f89f839a1fac51a824096

[jontrulson]

Hi @malikabhi05, couldn't you have just swapped out the call to mraa_i2c_read_byte_data() with a call to mraa_i2c_read_bytes_data(), but reading just one byte? That would seem to have been a better and cleaner workaround than reading all 11 registers every time on every platform...?

Also, as you are working around a firmata bug, was there an issue for firmata opened up for that so it would get fixed eventually? Should there be a comment in the mma7660_read_byte() indicating that this is a workaround for a firmata (only) bug?

Even better would be to detect that you are on a firmata platform and execute this workaround only for that. Seems a shame to use this hack for every platform when it's only a work-around for one (firmata)...