Horrible lag from changing 1 pin assignment

Next step would be look to see where BATT is used.

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?

This doesn’t make sense. What do you mean by a ‘floating value’? The output from the A2D is an integer from 0 to 1023, that’s what the hardware spits out, nothing you can do to change it. If the input is floating then the value will be random but still between 0 and 1023. The data sheet tells you how long it take the A2D to do its thing, but it’s of the order of microseconds AFAIK, certainly not long enough to notice.

well BATT used to be 1023. Now it has a different value, so this possibly gets executed

    if(BATT < 200){                  // If battery undervolt generate a fault
      OCR3A = 40000;
      return;
    }

Is there something special to what happens to pin 5 driving some other behaviours?

what does “generate a fault” mean?

Oh that sends a fault code to a nano so it can speak the error (in this case the battery voltage is too low).

However the symptoms seem to suggest the problem is in the graphics routine somewhere. I mean I can see the screen painting 1 element at a time, during which I can't use the touchpad. This only happens on screens involving the battery so the BATT value going from 1023 to something else seems to be the correct line of thinking but perhaps not the fault system but the graphics. I just can't figure out exactly what about the graphics is slow and why.

Small development: I just changed my power supply to a 14V battery instead of the boost converter battery I had before and I guess the fact the battery is 100x bigger and not running through a frequency converter did something to the ground quality so now the error is only happening on the power supply display screen and not the diagnostic screen or the main status display screen. Odd but I'll take it.

Comment out one by one the code of the screen drawings related to battery to see how it impacts performance.

I guess it was as good a time as any to do that because the code block in that area is small enough not to be too inhuman to comment out line at a time. It looks like the problem is with the animated bar I create to depict the battery level. Somehow the battery level being small has produced a negative number for 1 of the coordinates or the bar size, which must be invalid as an argument for drawing a fillRect or whatever so it chokes when that happens. Not sure how it worked in the past (because it was working) but maybe it has to do with how I’ve refined the BATT variable from a simple 1024 number to an actual voltage without updating the graphics code. Good call JML.

Great you could solve it!

A good way to start the end of the year :slight_smile:

Start... the end... of the year.

What are you doing to my poor brain?