Memory warning

[jipp]

Hi

I use a NanoWii and depending on the features I select in config.h the size of the resulting .hex is larger or smaller.
Fair enough and expected - as well for all other boards.

My question is now at which size will the NanoWii not be working anymore.
The Arduino IDE will give a warning at a certain size:

'Low memory available, stability problems may occur.'

From my experience with Arduino, this is really a 'may' and depends on the code, allocated memory for variables, dynamic memory, ...

So it's not simple to answer and needs either a deeper look at the code, or the experience of the community.
In case a small Arduino project fails, some led will fail, in case the MultiWii code fails it could be more expensive...

is it possible to answer this at all - to avoid aa certain size?

thanks in advance.

[Kbev5709]

Here's some ways to save some memory.....I'm not sure how much gets saved when you do what I do because I never checked to see how much, but there is a slew of stuff defined by default in the config.h sketch that does not get used even in a typical quadcopter configuration. For example, under the heading "Airplane" anything that is defined there can be commented out. Anything under "Common for Heli and Airplane can also be commented out. Anything under the heading "Heli" can be commented out. Anything under the heading "LCD/OLED - display settings" can be commented out IF YOU DON"T USE AN ON BOARD LCD READOUT. Same goes for "Display settings", "Navigation" /* keys to navigate the LCD menu */ and "LCD configuration menu". If you aren't running FPV or an LCD you can do away with things that are enabled under "LCD telemetry". Unless you depend on servo's like in a tricopter to steer, or if you use a servo gimbal and camtrig, you can disable all servos and references to them. My quad flies awesomely with all of these things commented out of my sketch.
All of that stuff relating to collective pitch and servo mixing for heli are not needed for your quadcopter to fly properly. All of that stuff adds up using a lot of dynamic memory.

[jipp]

thanks for the quick answer.

this are my changes to the default config.h using a NanoWii and two sensors:

#define QUADX
#define MAXTHROTTLE 2000
#define NANOWII
#define BMP085
#define HMC5883
//#define YAW_COLL_PRECOMP 10
//#define YAW_COLL_PRECOMP_DEADBAND 120
#define RCAUX2PINRXO
#define FAILSAFE
#define LED_FLASHER // pin D12
#define LED_FLASHER_DDR DDRD
#define LED_FLASHER_PORT PORTD
#define LED_FLASHER_BIT PORTD6
#define LED_FLASHER_SEQUENCE 0b00000000
#define LED_FLASHER_SEQUENCE_ARMED 0b00000101
#define LED_FLASHER_SEQUENCE_MAX 0b11111111
#define LED_FLASHER_SEQUENCE_LOW 0b00000000
#define MAG_DECLINATION 1.33f
//#define GPS_LEAD_FILTER
#define BUZZER
#define MOTOR_STOP


thanks to the above recommendation I played around and figured out that commenting of the following has some influence in memory usage:
//#define YAW_COLL_PRECOMP 10
//#define YAW_COLL_PRECOMP_DEADBAND 120
//#define GPS_LEAD_FILTER

As well there is a difference in using
#define RCAUX2PINRXO
-> uses more memory than
#define RCAUX2PIND17


After all I get the following message:

Der Sketch verwendet 23.286 Bytes (81%) des Programmspeicherplatzes. Das Maximum sind 28.672 Bytes.
Globale Variablen verwenden 1.966 Bytes (76%) des dynamischen Speichers, 594 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.560 Bytes.
Wenig Speicher verfügbar, es können Stabilitätsprobleme auftreten.

so a warning about possible instability. I guess its because of the usage of variables.

I did a different Arduino project yesterday where a similar message results in a crash after some loops, which I would like to void.

Any experience how likely his is on MultiWii if the dynamic memory is 76% utilized?

[Kbev5709]

Is that a list of all the things that you changed? That's all cool but if you go through ALL the default config.h settings that come with your multiwii arduino version 2.4 or whatever you use, you will see ALL of the stuff that I mentioned also UNCOMMENTED and enabled which DOESN'T NEED TO BE for a quad to fly. RE-COMMENTING all of the stuff I mentioned won't affect any flight characteristics and saves a ton of memory. Maybe I'm wrong and you can't disable some of this stuff because you don't use an AIO board, but I doubt it. In my previous post I listed all of the heading names under which everything under that heading that is un-commented can be re-commented to save more memory.
When I said "All of that stuff relating to collective pitch and servo mixing for heli are not needed for your quadcopter to fly properly. All of that stuff adds up using a lot of dynamic memory." I was talking about the fact that a collective pitch heli is not a quad, with a collective pitch heli using a swashplate to change the pitch of the collective pitch prop. Just disable (re-comment) all that crap. Also it does not need settings meant for airplanes (but they are enabled by default) so that can be disabled too. I run a fully functional mega board with GPS and everything and it only uses 37 percent memory. Re-enable all that crap and it goes to 89 percent.

