Serial buffer being corrupted by inclusion of code

So this is really strange. It took me probably a couple hours to narrow down this issue through trial and error. I'm getting garbage (but not random, one build of the sketch will produce the same results after each reset) data when reading the serial line. It only happens if the few lines below are included in the sketch. The function these lines are in is not being called! It's as if the compilation of these lines is introducing a bug.

The bad code:
unsigned long now = millis();
if ((now - hltWindowStartTime) > pidWindowSize) {
hltWindowStartTime += pidWindowSize;
}
if (hltPidOutput > (now - hltWindowStartTime)) {
Serial.println("Turning on hlt element");
startElementHlt();
} else {
Serial.println("Turning off hlt element");
stopElementHlt();
}

What I'm seeing when the lines are included (But not called!): this time, I have 18 bytes available to be read from the serial line even though I'm not typed anything in the monitor app. Any advice would be appreciated. I'm pretty new to arduino, but have been writing c++ and java for 15 years or more.

thanks,
brian

Those two string constants are going to take up precious SRAM. Perhaps you are near to running out of SRAM? That could explain why adding that code produces unexpected results.

Try changing:

    Serial.print("string constant");

to:

    Serial.print(F("string constant"));

This will allow the string constants to be printed directly form FLASH instead of being copied to SRAM before your sketch starts. This will save SRAM space and will work for .print() and .println().

Thanks John! That appears to be the problem. I'm now moving all of my UI strings over to flash using the technique documented here: PROGMEM - Arduino Reference
I had no idea of the 2k ram limitation (I'm used to writing servers that can use 2gb!). I do fault the arduino IDE / toolset for not detecting this problem, as all of the ram allocations seem to be static and fairly easily verified before loading the sketch.

cheers,
brian

bkrahmer:
Thanks John! That appears to be the problem. I'm now moving all of my UI strings over to flash using the technique documented here: http://www.arduino.cc/en/Reference/PROGMEM
I had no idea of the 2k ram limitation (I'm used to writing servers that can use 2gb!). I do fault the arduino IDE / toolset for not detecting this problem, as all of the ram allocations seem to be static and fairly easily verified before loading the sketch.

cheers,
brian

Not all used RAM usage is static, and considering a single inclusion like that put you over, I'm betting that if you totaled ALL of the static declarations, it wouldn't be over 2K. I guess its' easier though, to blame others.

Not all used RAM usage is static, and considering a single inclusion like that put you over, I'm betting that if you totaled ALL of the static declarations, it wouldn't be over 2K. I guess its' easier though, to blame others.

Well, I had non-static usage down to about 3 bytes of locals + about 3 stack pushes and whatever Serial.read() takes, but thanks for the snarky reply. If I were to exceed 64k lines of java code in a single class, my compiler actually blows up on me, it doesn't produce an invalid class file that causes the computer to reboot. Seemed reasonable to me, I guessing you have contributed to the avr toolset to be so offended by a suggestion for an improvement.

brian

bkrahmer:
I guessing you have contributed to the avr toolset to be so offended by a suggestion for an improvement.

I haven't adopted the latest IDE version yet but I've read comments implying that it does include checking the estimated RAM use. The problem is that global declarations are only one of the things that use RAM and the other uses are not realistically feasible to estimate.

I use this bit of code to help me figure out how much RAM I have left:

#include <inttypes.h>

extern int __bss_end;
extern void *__brkval;

int get_free_memory()
{
  int free_memory;

  if((int)__brkval == 0)
    free_memory = ((int)&free_memory) - ((int)&__bss_end);
  else
    free_memory = ((int)&free_memory) - ((int)__brkval);

  return free_memory;
}

Not really sure how accurate it is but does let you know you’re getting close.

I guessing you have contributed to the avr toolset to be so offended by a suggestion for an improvement.

brian

"I blame them"

Sure sounds like a suggestion for improvement. ..