I have been told that the I2C GPS board isn't recommended with multiwii 2.4 and been given no reason... I'm making sure it's possible!
I have set up Multiwii 2.4 with the I2C GPS board and bluetooth (also works with my OSD with bluetooth removed) and found that initially I was very short of RAM on the main 328... not really a surprise but it's so marginal it should be doable. I frequently run microcontrollers right up to the limits of the ram quite safely.
I found some code posted by EOSBandi that worked out the amount of free ram and I added this to my firmware and did some testing.
With the following enabled in config.h I had issues with running out of memory, the FC was glitchy and reset when conditional code ran (for example it was stable with the TX switched off and would crash when turning on the TX):
Code: Select all
#define QUADX
#define HK_MultiWii_SE_V2
#define FAILSAFE
#define DEADBAND 10
#define I2C_GPS
#define VBAT
#define POWERMETER_HARD
#define SUPPRESS_DEFAULTS_FROM_GUI
#define PSENSOR_SMOOTH 16 // the next three are default settings for averaging filter array lengths
#define VBAT_SMOOTH 16
#define RSSI_SMOOTH 16
When I reduced the size of the arrays used for averaging battery voltage and current values I was then able to get a sensible reading for the available ram and the controller didn't reset any more. With the following defined, around 5 bytes was free and the controller seemed ok. This wasn't what I would consider a safe margin, though.
Code: Select all
#define PSENSOR_SMOOTH 8
#define VBAT_SMOOTH 8
#define RSSI_SMOOTH 8
With the following defined I had around 60 bytes of free ram running the controller with a GPS fix, radio on and testing stick input, enabling GPS hold and RTH all seems fine. I left this running for quite a long time with a decent GPS fix. This change effectively disables all averaging of the Vbat and current values.
Code: Select all
#define PSENSOR_SMOOTH 1
#define VBAT_SMOOTH 1
#define RSSI_SMOOTH 1
My first scan through the GPS code didn't reveal anything that consumes a lot of memory that I didn't make use of in my ground testing... I think I'm good to go.
I think that free ram monitoring is a very important thing for this multirotor boards (it would have instantly stopped me from flying if I could have seen I had no free ram) and it would cut down on the number of crashes caused by people (who like me, want to get a lot on a small FC). It would be nice if this was a permanent fixture, it hardly costs any code space, ram or really impacts on cycle time as far as I can tell...