Any update on Sensor Fusion library 7.0?

[haizhouli]

Hey Mike,

You mentioned the new 7.0 is under the development and will support the KSDK? Any update on the new release? I am about to begin a new project with fusion sensor and KSDK.

Thanks a lot!

Haizhou

[michaelestanley]

Yes, that's the one.

[a8Chcx]

Hi Mike,

After I remove Toolbox for V5.00, I can install the new one.

Just want to confirm: The new version: V6.00 built on Aug.3, 2016?

Thanks,

Christie

[a8Chcx]

Hi Mike,

I am trying to install Fusion tool kit on Windows 7. When I download it and it dive me error "The publisher of Sensor-Fusion-V7-Setup.msi couldn't be verified."

Could you tell me how to fix it?

And Do I need to remove the toolkit for fusion v5?

Thanks,

Christie

[michaelestanley]

Christie, I do recommend that you remove the old Toolbox before installing the new.  That is independent of the message you are seeing, which you can simply ignore (run it anyway).

Mike

[michaelestanley]

Version 7.00 of the sensor fusion library is available as of this morning at kex.nxp.com.  Select the "Build an SDK" button, then "New Configuration".  Choose either FRDM-K64F or FRDM-K22F from the Boards->Kinetis pulldown menu.  Make sure you check both "ISSDK" and "FreeRTOS" checkboxes when creating your KSDK configuration.  Follow the instructions from there.

As noted in prior postings in this space, Version 7.00 is a major change from Version 5.00.  That release will continue to be available at nxp.com/sensorfusion.  Later today there will be a new version of the Sensor Fusion Toolbox for Windows posted to that web page as well.  You will need that for use with the Version 7.00 library.  Magnetic packet formats have changed from 5.00, and the new GUI has added features for precision trim of your accelerometer.

The user manual for 7.00 is much expanded over prior releases.  It also includes as appendices a number of my more popular blog postings on orientation and magnetic calibration topics.

Mike

[nirvanauscn]

Hi Mike, it seems the example code all depends on the shield development boards now.

Will NXP introduce examples w/o using shields (i.e., for K22F, using onboard's FXOS8700 only), same as in v5?

Thanks

[michaelestanley]

Generally we'll be relying on fewer example projects, but perhaps more explanations in this space and in NXP blogs.

It's actually really easy to convert one of the KSDK examples to use a sensor on the base board.  If you look at your main() function, you'll see there are really only two things you need to change.

1. The definition of I2Cdrv right at the top of main().  If you use your IDE to find the definition of I2C_S_DRIVER_BLOCKING, you'll go back to a definition in issdk_hal.h.  Follow that value back to an I2C port defined in the frdm_k64f.h or frdm_k22f (depending on your project).  You'll find the I2C bus for the base board elsewhere in the same file.  Change I2Cdrv to point to that.
2. In the appropriate installSensor function in main(), change the I2C address to the address for the sensor(s) on your base board.

That should do it.  We tried to take an object oriented approach for the top level functions in V7.00.  If you think about it, for your scenerio, you wanted to change the I2C bus and device address.  Those correspond directly to the two changes above.

Regards,

Mike

[marks]

Hi Mike,

I was hoping there would be a bare-metal option as well but did not see one. If I don't select any RTOS then there is no sensorfusion directory created in SDK_2.0_FRDM-K22F\boards\frdmk22f_agm01\issdk_examples\algorithms (only see pedometer). Will there be a bare-metal option? Or am I missing something?

Thanks!

Mark

[michaelestanley]

Mark,

Check for a new topic in about ten minutes.  I got you covered.

Mike

[michaelestanley]

Haizhou,

Thanks for checking in.  It has slipped a few weeks.  I'm told the new date is now early August.  As noted in my prior post, we're being integrated into the Kinetis Expert ecosystem.  The first release in this environment will support FRDM-K64F and FRDM-K22F.  The fusion code itself is platform independent, but relies on SPI/I2C access libraries that have only been tested for those two platforms to date.  So the sensor fusion will only show up as an option for those two boards in KEX.

I'm going to post a preview of the user guide, so you and others can see what is coming.  Feedback is most welcome.

Mike

[marks]

Hi Mike, Looking forward to SF 7.0! Some neat new features! Few questions:

Q1. Does the SPI work with the FRDM-STBC-AGM01? I ask because the data sheet says " FXOS8700CQ does not tri-state the MISO pin when the CS_B pin is deasserted (logic high), which can lead to a bus conflict if multiple slave devices are present on the bus." and the MISO is tied to the MISO pin of the FXAS21002.

Q2. Does both SF 5.0 and 7.0 incorporate the work around for the errata E2: Noise from I 2C/AFE Coupling. Seems like there is no synchronization between when the magnetic data is read and when the conversion takes place internally. Is the data ready interrupt used to initiate an I2C transaction? Or am I missing something?

Q3. Seems like the I2C transactions take a lot of time and that using SPI would be better because the sensor data could be read quickly and the processor could be put in a low power mode much sooner, waiting for the next interrupt. What are your views regarding using SPI vs I2C when using both the FXOS8700 and the FXAS21002 regarding low power and processor throughput optimization?

Thanks!

Mark

[michaelestanley]

Mark,

Good questions.  I'll take them in order:

A1: The FRDM-STBC-AGM01 is designed to use the parts in I2C mode.  So no.

A2: No they don't implement the workaround.  And you are not missing anything.  Since we can't control what other sensors/traffic are on the I2C bus (any of which could also trigger the issue), we just take the hit.  We might be able to squeeze a bit of improvement at the driver level by simply rejecting outlier samples when we oversample (ex: keep most consistent 3 of 4 FIFO samples).  I haven't implemented that function at this point.

A3: I agree SPI is more energy efficient, but at the cost of a slightly more complicated PCB.  When testing 7.0 power options, the I2C pullup resistors quickly become the limiting item when it comes to cutting power.

FYI, I expect you to have access to 7.00 via kex.nxp.com for K64F and K22F this week - most likely tomorrow or Thursday.  Make sure you check the ISSDK option in the KSDK builder.

Mike

[marks]

Hi Mike, Thanks for the quick response!

Is there an eval board that supports the SPI interface when using both the FXOS8700 and the FXAS21002? It would be nice to start with known good hardware and firmware if our customer decides to try the SPI path.

Best regards,

Mark

[krithisuryanara]

Hi Mark,

All our eval boards are I2C configured by default, but the eval board BRKT-STBC-AGM01 (including FXAS21002 and FXOS8700) can be converted to SPI mode by following the below app note.

http://cache.nxp.com/files/analog/doc/app_note/AN5167.pdf?pspll=1

Regards,
Krithi

[haizhouli]

Hey Mike,

Thanks for the update! The preview and the user guide are very helpful! Thanks!

Haizhou