Ah, I know that text adventure game.
Someone ported it to the Pokitto and then some random parent complained about the “scream pathetically like a girl” part.
Looking at the code I can’t actually see a direct cause,
so I’m suspecting it’s one of three things:
- A buffer overrun somewhere
- A side effect of some optimisation
- A side effect of the extra processing involved in an
The last possibility can be tested by putting the code in a state where the problem is present and then moving all the functions to an
.cpp file and calling them from the
If the problem can’t be replicated after that then it’s likely that the
.ino file is the cause.
Another test is to put the code in a state where the problem is present, compile it, and then fish out the
.cpp file that the Arduino IDE generates and examine it for discrepencies.
By the way, your
loop is printing the address of the
state variable, not its contents.
If the problem is optimisation related then the fact you’re taking the address of
state might actually be what’s stopping the problem because taking the address of a variable forces the variable to be stored in RAM.
I can see a few ways to optimise/improve this in general.
E.g. instead of having a buffer and wasting time with
strcpy_P you could just have a
There’s a number of other small improvements that could be made too:
bool instead of
false instead of
pgm_read_ptr to read a pointer instead of
uintptr_t instead of
unsigned int when interpreting a pointer as an integer
- Have a namespace
GLCD instead of tacking
GLCD_ on the front of functions.
I’d have a go at trying to improve the code, but I’d be flying blind,
so I’d probably end up writing something that didn’t run properly.