Serial.print dropping commands?

Hey Guys,

I have a HD44780-based LCD with a Modern Device LCD117 Serial LCD Board -->

I have some code that has been running merrily for the last six months and i have added a couple of more if arguments to it and now it is dropping commands that i send to it. i have spent over 2 weeks trying to work out why! :-[




HABS v0x00?n?n Start to Begin?n Select for Setup

f Select Mode?n?n A for Manual?n B for Automated


HABS v0x00 Start to Begin?n Select for Setup

B for Automated


as you can see i

this is the old code

// for hlt element ssr

if ((state & NES_SELECT) and (ReadPinElementHlt == LOW)) { digitalWrite(PinElementHlt, HIGH); Serial.print("?x00?y1ON "); } else if ((state & NES_SELECT) and (ReadPinElementHlt == HIGH)) { digitalWrite(PinElementHlt, LOW); Serial.print("?x00?y1OFF"); }

// for hlt pump ssr

if ((state & NES_START) and (ReadPinPumpHlt == LOW)) { digitalWrite(PinPumpHlt, HIGH); Serial.print("?x04?y1ON "); } else if ((state & NES_START) and (ReadPinPumpHlt == HIGH)) { digitalWrite(PinPumpHlt, LOW); Serial.print("?x04?y1OFF"); }

and this is the new code added to the bottom

// for mashtun pump ssr

if ((state & NES_B) and (ReadPinPumpMT == LOW)) { digitalWrite(PinPumpMT, HIGH); Serial.print("?x09?y1ON "); } else if ((state & NES_B) and (ReadPinPumpMT == HIGH)) { digitalWrite(PinPumpMT, LOW); Serial.print("?x09?y1OFF"); }

// for mash stirrer ssr

if ((state & NES_A) and (ReadPinMotorMT == LOW)) { digitalWrite(PinMotorMT, HIGH); Serial.print("?x13?y1ON "); } else if ((state & NES_A) and (ReadPinMotorMT == HIGH)) { digitalWrite(PinMotorMT, LOW); Serial.print("?x13?y1OFF"); }

If someone could explain why adding a couple of arguments would cause erratic behavour i would be forever grateful

Cheers Rob.

just a quick note, the first examples were captured using the serial monitor in arduino.

anything with a ? infront of it is a command ie ?n will start a new line

the command summary is here -->

You’re probably running out of RAM and that’s making your program misbehave.

All of those literal strings get stored in RAM along with the stack, heap and various predefined buffers. It’s very easy to use up 1K.

Hello etracer,

thankyou very much!

i have ordered a Atmega328 chip which i believe has twice the ram.

I will post here if that fixes the problem but i definately think your onto something!

Cheers Rob.

I wonder if i could use the ram hack on the ladyada site for now?


Yes, you can change the receive buffer to save some RAM. This presumes that you are not receiving a large amount of serial data. The buffer is there so that if you don't do quickly enough you don't lose data (by overrunning the buffer).

Another thing you can look into is moving your string literals into PROGMEM. This moves them from RAM to the flash program space. There is a Flash Library that can make this easier.

Next, look at your variable definitions and make sure you're using appropriate types. Don't use an int when all you need is a byte (like for the pin definitions). Avoid floats unless you really really need floating point results. Use "const" or #define for constants instead of using variables (once again for things like pin definitions or other fixed values). If the value is defined as a constant (or #define) the compiler uses the value where appropriate at compile-time only. This eliminates it's RAM footprint. It all comes down to optimization to preserve a very limited resource.

Lastly, remember that there is a difference between the variables that are static and consume a constant fixed amount of space in the heap, and dynamic usage in the heap and stack - both of which reside in RAM. As you call functions in you sketch, the arguments (and result from the function) are placed on the stack, causing it to temporarily grow. Also, any variables defined in the local scope of the function are added to the heap - also causing it to grow. When the function exits, this stack space and heap usage is released. The problem is that if you're close to running out of RAM from your static usage, the dynamic amount used during function calls can push you over the limit and cause the heap and stack to collide and corrupt data (causing crashes, weird results, etc.). This is very difficult to diagnose since the dynamic usage is only temporary. So the general rule of thumb is to not let your static usage get too high so that you have minimal free RAM.

Hello etracer,

You have saved me a phenomenal amount of frustration!

Thankyou for a very detailed explanation, i will have to read over it a few more times yet until it sinks in!

My new code is running stable on Arduino 0014 but Arduino 0015 seems to push it over the edge again (i'm guessing 0015 has something that uses more ram than 0014)

i end up doing the ladyada ram hack and checked over my code changing my pin definitions from int to byte as well as a few other locations i was using int when i only needed byte.

Thanks again Rob.