mowcius:
Remember to debounce the buttons... that's the major pain normally.
It is?
I normally just use a while(button == HIGH){} to wait until it goes low again before it does anything.
Depends on the application really though.
Actually depends on the buttons... with the cheapest kind of buttons, this would fail.
maniacbug:
mowcius:
I normally just use a while(button == HIGH){} to wait until it goes low again before it does anything.
As long as you're willing to wait for the 'up'. That feels like input lag to me, so I usually use 20ms debounce.
with cheap buttons, this could also fail, and adds a bit more to the code. Either because you halt the processor during 20 ms, or because you need to run a timer to check this.
So the way to go, is really a mix of quality buttons, some debounce tecnique in hardware, either with the capacitor or some gates (there's an application note somewhere about this) and some software to check it. Depending on the buttons you use, you may need one or none of the others... but since this will be a generic library, you have to think of most, if not all, possibilities regarding the buttons.
I implemented this (with a 16x2 or 20x2, not sure now) with menus, submenus, and a 8 key keypad for a coffee machine about 10 years ago. And back then, the major problem was the debounce because we used some top of the line buttons (1,3 euro each) on the prototype (the customer decided on those because of the incorporated LED, feel and size with interchangeable keys) and debouncing didn't even cross my wildest dreams... until, because of cost concerns and because the key would pop out when pressed, they decided to go with cheaper buttons... and the nightmare began. LOL
But if you use those normal Omron type keys you might get away with little worries about the debounce. The best to do, get an oscilloscope, a few buttons and test them to see what happens and create a debounce strategy then.
Just a thought, get the program to run as a state machine with methods to move level (sub-menu) up, down and enter. That way, the library could (but wouldn't need to) have the button code included, but it would make it easier to adapt if you'd like to use a blackberry tracker ball or a small joystick, for example.