Mpep; A reset would require starting from the begining, so I'd have to wait for initialization stuff to complete, but that may be the best solution. I have to ponder on that a bit more.
Srnet; That is what I thought from reading the various posts.
Goeytex; Doing my own polling may be the best compromise between useability and responsiveness.
Westaust55; That is pretty close to what I intended to do. The main loop will have perhaps 30 lines, including a count that will take one second to execute. This means that most of the time the button press will occur during that count. If I do my flag test right after the count, it would allow skipping the rest of the main loop.
Martin; All that would happen in the interupt routine I envision would be to sort out if the press was long or short, then set some bits in a flag byte that the main loop would use to change it's behavior.
All, thanks for your suggestions. I appreciate your willingness to discuss this without a sample of code and schematic diagram. 8^) One of my pet peaves is devices that don't respond quickly to user inputs. Unfortunately the one second count makes this tough. I even thought about breaking the count and flag tests into four parts, of one quarter second each and then summing the counts. This would get faster response for sure, but as Martin pointed out it would be messy. At this point I'll probably just do it as planned and see how it feels.
If there was a way to drop the stack and reset the interrupt system variables, that might have been nice, but your thoughts have help reinforce what I was expecting to have to do.
Oh yeah. The project is to utilize an air velocity measuring device that has been in my junk bin so long that I don't even remember where I got it. The original device used a capacitance sensor to detect the passing blades for counting. I only have the beautiful little mechanism part of the original instrument. I'm using fiber optic light guides to direct a light beam to and from each side of the rotor to detect the rotations. The impetus to get started on this after so many years is the acquisition of a neat little opto sensor made by Banner that uses light pipes. I've got it all breadboarded and working fine. Now I'm just getting the programming rounded out for easy use and addition of features such as changing units, doing running averages, and calculating volume flow rate associated with a user input flow area. It looks like the display from a very old QualCom cell phone will be the output device, and a pushbutton enabled rotary encoder knob the user input device.
Thanks again for your help. This forum is a great resource for experimenters. In my case, I only get around to a microprocessor project every year or two, so I never get to be a whiz at it.
tom