Arduino20/ 21 break code what runs on Arduino19 ok


i try to get my project working with the Arduino Uno, so i took the 21 and just uploaded what was working nice on the Duemilanove328.

It compiles fine (even 500bytes smaller) but its not working at all.

The Code is here: (its a little big...)

The Problems are:

  • Serial does not work
  • LCD Shows intro screen, then something else, then nothing, randomized
  • Portexpander over I2C do not work

I think something in the Memory is messed up, im using a lot of variables, but with 19 it worked :-[

Any Ideas where to look?

with greetings from austria, Steff

Can't figure out how to build your (eclipse based?) project, but a RAM problems seems pretty likely; various libraries consume different amounts of ram in different versions, due to feature additions and whatnot (not to mention changes in compiler behavior.)

What does "avr-size" say about your final .elf file in each version?

eclipse is for future development ;)

currently still in the arduino ide...

avr-size for the elf on 19:

   text         data          bss          dec          hex      filename
  25296         1398          476        27170         6a22      work_designer2k2_03.cpp.elf

and on 20:

   text         data          bss          dec          hex      filename
  24740         1400          622        26762         688a      work_designer2k2_03.cpp.elf

do i see it right that on 19 it takes 1874 SRAM, and on 20 2022? But as the Atmega328 only has 2000 it fails?

If so, how can i reduce the BSS ? :-?

And what is the BSS?

And what is the BSS?

That one I can answer... BSS is uninitialized data. Some examples...

int NotInit1; // set to zero by run-time library; placed in the BSS section char Buffer[10]; // also set to zero by RTL; in the BSS section

byte Flag = 1; // initialized by RTL; in the DATA section

void MyFunc( void ) { int AutoVar; // this one goes in the STACK section static char S[21]; // this one goes in BSS int i = 37; // this goes in DATA }

Now try

avr-objdump -t -j .bss xxx.elf

Which will dump the symbol table for the bss section (as Coding said, this is "uninitialized data". Normally the biggest chunk in most sketches is the 128byte serial buffer.) Look for things that are inappropriately large, or major changes between the versions. I don't recall having come across changes between 19 and 21 that caused significant increases in .bss size, but it wouldn't surprise me.

Note that in addition to data and bss sections in ram, your program will also need to use some amount of stack. If you're over 2000 bytes even without the stack, you definitely are going to have problems...

ok, done the avr-objump, this things got bigger:


008005f6 l     O .bss      00000002 twi_masterBuffer
008005fa l     O .bss      00000002 twi_txBuffer
008005fe l     O .bss      00000002 twi_rxBuffer
008005ea g     O .bss      00000002 _ZN7TwoWire8txBufferE
008005e5 g     O .bss      00000002 _ZN7TwoWire8rxBufferE


00800634 l     O .bss      00000020 twi_masterBuffer
00800656 l     O .bss      00000020 twi_txBuffer
00800678 l     O .bss      00000020 twi_rxBuffer
0080060a g     O .bss      00000020 _ZN7TwoWire8txBufferE
008005e7 g     O .bss      00000020 _ZN7TwoWire8rxBufferE

nothing else changed...

so, all this got 10x as big. what costs 90bytes, or?

I have now just changed some serial.println("LONG TEXT") to serial.println("LT") style, and its working again ::) Just slipped right below the 2000byte mark...

But i will rethink the whole thing, running so close to the edge is not confident :-[

Thanks for all the help!!! Saved my day :)

I found the following structure really useful for sketches that print a lot of "plain" strings, and rather simpler than I had expected... Getting "double-charged" for constant strings is annoying!

#define fp(string) flashprint(PSTR(string));
void flashprint (const char p[])
    byte c;
    while (0 != (c = pgm_read_byte(p++))) {
      fp("Calibrated 8MHz Internal Clock");

that looks interesting :)

as im using already PROGMEM for some lookup tables i thought about taking it also for the strings, but your way looks different to the samples from PROGMEM.

Will give it a try, with all my strings this should save quite a bit!

your way looks different to the samples from PROGMEM

Some of the other libraries that allow you to put strings in flash memory went to some trouble to allow the overloaded "print" functions to "do the right thing", and/or implement "stream" for convenient IO. My function ONLY prints a string. Very C-like rather than C++. :-)

you guys helped me a lot, so i made a small writeup from this so maybe others will be helped too:

Arduino SRAM Overflow