running out of flash on promini/nano

[Hamburger]

Hi,
with 4 sensors board (gyro, acc, mag, baro) and lots of LCD and telemetry features I am now pretty close to the limit.
If I activate GPS (which I do not have) I can create a binary which is too large to successfully upload (32k - bootloader).
So be warned, the error message for failed upload in the arduino IDE may be not too helpfull. With Makefile in Eclipse is is easy to spot.

Already I had to do some code tweaking to reduce memory footpirnt - see latest digit1(), digit10(),...,digit10000() functions in r604 in _shared branch.

[mr.rc-cam]

Thanks for the warning. Too much good stuff crammed into a small package.

Code space relief is possible by using the EagleTree ALT-V4 baro sensor. I don't recall the exact amount of Flash mem reduction, but it was well over 1K byte. It's a very good baro sensor too, so other than the $40USD hit to the pocket book it's a useful solution. But the money could be spent on a Mega board as well, which is a better long term solution if you need all the bells and whistles.

[Hamburger]

For the time being I could diisa5le the baro Sensor as I do not yet use it. or reduce strings.
About time to switch to otber hardware

[Hamburger]

again!

I have an arduino nano with 10dof sensor FREEIMUv035_MS. As usual I have enabled full LCDconfiguration and Telemetry via vt100. With code revision 656 this config built into a hex that cannot be loaded.So I modified the code as follows:
- shorten strings,
- create macros to selectively disable single telemetry pages
- create macro to supress inclusion of the serial OSD commands codes
- simplify taskorder switching mechanism

With all these measures combined I could compile a working version again, but have to exclude most of the telemetry pages (sensors, RX inputs, auxN options' status, motor+servo outputs, diagnostics).

I do not have a GPS but from what I saw a lot of the GPS related variables are used unconditionally throughout the code regardless of #if GPS (eg. in Serial M-command). Since we all are close to moving to the next hardware platform I do not want to spend much effort on optimizing this aspect but if we intend to add functionality while remaining arduino compatible and usable, this will require some action sooner than later.

[copterrichie]

Maybe it is time to move to a new platform like a STM32.