Memory footprint reductions and tweaks for AVR chips

[zrecore]

Hi Mike!

I'm back again, this time with a few more optimizations to the FreeIMU library!

In libraries/AP_Filter/Butter.h, I had to remove the following condition checks in order to get Arduino 1.6.7 to compile (now with gnu++11 or c++11 support?)

#if defined(__AVR__) || defined(__ARDUINO_X86__) || defined(__SAM3X8E__)
...

...as the compiler seems to complain about the lack of constexpr

In libraries/AP_Filter/MovingAvarageFilter.cpp I found a for() loop that zero-fills an array... Swapping that out for memset() saves us a few more bytes, and does the exact same thing (I think). Had to include <stdlib.h> in the cpp file, and "Arduino.h" in the header file.

Also found a zero-fill attempt using a for-loop in libraries/AP_Filter/RunningAverage.cpp. I've swapped that out for a memset() call. I am a bit new to C, so I would like to request extra eyes on this stuff (noticed the for-loop variable was an int, not uint8_t or the like...hopefully I called memset() with the correct values)

I've updated libraries/FreeIMU/FreeIMU.cpp as well. Defining EXCLUDE_ICOMPASS will now make the 9th value (iheading?) unavailable, allowing the exclusion of <iCompass.h> ...There's also a few attempts at swapping out the for-loop variables (int to uint8_t) ...again, new to C, maybe this is flat out wrong.

The new IMUduino (version 2.0) will now use the MPU-9250 instead of the MPU-6050 + HMC5883L. The MS561101-BA03 is still included.

The FREEIMU_DEVELOPER define is now set to "FreeIMU Community". Dunno what the most appropriate value here would be. I want to keep attribution to Fabio's work, but folks looking for info need to meet with the currently active maintainers of the FreeIMU. (Suggestions?)

Finally, I've attempted to comment out some debug related stuff in libraries/MPU60X0/MPU60X0.h ...since on an AVR w/ limited flash storage, I need to squeeze every byte I can get.

With all these optimizations, I am able to call FreeIMU::getRawValues() and print them to the Serial console. I am submitted a fork request (Do not merge without reviewing very carefully, please). My example sketch is at femtoduino/imuduino-btle (master) inside the "Arduino/libraries/IMUduino/examples/IMUduino2.0_FreeIMU_Updates" sketch folder.

[zrecore]

imuduino2.0_getrawvalues.dump.txt I've attached Serial Window dump of the "IMUduino2.0_FreeIMU_Updates" sketch.

[zrecore]

Here's a YouTube video of it in action https://youtu.be/rj-_gQ3ThhA

[mjs513]

Hi Alex - welcome back. I will definetly take a look as soon as i finish another project I am working on, another day or two.

Have you thought of moving away from the atmega32u4 and going with a different chip to support additional memory? From what I saw in my previous experiments the BTE library takes alot of memory and when you add in the pressure sensor it it even worse. Raw values are nice but the power of library is in the processing of the raw values.

Mike

[zrecore]

Hi Mike,

Yes, I am tempting to work w/ the Arduino Developer community on the Arduino Zero bootloader for the smaller SAM D21 chips (ATSAMD21E18A and the like). Still in process, though. I'm rather new to all this.

In any case, I figured at least some of the changes in the pull request should be made available for review (use of memset() instead of for-loop for zero-fills)

Some folks may simply be using the IMU + Barometer over serial, and can benefit from these changes (HC-05 modules can be hooked up to Serial, so no extra library should be necessary)

I hope to keep the FreeIMU library AVR friendly until Arduino on ARM (SAM D21) becomes more popular than the Arduino UNO among makers. On Jan 18, 2016 6:58 AM, "Mike S" notifications@github.com wrote:

Hi Alex - welcome back. I will definetly take a look as soon as i finish another project I am working on, another day or two.

Have you thought of moving away from the atmega32u4 and going with a different chip to support additional memory? From what I saw in my previous experiments the BTE library takes alot of memory and when you add in the pressure sensor it it even worse. Raw values are nice but the power of library is in the processing of the raw values.

Mike

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/44#issuecomment-172552223 .

[mjs513]

Hi Alex Oh - i agree several of the changes in the pull request can be made no problem - int to uint8_t, memset (have to get a little bit more familar with this one myself), and fix the ap_filter library. the filter lib works with the teensy 3.1 no problem.

Been using the HC-05 as well as the xbee as well and works like a charm.

