AVR Freaks

For some debouncing code, wit handling of short and long key-presses, see: https://www.avrfreaks.net/index.p... (ultimately leading to http://www.mikrocontroller.net/a... )

But, surely, there aren't all that many ways that this can be done given a tick interval. There are two components, debounce and press duration. When a state change is indicated by the debounce, a timer ( a counter ) is started and when the counter is greater than a certain value, it is a long key press.

But... the code. The class Key ( this is C++ ) has two data members. The first m_val is a bit field of four bits and the second m_count is an unsigned eight bit value. When the Key::input() method is called, the current pin state value is shifted into the m_val variable. If m_val has changed and is equal to 0x0F ( FFVAL ) m_cnt is cleared, if m_val is 0 then a break event ( switch released ) event is posted. Then m_cnt is incremented ( only when m_val == FFVAL ) and goes through a series of comparisons. If m_cnt == 1, that is a short press, if m_cnt > 30, that is a long press. There are other conditions for repeated button presses.

There are some other features of the code, but that's a basic outline. Just what would be expected from standard debounce implementations, though it is in a somewhat more complex framework here.

Martin Jay McKee

Each Key object ( stored in the array keys[] ) is it's own unit. Key is a class... it just declares what something looks like. You have to create instances of classes ( objects ) to actually define storage. The important thing about objects, however is that each has its own storage, in this case for m_cnt and m_val. Also, if you look at the per10ms() method, the input() method is called on every key with two values, the current state of the pin and 'enuk' which is a KeyEnum, value... long way of saying that it is an "ID" for each key.

So, question #1, why is the count in the input call? Because the Key object is where the count ( m_cnt ) is stored. The actual timing is a combination of how often input is called and the count threshold values, but the input() method has the counter implementation because the implementers decided that it made sense to put it there ( how's that for an answer ). In this case, I would agree. Given the structure, why not make the same object handle both debouncing and timing on a key.

And, question #2, how do you know which key it was? I'd have to dig deeper into the code to explain it fully ( and I really don't feel like doing so at the moment ), but do you notice the calls to putEvent() in the Key::input() method? What is actually being sent appears to be modified by a macro ( all caps ) or function, and it takes as a parameter enuk. For instance, EVT_KEY_FIRST(enuk) is the parameter to putEvent() for a short press ( count == 1 ). The answer appears to be that the events ( and the keys they relate to ) are encoded to the uint8_t value by these macros.

I just had another thought ( and my previous explanation may be superfluous ) that what you meant was that, as there is only the ability to store a single event value, multiple button events could be lost. If that's the question then, yes, it looks like a problem. The timer code does not process the events so more than a single button having an event during a single check cycle will result in at least one event being lost. Of course, there may be a design reason why it doesn't make sense to handle multiple events at once.

Martin Jay McKee