As some of you may know, I have developed several arduino open-source libraries, phi_buttons, phi_prompt, phi_big_font,phi_morse, phi_super_font, etc.
My main focus is to interface arduino with inputs such as buttons, keypads, etc. and outputs such as LCDs so a project developer doesn't have to through all the trouble to create these themselves. I've been successful with these libraries so far but I'm not completely satisfied with how contributed libraries are maintained.
The reason I developed these codes is that the current status of contributed libraries is that each library is managed by an individual and in order to say use a matrix keypad and a couple of rotary encoders, you need at least two libraries and they follow different conventions and you are expected to learn different things with each new library you come across. And most of them don't even support hold-and-repeat! Not to mention lots of them are no longer maintained and are left to rot. There has to be some common basis among some of the libraries so a general expectations are met, such as each keypad library should have a getKey for getting a key press regardless who wrote the library, through inheriting from a common interface.
Here is what I've just done in the past few weeks, using what I already had as basis:
I've made a new library called phi_interfaces library. At the moment it contains classes such as single buttons, matrix keypads, analog buttons (essentially a keypad in nature), rotary encoders, and liudr keypad, plus some nice things shared by these classes.
To write a project, you just need to include one library, the phi_interfaces.h, and you can create objects such as single buttons, matrix keypads, rotary encoders etc and they all behave as expected.
The matrix keypads, analog buttons (keypad in nature), rotary encoders, and liudr keypads (or any other future keypads) are all inheriting from multiple_button_input, which has a function called getKey, same as the popular keypads library. Any of these objects can provide buttons pressed with this function. They all support hold-and-repeat and essentially can support my multi-tap codes if they have at least 10 number keys. If you are interested in expanding this interface to a different type of keypad, say a capacitive keypad, all you have to do is to write a sense_all() code to provide the interface a handle to sense all possible buttons and give an immediate status. All the debouncing and status changes are handled by interface functions and eventually by the getKey. So even a library developer will save time by not having to write their own debouncing etc. while we can all contribute to the polishing of these basic codes.
This also makes my library expansion much easier.
The buttons class is a subclass of the single_button_input class (interface). The interface has a few functions, sense() being the most useful function. Any classes using this interface will need to implement this function so they can be controlled the same way.
Future development will support IR remote, PS/2 keyboard, etc under the multiple_button_input, which will all support the getKey method.
Attached is an organization chart for the classes. Any suggestions?
Blog page:
I know only two types, the always-off, common to GND ({3,2,0,1,3,2,0,1,3}), and the always-on, common to GND ({0,1,3,2,0,1,3,2,0}), both have detent. At the moment one can choose one of the two by changing the line in the library. I can certainly make an option of this. I'm expecting the user to stick with one type, instead of finding random parts and hodgepodge them together 