Partial OLED static glitch

I am experiencing a bizarre issue where a small part of my OLED display will glitch out, based on the existence of functions that aren't even called.

My wiring is as follows:
A4 and A5 go to sda and scl, gnd to gnd, and 5V to vcc.
A0, A1, and A2, are each connected to the other gnd line.

In my code, it starts by running Cordpage, and will run only that function unless one of the button pins is grounded. Bladepage, Crosspage, and Lamepage do not run(and wouldn't really do anything even if they were called). However, despite the fact that this is running Cordpage, and never changing to another, there is a small burst of static in the lower right. This static goes away if ANY of the other pages are commented out in the loop. For example, the only difference between my two files is that in the loop

if(page == bladepage){
Bladepage();
}

has been replaced with

if(page == bladepage){
//Bladepage();
}

yet, in spite of the fact that Bladepage is never called, this removes the static. This also works for Crosspage and Lamepage.

These are the displays in question.

In principle, I know there might be ways to try and circumvent this issue, like clearing and rewriting the display each time. I haven't given those much consideration yet, because for now, I just want to know WHY it's glitching out like this; it makes absolutely no sense to me that this should be an issue.
Can anyone give me any insight into why this is happening? I'm losing my mind.




sketch_sep12c.ino (11.3 KB)
sketch_sep12d.ino (11.3 KB)

I reckon you are running out of dynamic memory and your stack is bleeding into your display buffer. When I compile your sketch I see:

Sketch uses 18800 bytes (61%) of program storage space. Maximum is 30720 bytes.
Global variables use 743 bytes (36%) of dynamic memory, leaving 1305 bytes for local variables. Maximum is 2048 bytes.

which seems fine, but what you don't see included there is the 1k buffer for the display (allocated on the heap using malloc). So free memory is only about 280 bytes. But you are also using a few Strings which also use up heap, and then you have the stack requirements as well.

I would suggest eliminating your use of Arduino String in favour of simple C-style strings. That will mean you will see the memory required for the strings in the memory summary during compilation and will also reduce or eliminate competition for the small amount of residual heap at run time.

THANK YOU! That seems to make sense, I did some quick tests and found that commenting out some of the print strings reduced the size of the static. Also, replacing

display.println("Cross test");

with

display.print("Cross");
display.print(" ");
display.println("test");

for some reason seemed to save memory.

I'm still a bit confused as to why this is happening though, since everything I changed was in functions weren't being called. Is there any way to stop them from influencing the other functions when they aren't running.

Also, might you be able to recommend a good resource to learn about using C-style strings as you said in arduino? I tried googling it, but I got a jumble of rather opaque results and discussions/tutorials of regular string use.

You simply have to keep a close eye and control over the memory you are using. Once memory gets accidentally overwritten, the symptoms can be very varied and hard to track down. Where memory is tight, try to avoid using run-time dynamically allocated memory (malloc/new). I appreciate you probably didn't know you were using it in this situation, but now you do.

You could start here for an intro into C-strings.

The cross test thing is likely because the compiler looks for "string literals" that are duplicated in the sketch and only stores them once. It then just references the one copy anywhere it is used. I don't recommend breaking them up as you have though as it impacts readability - that would be a last resort.

EDIT: Oh, and you could also try the F() macro to save some memory, though it may not be supported in every situation.