Promise I will work on the updates as soon as possible. By the way when you get the D21 incorporated I will probably get a IMUduino myself.

Mike

[mjs513]

Hi Alex, Going to go ahead close this based on my comments against your pull request. If you want you can reopen - your discretion.

Library should be updated this afternoon.

Mike

[zrecore]

I've replied to.the pull request thread, clarifying the iCompass changes and asking a question or two. :-)

[mjs513]

Alex

I ran some tests on the library with the Leonardo, here are the results:

YPR Modified Sketch to return all values, Leonardo size rounded up

6050, 5883, 5611, MARG = 4: 35K MARG = 0, no icompass: 33K MARG = 0, magnetometer disabled: 30.6K

9250, 5611, MARG = 4: 34K MARG = 1: 40K, with magnetometer disabled = 25.2K MARG = 3: 35K MARG = 0: 34K; iCompass commented out 31.7K (Note on a Uno this fits at 29.6K but borderline) Magnetometer Disabled: 24K

9250 with mag disable should fit. With the 6050 a little more work may get it down to where you need it to be. My guess it that if you remove the code for temp calibration it may fit.

Past experience shows that if you do not need heading just disable the magnetometer and you will still get some good results - you may have to tweak the kp, ki, etc a bit.

thoughts? Mike

[zrecore]

@mjs513 Cool, I have checked out the master branch locally, and pulled from your repository. I noticed an issue when attempting to compile in MovingAverageFilter.cpp ...memset wasn't available until I also included Arduino.h in there.

I also noticed I could save a few more bytes by changing iCompass.h::iround() to:

    float iround(float number, float decimal) {
      //int ix;
      //ix = round(number*pow(10, decimal));
      // return float(ix)/pow(10, decimal);
      return float(round(number*pow(10, decimal)))/pow(10, decimal);
    }

..Want me to submit a pull request for this?

[mjs513]

Go for it. :)

Mike On Jan 21, 2016 2:40 PM, "Alex Albino" notifications@github.com wrote:

@mjs513 https://github.com/mjs513 Cool, I have checked out the master branch locally, and pulled from your repository. I noticed an issue when attempting to compile in MovingAverageFilter.cpp ...memset wasn't available until I also included Arduino.h in there.

I also noticed I could save a few more bytes by changing iCompass.h::iround() to:

float iround(float number, float decimal) {
  //int ix;
  //ix = round(number*pow(10, decimal));
  // return float(ix)/pow(10, decimal);
  return float(round(number*pow(10, decimal)))/pow(10, decimal);
}

..Want me to submit a pull request for this?

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/44#issuecomment-173685852 .

[zrecore]

...Ok, noticed that even if my sketch only uses 68% of memory, the Arduino IDE warns me of potential instability due to low memory. We can just close this ticket, I am going to move on to ARM based designs and no longer attempt to fit the FreeIMU-Updates + Adafruit nRF8001 routines. IMUduino revisions 1.x will simply keep using the legacy FreeIMU library. :-)

[mjs513]

Yok, but did you test to see if it still runs. May just be the warning.

Mike On Jan 21, 2016 3:28 PM, "Alex Albino" notifications@github.com wrote:

...Ok, noticed that even if my sketch only uses 68% of memory, the Arduino IDE warns me of potential instability due to low memory. We can just close this ticket, I am going to move on to ARM based designs and no longer attempt to fit the FreeIMU-Updates + Adafruit nRF8001 routines. IMUduino revisions 1.x will simply keep using the legacy FreeIMU library. :-)

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/44#issuecomment-173698586 .

[zrecore]

@mjs513 I ran it without the Adafruit nRF8001 library, using Serial window output only, and setting MARG to 0, and in a subsequent test, 4 in FreeIMU.h

It works very well...just no nRF8001 BLE capabilities. Folks using AVR chips can still benefit from FreeIMU-Updates + UART bluetooth/wifi modules though (or even a direct serial connection to something else).

[mjs513]

Like you said they can also hook it ip to a hc05 with the imuduino since it still has imu with avr on one small board. Keep me posted on the arm conversion as well as version 2 with the 9250.

Still going play around with it a bit to see how small a foot print i get it too with compromising the library.

By way how much added space the nrf module take up?

Mike On Jan 21, 2016 5:29 PM, "Alex Albino" notifications@github.com wrote:

@mjs513 https://github.com/mjs513 I ran it without the Adafruit nRF8001 library, using Serial window output only, and setting MARG to 0, and in a subsequent test, 4 in FreeIMU.h

