This is a classic example of polling versus interrupts. I've used this example here before:
Suppose you're setting up a fire alarm system for the Empire State building. There are 100 sensors per floor. The controller in the basement visits each sensor and reads whether there is a fire (1) or no fire (0). The sensor reading is reported back to the basement after each sensor read. The "round trip" takes 1 second to report from a sensor. When sensor #100 reports, the code reads sensor number 1 on the second floor. This process repeats until all sensors for all 108 floors have been read. The process then starts all over again on the first floor. This is a polling alarm system.
Now suppose your luck is such that sensor #100 on the first floor burst into flame just as you read sensor #1 on the second floor. By the time you re-read sensor #100 on the first floor again, the fire has a 3 hour head start. You'd be surprised how miffed people get when they have to wade through 10 floors of fire on the way to lunch.
Now suppose instead that each sensor has the ability to send a message to the basement the instant it detects a fire. The fire would be known in 1 second. This is how interrupts work. Except for all but the most trivial programs, interrupts will always yield a more responsive system.
When writing ISR's, just make sure that 1) you don't use any functions that themselves use interrupts (no delay() or Serial.print()'s), 2) keep the ISR as short as possible, and 3) declare any globals used in the IRS with the volatile type specifier.
Jack, W8TEE
On Saturday, January 11, 2020, 5:02:40 PM EST, Joel Caulkins/N6ALT <caulktel@...> wrote:
Thanks for explaining your changes Mark, it makes sense now and explains why the display flashes every time the digits change also. All in all, it's working pretty good now.