[jipp]

I did some investigations and collected the following infos (based on MultiWii 2.4).

The NanoWii is based on the Atmega 32U4. The following are the memory characteristics of it:
-Flash 32k (4 KB used by boot loader) - full memory can be used when boot loader is bypassed
-SRAM 2.5k
-EEPROM 1K

The different kind of memory have different purposes:
-Flash or Program Memory: used to store your program image and any initialized data
-SRAM (Static Random Access Memory): Static Data, Heap, Stack
-EEPROM: another form of non-volatile memory that can be read or written from your executing program

The amount of Flash memory usable for the code and initialed data can be increased by bypassing the boot loader. To do so you need either another Arduino or an ISP programmer.

I found the webpage below which explains in a quite good way how Memory is used: https://learn.adafruit.com/memories-of- ... o-memories
Some information from above is from there.

Bypassing the boot loader is quite simple by connecting the NanoWii to an ISP (also an Arduino can be used as programmer). The NanoWii ports need to be connected as follow:

RAW -> VCC
GND -> GND
RST -> RST
Pin 14 MISO
Pin 15 SCK
Pin 16 MOSI

Programming the NanoWii with an ISP can overwrite the boot loader, but it can also be rewritten using the ISP. Using the Arduino IDE 1.6.x its quite simple to place self-made definitions of boards into the private Arduino folder. I attached them as .zip. Simply place it in <Home Folder> -> Arduino -> hardware. After this the IDE will show two additional boards: NanoWii (a copy of the Arduino Leonardo definitions) and NanoWii (ISP) (which has a different definition of free flash memory - excluding the boot loader).

Another important outcome is that you simply have to try some settings inside the config.h. It can be that pin definitions (aux2 on RX0 uses more men than on D17) release more memory and commenting out some settings (Heli, GPS) also releases some memory. Read carefully through the comments, there are good hints to spare memory as well.

At the end: the NanoWii is a small processor with few memory and there will be compromises.
Take Memory warnings serious it can result in process crashes or weird behaviour.

Due to this and also thanks to the comments from above I found a combination which fits my needs (only listen the diffs below):

#define QUADX
#define MINTHROTTLE 1200 // (*) (**)
#define MAXTHROTTLE 2000
#define NANOWII // the smallest multiwii FC based on MPU6050 + pro micro based proc <- confirmed by Alex
#define BMP085
#define HMC5883
///#define SRF10 // may used later
#define FORCE_MAG_ORIENTATION(X, Y, Z) {imu.magADC[ROLL] = X; imu.magADC[PITCH] = Y; imu.magADC[YAW] = -Z;}
#define RCAUX2PIND17
#define HEADFREE
#define FAILSAFE // uncomment to activate the failsafe function
#define LED_FLASHER // pin D12 (former D8)
#define LED_FLASHER_DDR DDRD
#define LED_FLASHER_PORT PORTD
#define LED_FLASHER_BIT PORTD6
#define LED_FLASHER_SEQUENCE 0b00000000 // leds OFF
#define LED_FLASHER_SEQUENCE_ARMED 0b00000101 // create double flashes
#define LED_FLASHER_SEQUENCE_MAX 0b11111111 // full illumination
#define LED_FLASHER_SEQUENCE_LOW 0b00000000 // no illumination
#define LANDING_LIGHTS_ADOPT_LED_FLASHER_PATTERN
#define MAG_DECLINATION 1.33f //(**)
#define MOTOR_STOP

this ends in:
Der Sketch verwendet 22.502 Bytes (78%) des Programmspeicherplatzes. Das Maximum sind 28.672 Bytes.
Globale Variablen verwenden 1.879 Bytes (73%) des dynamischen Speichers, 681 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.560 Bytes.

including #define SRF10:
Der Sketch verwendet 23.230 Bytes (81%) des Programmspeicherplatzes. Das Maximum sind 28.672 Bytes.
Globale Variablen verwenden 1.904 Bytes (74%) des dynamischen Speichers, 656 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.560 Bytes.

commenting out all things that are obvious not needed (see post above) will reduce the memory from the 2nd set to:
Der Sketch verwendet 23.212 Bytes (80%) des Programmspeicherplatzes. Das Maximum sind 28.672 Bytes.
Globale Variablen verwenden 1.901 Bytes (74%) des dynamischen Speichers, 659 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.560 Bytes.