It works very well...just no nRF8001 BLE capabilities. Folks using AVR chips can still benefit from FreeIMU-Updates + UART bluetooth/wifi modules though (or even a direct serial connection to something else).

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/44#issuecomment-173735114 .

[zrecore]

@mjs513 The Adafruit nRF8001 library takes up a sizable chunk of memory. I wonder if there is a light weight alternative. I know @sandeepmistry has a library for working w/ some Nordic chips at https://github.com/sandeepmistry/arduino-BLEPeripheral

...I wonder if the nRF8001 can be tasked with reading IMU data (this is a shot in the dark)

[mjs513]

Just checked and lools like it will support the 8001. You should give it a try On Jan 21, 2016 6:46 PM, "Alex Albino" notifications@github.com wrote:

@mjs513 https://github.com/mjs513 The Adafruit nRF8001 library takes up a sizable chunk of memory. I wonder if there is a light weight alternative. I know @sandeepmistry https://github.com/sandeepmistry has a library for working w/ some Nordic chips at https://github.com/sandeepmistry/arduino-BLEPeripheral

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/44#issuecomment-173752246 .

[zrecore]

For future reference: https://github.com/NordicSemiconductor/ble-optiboot I'll see about tying this together and making it work for AVR chips + FreeIMU

[mjs513]

Thanks for the reference. Interesting appeoach. If you use the optiboot but the approach assumes the user has a certain level of expertise to get it compiled in arduino env. Not nit picking just discussing.

The only issue i see with the freeimu library is with the eeprom. Would have to change the base adress. Not a biggie.

Mike On Jan 21, 2016 7:11 PM, "Alex Albino" notifications@github.com wrote:

For future reference: https://github.com/NordicSemiconductor/ble-optiboot I'll see about tying this together and making it work for AVR chips + FreeIMU

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/44#issuecomment-173757109 .

[sandeepmistry]

@mjs513 The Adafruit nRF8001 library takes up a sizable chunk of memory. I wonder if there is a light weight alternative. I know @sandeepmistry has a library for working w/ some Nordic chips at https://github.com/sandeepmistry/arduino-BLEPeripheral

I expect my library to use even more memory at setup time. As it creates the nRF8001 setup messages on the fly, where as the Adafruit lib uses nRFgo to generate the messages externally.

It might take less memory after setup though, only one way to find out though :)

[zrecore]

...As I sit here at 11:50pm, I just realized there must be some way to get DMP functionality from the MPU-9250 (worked w/ the MPU-6050, assuming I can access the INT and FSYNC pins)

I suspect this would drastically reduce the memory footprint, as an AVR chip would no longer need to run AHRS algorithms, etc. Of course, I understand the DMP features were reverse engineered for the MPU-6050...but maybe there's progress on the MPU-9250.

(Guess I'll have to wait 'till morning.)

Thoughts? On Jan 23, 2016 7:51 AM, "Sandeep Mistry" notifications@github.com wrote:

@mjs513 https://github.com/mjs513 The Adafruit nRF8001 library takes up a sizable chunk of memory. I wonder if there is a light weight alternative. I know @sandeepmistry https://github.com/sandeepmistry has a library for working w/ some Nordic chips at https://github.com/sandeepmistry/arduino-BLEPeripheral

I expect my library to use even more memory at setup time. As it creates the nRF8001 setup messages on the fly, where as the Adafruit lib uses nRFgo to generate the messages externally.

It might take less memory after setup though, only one way to find out though :)

— Reply to this email directly or view it on GitHub https://github.com/mjs513/FreeIMU-Updates/issues/44#issuecomment-174195543 .

[mjs513]

.. You could use the Invensense Motion Driver App which is available for download from their developers corner. But remember DMP does not fuse the magnetometer data, equivalent of disabling the magnetometer in the FreeIMU code. You can also check this link: https://developer.mbed.org/users/p3p/code/MPU9150_Example/, https://learn.sparkfun.com/tutorials/mpu-9150-hookup-guide#installing-the-arduino-library

It appears that the 9250 uses the same core dmp as the 6050. The base chip is the 6500 with the AK8963 magnetometer.

Here is couple of other references: https://www.digikey.com/Web%20Export/Supplier%20Content/invensense-1428/pdf/invensense-motion-driver-6.1-guide.pdf?redirected=1

Maybe i will give it a try.