MultiWii 2.4 - Don't fly if you are warned for low memory.

[Pigeoncraft]

I know this is probably a no brainer for most of us but I though I would share some of my findings.

So I have a smaller quad using a Flip 1.5 controller and when 2.4 was out I had the urge to upgrade as most of us do. When compiling the sketch I noticed that the settings I wanted to use (I2C GPS, Baro, ect) was using 98% of the storage space.

Exact Warning:

Sketch uses 30,408 bytes (98%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,749 bytes (85%) of dynamic memory, leaving 299 bytes for local variables. Maximum is 2,048 bytes.
Low memory available, stability problems may occur.

Normally this would tell me that I need to get a new board or do some magic to the code to shrink it. But I said "Meh, Ill be a guinea pig." So I loaded it up and it seemed to work fine doing initial testing props off looking at logs also checking Bluetooth and gps packets. Great. But I still didn't trust it. So I then put the props on and stuck it on a stand tied down and starting it up. I set it at half throttle and started going though different modes. Level, Horizon, Baro, Gps Hold, Fly path ect. I got though the first loop of tests fine and set it to idle. Then I noticed the board reset which seemed odd I then went to rearm the motors and the instant I gave it any throttle it seemed to jump to half to full throttle and decided that 20 - 30 degrees to the side was center and wouldn't really listen to controller input. I pulled power and now currently going though the code to see if I can shrink it so I can continue more tests.

If any of you ha\ve some ideas on how we can shrink the GPS code down a little bit that would be great because as it stands more then 40% of the code it seems is the GPS.

[PatrikE]

Actually the navigation engine is still active even without waypoints!

I have done some slimming on my FixedWing dev.
MultiWii_FW_150431.zip
It undefines Baro and MAG plus lots of GPS code.
But when i add the sensors it it compiles smaller on a Crius_SE

Sketch uses 25 952 bytes (84%) of program storage space. Maximum is 30 720 bytes.
Global variables use 1 744 bytes (85%) of dynamic memory, leaving 304 bytes for local variables. Maximum is 2 048 bytes

There's still memory warnings though.
Add #define SLIM_WING in config.h
You need to find in def.h where the sensors is undefined.
search for SLIM_WING

I have not tested tto use SLIM_WING on a copter so be careful!
It works good on planes but there might be something for copters still needed.
Or at least it can give some clues what you can exclude in the code.

/Patrik

[Pigeoncraft]

Yeah ill have to look into that when I get home. I'm just worried about the low amount of bytes for local vars.

[GUSHELFER]

also they are working on it, when you have the communicate novelties .

[brm]

time for a quck increment: 8 to 32 bit

for shure someone can add a ton of new conditional compiles, but ....

[Pigeoncraft]

Well if there is code that is using up large amounts of cycle time and memory and only some people are going to use it then we should have defines to keep it out of the compile.