Is this a memory conflict?

I’m working on a project that involves using a rotary encoder to navigate a menu on an LCD using the ADAencoder library.

The sketch was working fine, then quit working after I added another unrelated routine. After commenting sections out to try and identify the source of the problem, I came to a section that simply changes the pointer in a pointer array. The entire sketch is quite long, but the basics are below:

// defined globally (before setup):
char *LCDline1[4]; 
char Line1Msg0[] = "00:00  Temp 88 F";
char Line1Msg1[] = "***Temp High ***";
char Line1Msg2[] = "*** Temp Low ***";
…..
void loop(){
…
    for(i = 1; i<4; i++){     // reset all pointers 
      LCDline1[i] = Line1Msg0;    // if I change this to Line1Msg2 it doesn't work.
    }
}

As written above, the code works fine. If I change the assignment in the for loop to anything besides Line1Msg0, (see below,) the encoder quits working.

     LCDline1[i] = Line1Msg0;    // This line will work perfectly
    LCDline[i] = Line1Msg1;    // this compiles fine but the encoder quits working.

Any idea what this could be or how to debug it? My sketch uses about 15K of memory, so I shouldn’t be running into memory problems. The strings are also not used in any other part of the sketch. Another thing I’ve noticed is that if I use Serial.print, the encoder library gets glitchy but will still work for the most part.

Might you be running out of RAM? Remember the compiler optimizes away things you never use, so just referring to a value might pull it into the binary and push the size over the limit.

It looks like it may be. I didn't think it would be because my sketch compiles at 14k out of 32k available, but I forget that the Uno only has 2k of SRAM for variables and running the sketch. I tried removing any other references to Line1Msg0 and then changing the reference in the FOR loop to Line1Msg2 and it ran fine. If I added another reference to Line1Msg0 somewhere else in the sketch it quit working again. I ran a short freeRam routine and I'm down to 150 bytes, before any routines are called. :~

Guess I either need to do some memory optimization or just upgrade to a MEGA to have more space to work.

Thanks for the help!

If the “strings” are not going to change, you can keep them in PROGMEM.

You should post all your code. The 'glitchy' encoder reading is likely to be because of Serial.print, which uses interrupts, and if your encoder also uses interrupts, they could interfere with one another.

[quote author=James C4S link=topic=208185.msg1530831#msg1530831 date=1388722521] If the "strings" are not going to change, you can keep them in PROGMEM. [/quote]

Yes - that was one of my next steps; the majority are not going to change, so I should be able to save a lot of memory that way. I'm hoping to add a wifi/SD card reader in the future which I know will eat up quite a bit of RAM, so I'm likely going to need the extra memory of the Mega either way, but for the time being I'd like to make it work with the Uno.

Is there a

lar3ry: You should post all your code. The 'glitchy' encoder reading is likely to be because of Serial.print, which uses interrupts, and if your encoder also uses interrupts, they could interfere with one another.

Yes, I'd noticed that too (glitches when I added Serial.print lines for debugging), but in this case, I had turned off all the Serial commands (except Serial.begin); literally the only thing I was changing was the single variable assignment as described above. Would just the Serial.begin cause problems?

I hesitated to post all the code because it was quite long (~1000 lines), and I really don't expect people on a forum like this to sort through that much code! I tried to post enough detail while keeping it concise. Hopefully I was successful and didn't inadvertently make it harder for folks. :)

Sleepydoc: Hopefully I was successful and didn't inadvertently make it harder for folks. :)

Posting only snippets is a sure fire way to make the troubleshooting efforts significantly more difficult than necessary.