pokmo

Working with MPU6050 on MSP430

10 posts in this topic

Hi

 

I'm just getting started in working with MSP430 with MPU6050. Is Jeff Rowberg's library the go-to library for interfacing with the MPU6050? Ideally, I'd like to use DMP, but that the i2cdevlib library doesn't seem to have that feature.

 

Does anyone know a good way to work with the MPU6050 (preferably DMP) on MSP430?

 

Any thought appreciated.

 

Thanks

Share this post


Link to post
Share on other sites

I bought a few of these for experimenting. They are quite easy and straight forward to read raw values using plain I2C, but the DMP was a dark art of no manufacturer support. Things might have changed with unofficial progress but knowing the manufacturer was obfuscating a main selling feature was disappointing.

 

Edit: it looks like there has been improvement in the manufacturer documentation and libraries so my information is probably old. :)

Share this post


Link to post
Share on other sites

I bought a few of these for experimenting. They are quite easy and straight forward to read raw values using plain I2C, but the DMP was a dark art of no manufacturer support. Things might have changed with unofficial progress but knowing the manufacturer was obfuscating a main selling feature was disappointing.

 

 

Do you know how I2CDevLibs managed to get DMP working on the Arduino? Since it works on the Arduino, could that somehow be ported to MSP430?

Share this post


Link to post
Share on other sites

Do you know how I2CDevLibs managed to get DMP working on the Arduino? Since it works on the Arduino, could that somehow be ported to MSP430?

On this thread the Invensense documentation is available. You've got me back interested, so thanks, but unfortunately it'll be a little while before I try.

 

http://www.i2cdevlib.com/forums/topic/153-official-dmp-documentation-is-released-by-invensense/page-3

Share this post


Link to post
Share on other sites

I think that the msp430 is a poor choice of host for this type of code. I just took a look at some of the library code and it seems to like to use floating point.  The MSP430 isn't really a good choice for this type of math.  Maybe the msp432 or one of the other cortex-m4 chips would be a better choice.

Share this post


Link to post
Share on other sites

The other problem seems to be its use of dynamic memory. This is also a major limitation of the msp430 chips (assuming you are talking about the g2 series)

 

It seems like the MSP430 implementation is crippled in some way compared to the other platforms. Here it disables some of the DMP functions:

 

https://github.com/jrowberg/i2cdevlib/blob/master/MSP430/MPU6050/MPU6050.cpp#L3042

 

-rick

pokmo and Fmilburn like this

Share this post


Link to post
Share on other sites

@Rickta59 

 

The other problem seems to be its use of dynamic memory. This is also a major limitation of the msp430 chips (assuming you are talking about the g2 series)

 

It seems like the MSP430 implementation is crippled in some way compared to the other platforms. Here it disables some of the DMP functions:

 

https://github.com/jrowberg/i2cdevlib/blob/master/MSP430/MPU6050/MPU6050.cpp#L3042

 

-rick

 

Interesting. Any idea why the Arduino version of those functions couldn't be modified but disabled completely?

Share this post


Link to post
Share on other sites

It depends on which msp430 you are using ... The g2553's only have 512 bytes of ram .. newer msp430s have more ram and could support some dynamic memory

Share this post


Link to post
Share on other sites

Why wouldn't you use an MSP432 for this? It seems like a great fit, and would be a lot more efficient than an arduino or MSP430.

Share this post


Link to post
Share on other sites

Just a discussion point, I think the motivation to pair an MSP430 with an MPU6050 is justified based on the Invensense hype and PR that all the heavy lifting would be handled by the magical DMP onboard coprocessor. In the real world, the gyro and acc data is very noisy and filter and calibration dependent. It's a really useful experiment to play with as it broke some of my theoretical idealism with the reality that sensors are super noisy. Getting the best and fastest possible orientation from this device will be a combination of filtering the raw data and combining data. It really felt like every 6050 was different, so the chances the filtering and IMU combination being optimal in the DMP feels iffy, but I would try and see.

 

My personal recommendation is to fire up a 2452 launchpad with the terrific I2C explorer from this forum and have a play with what you can get back from the sensor documentation. I then modified the I2C explorer to a binary serial connection and did all my tinkering in a java app to get an understanding of the sensor under movement without constantly flashing a device.

tripwire likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now