Driver for button

[sdalu]

Hi,

(I'm not sure if it is the right forum section to post)
I've started to write a component for handling switch/button, so to avoid having to write the same code every time.
It is handling debouncing, grouping 2 buttons to emulate a third one, and optionally generate dbl-click and longpress.

Could such a component be part of ChibiOS hal?
If so I could do more code cleaning. Hint in improving the code would also be welcome.

[Giovanni]

Hi,

It could have a place in EX if it does not use HW directly. Technically it is a board-level peripheral so it would fit. We need to create an abstraction of a general user-input system, what you described seems very specific.

Technically the problem is your use of RT "ch" API, HAL is not supposed to use that, only OSAL API.

Giovanni

[sdalu]

Having an abstraction of a general user-input system would be great. I'm not feeling doing it by myself, but would be happy to help.

[barthess]

There are too many ways to connect buttons to MCU to realize them in well abstracted driver. They may be connected directly, via shift register, via specialized IC, multiplexed in matrix, connected to single ADC input via different resistors (like joystick on Olimex STM32_103STK board), etc. They may be handled in interrupt or polled in low priority dedicated thread or something else.

[electronic_eel]

I think having an easy to use button driver with included debouncing and so on would be nice.

There are too many ways to connect buttons to MCU to realize them in well abstracted driver. They may be connected directly, via shift register, via specialized IC, multiplexed in matrix, connected to single ADC input via different resistors...

This is true. But having a driver for a directly connected button is better than having no driver at all. Other interfaces, like shift registers, i2c-io-expanders,... could be added at a later point. Either offering the same interface, or a different one if necessary.

[barthess]

It is not hard to create subsystem (I prefer to not use word 'driver' here) for directly connected buttons than handles debounce and broadcasts chEvents for press, release (probably double press and long hold). But all handling logic must be performed in user code (for example combining of 2 buttons in third virtual button).

I think it may be realized like dedicated thread updating all buttons' states every 20ms using provided function readButtonState(size_t N). This is easy way. The hard way is using of interrupts with timestamping in ISR and it requires huge amount of interrupt enabling/disabling logic. First way is more or less general, second is totally application specific.

Any other thoughts?

[Giovanni]

Good idea barthess, I would go even further.

Make it an object that looks like a serial port (channel interface), key presses would be translated in chars and put into the input queue with events. The module would exports one function that must be called at fixed intervals and implements the decoder state machine.

It would be very abstract, key presses/releases would be chars into the queue, the decoder function would be called at fixed intervals using any mechanism (thread, virtual timer, GPT timer or other).

Giovanni

[barthess]

@Giovanni
I prefer to use chEvents instead of queue because:
1) there may be more than 1 keyboard listeners.
2) sending ASCII chars instead of codes from pressed buttons looks nice but suitable only for press not release events.

[electronic_eel]

I think it may be realized like dedicated thread updating all buttons' states every 20ms using provided function readButtonState(size_t N). This is easy way.

May be easy. But Giovanni went to great lenghts to develop the tickless timer mode allowing to implement aggressive power saving modes without continuous wakeup for scheduling. Now you suggest wasting a lot of this achivement with a "simple" button handler running in a loop.

A common usecase for a button is a wakeup from a deep sleep mode. This would go hand in hand with a interrupt based button handler.

So I suggest using an interrupt based approach combined with virtual timers for debouncing.

I prefer to use chEvents instead of queue because:

me too.

[barthess]

Your variant needs dedicated interrupt pin for every button otherwise it is a chance to miss button press. But it is perfectly suitable for small amount of buttons.

Anyway, both variants may be combined. All buttons ORed externally (good IO expanders can do such work) and connected to interrupt pin. Interrupt wakes up thread. Thread runs 5-10 seconds polling buttons and than sleeps until next interrupt.