Going from r1692 to r1695 eats about 160 bytes

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Going from r1692 to r1695 eats about 160 bytes

Post by Hamburger »

with the same config as before - no GPS, regular RX - I see an increase of memory consumption of about 170 bytes when going from r1692 to r1695.
From first glance this comes with eosbandi r1694 code changes. Not sure which part of that huge submit would bring such increase.
Anyone else observed this?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Alexinparis »

around 30 are eaten here:

Code: Select all

  #else                   //if no servo defined then zero out the config variables to prevent passing false data to the gui.
    for(i=0;i<8;i++) {
        conf.servoConf[i].min = 0;
        conf.servoConf[i].max = 0;
        conf.servoConf[i].middle = 0;
        conf.servoConf[i].rate = 0;
      }
  #endif


I don't think this code is useful as the gui should not care in case of no servo

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Alexinparis »

more than 40 were eaten due to the #ifdef GPS bug

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Hamburger »

Ah ok. So we get an idea where and what to look for.
Thanks.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Hamburger »

my next tests use the configuration of #define COPTERTEST 1.
If I enclose the unused function in Protocol.cpp with an #ifdef like this that will reduce hex file size by 106 bytes.

Code: Select all

#ifdef GPS_SIMULATOR
void SerialWrite16(uint8_t port, int16_t val)
{
  CURRENTPORT=port;
  serialize16(val);UartSendData(port);
}
#endif

why would it make a difference if an unused function implementation was included in source or not?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Hamburger »

anyone to confirm the memory waste from the unused SerialWrite16()?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Alexinparis »

Hamburger wrote:anyone to confirm the memory waste from the unused SerialWrite16()?


I managed to reproduce this memory waste, but not currently with win Arduino 1.0.5-r2
quite odd: the declaration is done Serial.h and definition Protocol.cpp
the compiler/linker is maybe lost

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by EOSBandi »

Hamburger wrote:anyone to confirm the memory waste from the unused SerialWrite16()?

Nope, I tried it (r1700) and the sketch size remains at 11668 byte even if I comment out the function....
(Using 1.0.5-r2 with Visual Studio IDE)

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by EOSBandi »

Alexinparis wrote:around 30 are eaten here:

Code: Select all

  #else                   //if no servo defined then zero out the config variables to prevent passing false data to the gui.
    for(i=0;i<8;i++) {
        conf.servoConf[i].min = 0;
        conf.servoConf[i].max = 0;
        conf.servoConf[i].middle = 0;
        conf.servoConf[i].rate = 0;
      }
  #endif


I don't think this code is useful as the gui should not care in case of no servo


Well, it was a quick hack to fix a problem in WinGUI. I thought that without servo the config struct elements will be zero. But i realized that it contains garbage.... :(

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Hamburger »

EOSBandi wrote:Nope, I tried it (r1700) and the sketch size remains at 11668 byte even if I comment out the function....
(Using 1.0.5-r2 with Visual Studio IDE)

ok, seems to be a compiler issue then. I use the toolchain that comes with older version of arduino IDE', probably 1.0.3.
What is the current 'official' recomendation for arduino IDE? I would continue testing with that version then.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Hamburger »

EOSBandi wrote:
Hamburger wrote:anyone to confirm the memory waste from the unused SerialWrite16()?

Nope, I tried it (r1700) and the sketch size remains at 11668 byte even if I comment out the function....
(Using 1.0.5-r2 with Visual Studio IDE)


some update:
both arduino ide 1.0.3 and 1.0.4 come with the same toolchain (according to versions.txt) on macosx.
avarice: 2.8
avr-libc: 1.6.4
avrdude: 5.4-arduino
binutils: 2.19
gcc-3: 3.4.6
gcc-4: 4.3.2
gdb: 6.8
libusb: 0.1.12
make: 3.81
simulavr: 0.1.2.5

No surprise, both arduino ide versions do produce same size of 10358 bytes. (quite less than your value of 11668)
Yes if I repeat your experiment r1700, coptertest=1 and compare with the unused function SerialWrite16() commented vs. uncommented then I get same size 10358 bytes again.

But if I do same comparison with r1698, coptertest=1, then commenting vs. uncommenting the unused function SerialWrite16() suddenly matters!

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Going from r1692 to r1695 eats about 160 bytes

Post by Hamburger »

EOSBandi wrote:Well, it was a quick hack to fix a problem in WinGUI. I thought that without servo the config struct elements will be zero. But i realized that it contains garbage.... :(

Umh, I took that for an ok to remove it. Hope the interpretation was correct?

Post Reply