Steve and Peter,

DEJA VU
- - - -
If he is using Pin A into INT0 as a non-polling trigger, that Pin B takes care of itself due to the grey-code of its output. It will be stable by the relative time that Pin A transitions as you described.

I'd still debounce INT0 in this scheme and use the interrupt to schedule the debouncing. Pin A near its transitions can still bounce near the edge. If this were an automotive application, I would moe fully utilize the grey code sequence and a motor running could setting off enough vibration in the dial near a Pin A transition to cause real problems.

The problem I have with this approach is that there is no null state to track actual turning to deliniate transition jitters. I'd be more inclined to use the INT0 interrupt to start debouncing both PIN A&B inputs until a timeout period. I'd poll via a scheduling interrupt. Would it be necessary to turn this debouncing on and off based upon the INT0? Probably not unless the micro was really doing a lot of computations.

DEJA VU
- - - -
I'm sure we all discussed this about 4 to 6 weeks ago at an early design phase. As all have mentioned, there are many suitable techniques that can be used.
My preference is to squeeze out every bit of performance out of any component I buy into a design even though this often complicates the coding process. I enjoy coding - so I'd want every bit of resolution I could get out of the dial at the tasker level and let tthe machine pass it on to the Man-Machine Interface (or Human-Machine Interface) to make the decision how much resolution can be tossed for the ergonomic factors of the dial. Its easier to round off after carrying forward accuracy than to re-design an interface if it proves later to be inadequate.

And... its more fun to increase the challenges. :)

DEJA VU
- - - -
-Jay C. Box