Mechanical rotary encoder on an S08 via TPM/KBI & push switches question?

[iansmusical]

Hello All,

I'm wanting to interface a mechanical detent A/B output rotary encoder with a built in switch to an S08 but am not sure of the best way to do it in terms of software. Having read previous forum postings I have learnt a lot but not enough to actually implement the software. I would prefer to use an interrupt method as opposed to polling but where I'm struggling is how and where to implement the necessary debounce delays? I'd welcome code examples or anything to get me started :-)

On a related note does anyone have examples of push switch code using the KBI module to achieve simple push detection, press and hold/repeat, key press and release detection or if not any websites that show the theory of operation for such features?

Interestingly I've not really found any relevant reference material, app notes, design notes on the Freescale website to show such solutions :-(

Thank you in advance.

Ian

[egoodii]

You will find it much easier to implement a 'polled' quadrature decode, even if that is on a 'timer interrupt', in the range of every 1 to 10ms.  As long as you are sampling 'fast enough' that only ONE of A or B can change between polls, then all you have to do is sample both A and B at the same time (on the same I/O port), and thence the 'state change' of the two bits, compared to the previous sample, will ALWAYS give a correct count-change, no matter HOW much it 'bounces', and your count can only 'dither' by 1.

[iansmusical]

Hi Earl,

Thanks very much for your reply much appreciated.

The method you have described makes sense and would probably be best running from a timer interrupt. Can you explain further the debouncing strategy, perhaps with a pseudo or real code example? When you say about the count dithering by 1 is this jitter/creep?

Thank you again,

Ian

[egoodii]

There will be no 'creep'.  As long as you are sampling 'faster than the quadrature rate' there will always be exactly one differing edge at any one sample.  If the sampling is 'dithering' on one edge, then the count will keep going up and down by one, but it CANNOT creep sampled this way  -- and that is the fundamental advantage of this approach.  Now the question of 'debounce' --- what does this quadrature 'do' and what are the effects of 'bounce' -- so, for instance, if it just scrolls up and down a menu, then the exact 'bounce' as it flies up or down during a step is of no matter, only where it stops.  Now this assumes that your mechanical input device has a 'detent' that helps it 'rest' between quadratures, so that once 'let go' the inputs are assured to 'settle down'.  If not, then no 'debounce' will ever stop that last jitter,  One thing you can do is 'squelch' any change <2 until stable >50ms.  Now this all assumes you are looking to count all four quadrature edges.  We had one case where the 'dial encoder' had detents all right, but they were AT one of the signal-change points.  So one option there (as we chose) is to treat that input merely as a 'direction indication' in your samples, and only 'count' on changes of the other input (using the direction indication then to say whether rising is 'up' or 'down' in count, and vice-versa).  Half the counts/rev, but at least stable!

[egoodii]

Attached is the 'main loop' of a code set we use for 'general front panels', using a small S08 like SH8 or GT16.  As set up, it allows three encoders, a key matrix, and a couple 'switch tree' inputs, all as user-input options.  This doesn't have any explicit 'encoder debounce' as our usage didn't require any (used for things like volume, and menu scrolling).