Mega 2560, sketch size 27K bytes, adding elements to my structs breaking sketch

Using Arduino Programming Questions
1

Maybe I'm missing some fine points about declaring structs. My sketch fails in inconsistent ways when I merely add members to struct definitions in an .h file even before I employ any code to utilize the members. Compile is successful, no errors. I wonder if my compiler environment has become faulty, or if I lack some understanding about how structs need to be declared for the Arduino compiler, or who knows what maybe not even related to my structs. I wouldn't even be surprised to find that the problem can only be replicated when compiling in Linux Mint.

I've built up the code in R & D stages that I would describe as proof-of-concept steps, and I am now convinced the general concept is feasible, but I cannot make further progress because whenever I add the struct elements I'll need next, the sketch fails in ways that seem totally unrelated to the new struct definition. Note that I don't even add code to employ the new elements, the sketch just fails in places that worked fine before.

I am using pin change interrupts ISR( PCINT0_vect ), etc and piggy-backing on the every-millisecond ISR( TIMER0_COMPA_vect ) interrupt. The triggering for the pin change interrupt comes from DHT temperature/humidity devices.

My TIMER0_COMPA_vect code takes many triggerings to complete longer tasks. In order to minimize the micro seconds that each triggering of TIMER0_COMPA_vect uses I will complete long tasks in very small interrupt code steps, but I am being stymied like this in getting that done. The "eat the elephant in small bites" interrupt scheme should explain to you why so many variables are global and many are struct-supplied.

I attach the code knowing that it is so long that you'll find plenty of things about it that aren't elegant - an understatement - but I'd appreciate some good-hearted opinions. Note that you'll need at least one DHT11/22 to see the code run, and I haven't tested the code with less than one device served by every pin change interrupt.

In case anyone needs to know my experience level - outside of my Arduino sketches, the only C/C++ programming I've done is a couple semesters in college 1985-ish and 2 or 3 very small helper shims in C 20 yrs ago. I do have a few yrs total of various other languages with Z80 machine/assembly (yes, both b/c the programming setup was of my own design and construction) being my strength. My profession is electronics technician.

In order to pose a specific question as an example: why does the sketch fail to print any calculated DHT readings by 17 to 20 seconds after starting if I merely uncomment the proposed element "u8 sandbox_bytes[ 6 ]" of the struct named "ISR_specific" that is defined in line 141 of "structs.h"? As I wrote above, adding the other elements to the struct produces failures as well.

Plz don't worry about the term "timebomb" in the file names. It merely means I still have debugging to do about something related to sketch operational lifespan.

Basically good (at this point in development) output:

Multiple DHT using Pin Change Interrupts Sketch

This sketch will display the numbers of all digital pins with the ports and port masks
for them, detect and display all DHT devices connected (even those on pins not
supporting Pin Change Interrupts), and detect the existence of all Pin Change Interrupts
supported by the microcontroller board and display them for you.

IT LEARNS THE INTERRUPT DETAIL BY TOGGLING PIN VOLTAGES, so all pins must be free to
toggle for the results shown to be correct.

If you need to, you may protect pins from being tested for devices by listing them in one
of the two protected pin arrays. The built-in LED renders its pin useless for DHT use,
so that pin is included in the list of protected pins by default and is given an alternate
.
.
.
blah
blah
.
.
.
96. interval = 0. TIMER0_COMPA_vect_stage = 0. isr_inside_ISR = 1. newbytes[ 0 ] = 4. micros() = 17110956. micros() - quartertime = 3238342377. quartertime = 1073741823
11: 0.0% 0.0C, 17.23 seconds of age. Interval = 2
12: 0.0% 0.0C, 17.23 seconds of age. Interval = 2
50: 35.0% 25.0C, 0.59 seconds of age. Interval = 2
51: 55.7% 25.5C, 1.24 seconds of age. Interval = 2
53: 35.0% 26.0C, 1.90 seconds of age. Interval = 2
14: 34.0% 26.0C, 1.04 seconds of age. Interval = 2
15: 57.5% 25.4C, 1.70 seconds of age. Interval = 2
63: 29.0% 24.0C, 1.49 seconds of age. Interval = 2
66: 56.6% 25.5C, 0.86 seconds of age. Interval = 2
67: 0.0% 0.0C, 17.30 seconds of age. Interval = 2

Note the calculated values are shown for several pins by about 17 seconds. When failed as I have described above, those values are zeroes.

structs.h (12.7 KB)

Discover_DHT_devices_Sep9from_Aug30_2017_1039_with_timebomb.ino (248 KB)

ISRs.h (38 KB)

nano_isr_details.h (2.45 KB)

misc_maskportitems.h (3.02 KB)

2

UPDATE: I reverted my sketch version back far enough and found a month-old sketch version that I can add struct elements to without the sketch failing. Thus, I will, for the umpteenth time, try a little different upgrade order. I may be alright now by updating the structs before the other code goals. Hope springs eternal....

3

I'm making fine progress with the order I said in my last post. Looks like I'll break through that glass ceiling this time if it is as it appears - a matter of declaring/defining the structs correctly in finality early enough in development before some invisible development progress/complexity/size "gotcha" line is crossed. My confidence level in the stock IDE for Linux takes another hit.

4

Conquered successfully. During which time I changed numerous things in sketch so the attached one is very obsolete. However, my previously stated conclusion about the problem with adding elements to structs remains my best thoughts about the problem I was having. And I am so glad I learned (the hard way) to save snapshots along the way so I could go back to any working point.

5

Proof of concept was finished yesterday successfully and posted in GitHub

I'll only worry about beautifying the code if some interest is shown in it.

6

While you’re having a good time answering and solving your own question, a couple of questions...,

I didn’t look at your code, but the title suggests you are trying to populate an array of structures... ok if they are in FLASH before compiling, the 2560 has quite a lot of program memory... — but if you are loading up the structure at runtime, of course they are held in RAM, which is significantly smaller than the FLASH.
Your declared program variables can only allocate perhaps 80-90% of all available RAM before bad things happen - because the compiler needs some room to handle internal transient storage needed while running your program.