Horrible lag from changing 1 pin assignment

Found myself a real stumper here...

For reference here's my program: https://youtu.be/QUfW7tNNWTI

Everything has been pretty snappy and working pretty well so far. I'm just at the point now where I can do a lot of debugging because I can start hooking up real inputs etc and checking to see if the data is being processed and displayed correctly. I got my input capture unit for KR working and also the AVR internal temperature graph working, then I moved on to the main battery voltage...

So I had initially made a mistake by assigning my main battery voltage to A9 on the mega. The physical wiring I did had it going to A11 through a voltage divider, to drop the voltage from 30 down to 5 and then using math internally to compensate and display 30 (or whatever voltage comes in). So bear in mind that up until I noticed this mistake, everything was working fine.

So I go into the code and check pin assignments. I realize that ADCs don't need to be set up so then I search for any instances of code reading that pin and I find just 1 which is part of my update routine. I change it from
BATT = analogRead(A9)
to
BATT = analogRead(A11)

and shit hits the fan. Not only does my KR ICP no longer work (reports a 0 instead of a 2 because I was sending it a 2) but more importantly the interface was suffering some ungodly lag. I mean bad lag, like waiting 15 seconds for my finger to register on the touch screen.

Now this only seemed to happen on screens where the battery information was present. If nothing battery related was on that screen it didn't lag but I'm wondering why the heck is it lagging at all? It reported the correct voltage so the ADC is polling, and even with the wrong pin assignment it was still polling but just giving a 1023 instead.

I guess, has anybody ever had this experience before where a program just froze up horribly because of an ADC input re-assignment? I don't even have a working hypothesis so I'm not sure what to look at first. I'm going to try changing the code back to the incorrect pin to see if that fixes the problem but that's all I can think to do now.

I can’t see your code.

Don’t forget the code tags

The code is pretty massive. Is there a particular segment you want to see?

Gahhhrrrlic:
The code is pretty massive. Is there a particular segment you want to see?

All of it please

Please follow the advice on posting a programming question given in Read this before posting a programming question

In particular note the advice to Auto format code in the IDE and to use code tags when posting code here as it prevents some combinations of characters in code being interpreted as HTML commands such as italics, bold or a smiley character, all of which render the code useless

Message exceeds 9000 characters

a.txt (127 KB)

Try to imagine that we have no idea what “my KR ICP” means.

Gahhhrrrlic:
Message exceeds 9000 characters

Have you heard of header files?

Heard of them yes. However I am a self-taught programmer and actually don't use them so I don't really know what you're talking about.

Then attach the code

It is attached in my post #4

Try to imagine that I have no idea what “my KR ICP” means.

It should be easy, because I don’t.

KR = Knock Retard: A phenomenon in combustion engines where an unstable high pressure wave develops in the combustion chamber, causing a resonant vibration in the metal components that can be heard by a microphone connected to the engine block.

The microphone wires are sampled directly, fed into a band-pass op-amp and then into the ATTiny85 where a Fourier transform isolates a particular signature knocking frequency and measures its amplitude. The Tiny then generates a CTC waveform whose frequency correlates to the magnitude of the knock. The ICP5 pin in the main program monitors that waveform and measures the clocks between falling edges. This number is used in the GUI to determine how much knock is occurring.

However this is tangential to the lag issue I suspect.

Gahhhrrrlic:
Heard of them yes. However I am a self-taught programmer and actually don’t use them so I don’t really know what you’re talking about.

I’m talking about seeing code that I need to see, and not junk that I don’t need to see.

I'm not sure what it is you are suggesting that I am doing wrong. If you don't like how I code, then I apologize. As I said, I'm self-taught and tend not to do things by the book... "just cuz". My coding style has worked well for me in the past but I can understand why it might be considered bloated to others. That's why, even for my own benefit, I comment as much as I can. This is also why I asked if there was a way I could show you a smaller segment of code so you don't get overwhelmed by the big mess you asked me for instead.

The other thing is, unless you have all the custom libraries I used, all the chips I used (and their sketches) and the same display I used, and all the simulated inputs I used, you won't be able to reproduce this effect at home anyway so my query is more about either catching something in the code visually or bearing upon the wisdom of people on this forum who simply know things and might pick up on this symptom I mentioned.

This is also why I asked if there was a way I could show you a smaller segment of code so you don't get overwhelmed by the big mess you asked me for instead.

The problem with a segment of code is there's no way to be sure if the problem is in the segment or elsewhere. The problem with a huge amount of code it it puts people off helping if they have to wade through it all to find the problem

The solution is for you to write a small program that demonstrates the problem. Often when writing this small program you find the problem anyway.

That's a fine idea except I have a gut feel that if I tried to reproduce the problem on purpose on a smaller scale, it wouldn't happen. This literally precipitated from changing 1 number from a 9 to an 11 and compiling. both pins are on the ADC multiplexer so... I really don't get why it broke things.

That's a fine idea except I have a gut feel that if I tried to reproduce the problem on purpose on a smaller scale, it wouldn't happen.

Been there done that. I had a problem whereby my code would crash at a very specific point; I got it to one line of code. As soon as I tried to simplify to find the cause the problem disappeared. I got there in the end, took about 3 months. My point is try anyway, you don't know where it might lead.

Are you aware of putting serial prints in to see if your code reaches particular points?

Oh yes, I’ve done that many times and it definitely helps. In this particular project, for reasons that aren’t trivial to explain, I can’t easily have a usb cable connected to my board when testing the effects of a revision I just compiled. I have to run it stand-alone as a black box, see the error, guess why it happened and try to correct it back on the PC side. That’s my own fault for not wiring the circuits up to make real-time debugging practical but… this is a clean sheet design so I guess live and learn?

TBH, despite the sea of code in the file I attached, it’s not too bad and follows a fairly linear progression in the main loop, which I commented in detail. The block of text containing the ADC polling call, which is the suspect line of code I changed, is part of the update_IO(void) function near the bottom. The BATT variable it’s stored in gets used in only a couple of places, namely painting the main status display, the power supply display and the diagnostic display. Other displays seem unaffected. And nothing is technically broken per se. The voltage reads fine. It’s just that the GUI is so slow that it’s unusable until I get a lucky touchscreen input through to cancel that screen.

Actually 1 further thing I noticed is that everything that involves an A/D seems to have floating values now where they were all pegged at 1023 before. It's like I woke up the ADC by changing that 1 line of code and now the ADC is bogging down the program or something. Is it possible that the ADC could be slow for some reason and why would it behave differently just because there's a non-floating value being read for a change?