Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using MPU9250 with nRF52 SDK and 52832 part

I want to use the MPU9250 driver found in the Thingy SDK in my nRF52 project.  I am using GCC 7.2 Arm/Eclipse as the development environment.  The driver source file inv_mpu_dmp_motion_driver.c from the Thingy distribution includes thingy_config.h which comes from project/pca20020_s132/config/thingy_config.h.

My project is using pca10040 however.

I am reluctant to modify the inv_mpu_dmp_motion_driver.c to target my board as I would rather not have to port this on future releases.

Is there support the MPU9250 driver in the nRF52 SDK upcoming or planned, or should I just integrate my board definitions with a modified version of the source from the Thingy SDK?

Parents
  • I looked over the sample code provided, but did not see the equivalent code such as drv_mpu9250 and drv_motion from the Thingy project.  We are trying to decide whether the use the SDK13 on which the Thingy was built to take advantage of testing that has been done with this code, or to port this code to be compatible with a build based on SDK14.2

    Is there a recommendation regarding doing this port in terms of what sort of risk we are taking, and what sort of support would be available if we run into problems?

  • Kerry, 

    I am going through this exact problem. I am using Keil for developing and wwas hoping to use the MPU9250 driver with pca10040. Did you resolve your questions? Any pointers?

  • I ended up pulling some code from the Thingy distribution in my source code base and making some modifications to the source and header so it could build.  The modifications were to get around the assumptions about the pca10040 made in the Thingy code so I could build against a project that is using the pca10032.

    The net result is a few modules pulled from the Thingy code that have modifications (inv_mpu.c, inv_mpu_dmp_motion_driver.c, drv_mpu_9250, and a few others) that will have to be reviewed on new releases of SDKnRF52 or Thingy code base.  It is not ideal, but is manageable.

Reply
  • I ended up pulling some code from the Thingy distribution in my source code base and making some modifications to the source and header so it could build.  The modifications were to get around the assumptions about the pca10040 made in the Thingy code so I could build against a project that is using the pca10032.

    The net result is a few modules pulled from the Thingy code that have modifications (inv_mpu.c, inv_mpu_dmp_motion_driver.c, drv_mpu_9250, and a few others) that will have to be reviewed on new releases of SDKnRF52 or Thingy code base.  It is not ideal, but is manageable.

Children
Related