This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDK15 Invensense MPU9250

Hi, we switched from your competition to your platform. I know you wrote somewhere that you cannot provide examples for every sensor out there. But your Nordic Dev Zone is a bit messy, information cluttered everywhere. And soon, information is also outdated by your own updates.

If we would talk about motion sensors, I know there are like only two manufacturers: Invensense & Bosch.

Your competition has better community and also the owners themselves care more and provide basic examples on everything. I'm not asking you to do so. Just motion sensors, there is not many vendors and you have 50+ similar questions about motion sensors. It would be good, responsible, western EU style behavior, if your management would get some feedback from community managers. If so many people asking about issues or examples. You can have better ROI and save resources here, if you would, by all the years, provide some, even basic example. You have MPU in your documentation, but that does not stand for motion processing unit, it is some memory protection unit instead (only adds to confusion when googling).

We have met on CES at Las Vegas, you ask for some feedback, how to get better than competition. Your competition have better examples of how easy is to use their product. How good is time to market. Here I see only messy forum and customer rant about the same thing again & again and it is more than 1 year.

And before you will send here the unofficial Michael's github, I want to say that it was for SDK14. Not for SDK15. Next it does not use Invensense DMP driver.

I want to use eDMP motion driver by Invensense. Read quaternion (4D vector) and use their pipeline and configuration. Because, unlike Bosch with second ARM coprocessor, Invensense requires to load their driver in your firmware memory, in order to get these data. You can find many examples on Sparkfun, Adafruit, not to mention Arduino community itself. Also other ARM vendors provide at least one example.

I'm not asking you provide examples on every sensor out there. Just, when it comes to market share, there is only Invensense and Bosch with MPUs. That would be quite basic bluetooth beacon example in 2019.

So my question is: can I get SDK15 working with MPU9250 using DMP? On various boards including ESP, NXP, Arduino, it is really a matter of minutes and then companies, your customers, can focus on developing the product and time to market is acceptable. Here with Nordic, my experience so far, is that the community is not exchanging projects as it should and Nordic company is not doing anything to bring more customers on their platform. What took me one day on other platforms, is impossible to accomplis on SDK15.

I think it is start of 2019 and time to rethink this whole community / customer / startup / manufacturers strategy.

Parents Reply Children
  • The include of "... board.h" does not matter for the abstraction.  You pin assignment in the data structure in  your code.  It is not hardcoded.  Look on top of main.  Everything is in the declaration/assignment of config.  Look other examples like blinky, UartPrbsTest.   The examples in EHAL\exemples for instance work in nRF5x, LPC11xx same code only need to change the pin map in the config structure on the top of main.  The same UART code also works in OSX. 

    Here is how the abstraction works.  Lets have 2 interface SPI and I2C and the MPU-9250.

    SPI g_SpiInterf;

    I2C g_I2cInterf;

    AgmMpu9250 g_MotSensor;

    Assuming we already initialized the interfaces

    To Init the MPU to work with SPI

    g_MotSensor.Init(MotCfgData, &g_SpiInterf);

    Want the Mpu to work with I2C instead

    g_MotSensor.Init(MotCfgData, &g_I2cInterf);

    here this is compiled with s140 pin mapped to your board.  I tested it on the Nordic DKUartBleDemo.hex

  • Your hex build behaves exactly like the one I build from NRF52 folder. Discovery works, I see UARTDemo device. But NRF Toolbox cannot connect, because it will not find required service characteristics.

    Now, because NRF5 SDK examples built for Segger Studio works, I suspect my problem will be something with sdk_config.h and some new nrfx directives and the fact I use SDK 15.2. What version you use, please? SDK 15.0 ?

  • For example your nrf52840_xxaa.ld containts FLASH (rx) : ORIGIN = 0x00000, but correct from NRF5 SDK for NRF52840 is FLASH (rx) : ORIGIN = 0x26000. I did also flash softdevice_s140.hex separately in NrfGo Studio.

  • origin 0 when no softdevice is used, and 0x26000 with softdevice.  There are 2 .ld file one with and one without,  Look in nRF52840/src folder

  • Found another bug. If you enable NRF_LOG in sdk_config.h for 52840, this needs to be fixed:

    ARM/Nordic/nRF52840/EHAL/src/nrf_log_backend_uart.c

    #include "uart.h" (does not exist)

    #include "coredev/uart.h" (correct)

    Also a lot of linker problems between EHAL and NRF52840. For example EHAL links against /components/libraries/log, but your UartsBLE NRF52840 example project links agains /components/libraries/experimental_log

Related