[Solved] Getting different results from the same function in two programs...

Hey guys,

I started with a touchscreen calibration program from Adafruit and built my program on top of that. I'm designing a keyboard GUI on a 7" TFT touchscreen (800x480) using the RA8875 graphics driver, all off of a genuine Arduino Uno R3. Anyhow, the original calibration program found in the libraries examples works like a charm, but in my project, it seems to not get past line 62 no matter how much I smash my finger into the screen. I know this to be true from the debugging messages you see in my code. This is line 138 in the original version.

They note "Wait around for a new touch event (INT pin goes low)" on that line (I've deleted the comment on mine), so what seems to be happening here is something between digital pin 3 and line 62 of the program, something isn't working right. I know there isn't an issue with the hardware or my connections as when I test the original it still works fine. I'm wondering if maybe there's something software side that's making this occur (perhaps the fact that my sketch currently uses 48% of program storage space and 37% of dynamic memory?). Any ideas would be appreciated greatly.

I know very well that it's quite inefficient for what it's supposed to achieve but I plan on tending to that later unless that is revealed to be the root of this problem. I also (now) know to test more frequently or at least save intermediary working versions!

Thx & BR,

Chris

I suspect the stack gets rather deep which raises the possibility of running out of SRAM at run-time.

There are several of these...

  Serial.print("CHANNEL ID: ");

Have you considered using the F-macro to eliminate consuming SRAM?

There are several of these...

  tft.textWrite("_ _ _ _ _ _");

If the TFT library supports it, have you considered using the F-macro to eliminate consuming SRAM?

Thanks for the suggestion. Initially, I did not consider it because most of the Serial outputs were put in place after I began debugging but I suppose that's only making my problem worse. I've since wrapped all serial outputs in F();, but the TFT library unfortunately does not support this. In hopes that it really is an SRAM consumption issue, I'm now going to try to push variables into PROGMEM. I'll update when done.

I changed my approach last night. Instead of moving everything into PROGMEM (which would have been all for nothing), I installed the freeMemory() library and found that I'm doing just fine (1365 bytes to spare during that while loop that's causing me so much trouble). I tried changing Uno boards and the RA8875_INT pin as well, made no difference. So I scrapped the calibration algorithm for a simple linear division one (granted, it's inaccurate) and it executes just fine. So I'm now convinced there's an issue with the board not being able to digitalRead after the calibration process (i.e. it's a software problem). I'll keep tinkering.

Build_and_Break:
I installed the freeMemory() library and found that I'm doing just fine (1365 bytes to spare during that while loop that's causing me so much trouble).

The measurement has to be taken at the deepest stack level to have any meaning.

@Coding Badly wouldn't it make the most sense to test at and directly before the point where a lack of available RAM is suspected? I'm certain if I ran the test in other functions my result would be, if anything, better (except for initial calibration during startup, but it executes that function well).

Build_and_Break:
@Coding Badly wouldn't it make the most sense to test at and directly before the point where a lack of available RAM is suspected?

See reply #4. By the time your suspect code is running SRAM may already be corrupt.

I'm certain if I ran the test in other functions my result would be, if anything, better (except for initial calibration during startup, but it executes that function well).

Your certainty is easily put to the test by making some actual observations.

They certainly were and passed said test with flying colors; to anyone wondering, I found two workarounds and have employed both in this paste. First, I switched from constantly checking the pin to using tft.touched() which checks the touch handler's memory for an "unread" touch event. Next, I switched everything over to char (long overdue) and reconstructed the keyboard entry handler. I'm unfortunately at a loss for words for exactly how I did it so those interested are really better off just looking at the paste.

Thanks to @Coding Badly for the help. Issue resolved.

Thank you for the follow-up.