Recommended Posts

I had to make few changes in defines in dmp code, and the provided CalLib, and now it compiles for MSP430G2553, MSP430F5xx, Stellaris Launchpad, and the Tiva-C series (TM4C123) launchpad. CalLib writes to either flash or eeprom depending on architecture.

It has failed for MSP430G2553, due to code size. It compiles for MSP430F5xx although I dont have a board yet to test. I have not tested the stellaris launchpad but I suspect it works, it does WORK on the Tiva-C series launchpad.

Here is the picture of the setup:

On one side I have an arduino nano v3 connected to a MPU9150 module (The cheap GY 9150) and on the other side I have a Tiva-C series launchpad with a sensorhub booster pack. (that contains a MPU9150 as well) and I have hooked up a usbee logic analyzer to i2c (sda, scl) of both mcus

For some reason, it is running slow on the TM4C123 then the arduino. It is supposed to work much faster on the Tiva-C launchpad, but on the contrary it does not. I measured mpu.read() times, and on Energia it wont go less then 50ms, where on arduino I have tested up to 200hz sensor read rates with no problem.

Here are two screenshots from the logic analyzer:

The top two signals are from arduino sda scl, the bottom is the sda(3) scl(3) of the Tiva-C

The MPU9150 is configured to update at 20Hz for both systems. however the i2c bus activity seems quite different.

I am thinking there might be a problem with the i2c speed on Energia, or that it works different.

Share this post

Link to post

Share on other sites

I've tested your code by hooking up a 9150 module (similar to the one you connected to the Nano) to Tiva C. I had to add Wire.setModule(1) to the setup function of the Energia9150.ino file and then it worked, but as you said quite slowly.

In the energia-0101E0012/hardware/lm4f/libraries/Wire/Wire.cpp file the TwoWire::getRxData and TwoWire::sendTxData both have a delay of 1ms build in. This is probably the cause of the delay you are seeing in the SCL of the Tiva. Moreover, the TwoWire::begin method limits the I2C speed to 100kbps.

I've tested your code also with a modified Wire.cpp file, forcing the speed to 400kbps and removing the delay(1) statements from the getRxData and sendTxData methods. This improved speed a lot, but wasn't stable (communictation with the module stopped at random times). To get it stable I had to add 10micro second delays (delayMicroseconds(10)) to the getRxData and sendTxData methods instead of the delay(1). With this change I could increase the MPU_UPDATA_RATE to 200 and the MAG_UPDATE_RATE to 100, resulting in an average sample time of less then 6ms.

Share this post

Link to post

Share on other sites

I mistake I did at the beginning was to think that euler angles were YPR.

I got quarternions, and sent them over serial with the mpu6050 processing example. You give it quarternions, and it will rotate the little plane by these metrics.

I have used for the visualization m_fusedQuaternion[4]

Also, on the boosterpack there is a design error. You have to unsolder 2 resistor from launcpad if you are using stellaris or tiva-c. basically, they shunted the i2c port to some other pins, in order to have backward pin compatibility, and you should also search for that and make sure your i2c bus is working as it should. Having i2c pins shunted to other mcu pins is not the best practice. It caused glitches and compass errors.

Are you also checking error codes from compass? Sometimes compass might fail to init, or dmp code might not load correctly, or work glitchy. (all because of those resistors)

Also what speed did you try at? You can try at different speeds and plot the results in order to gain more insight. Also, did you check compass calibration? When compass is calibrated, it works perfectly in 200hz.