¿ªÔÆÌåÓý

Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod #v6


Jack, W8TEE
 

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.

Joel
N6ALT

--
Jack, W8TEE

Join [email protected] to automatically receive all group messages.