/*===============================================================|| Simplified menu test...|| /root|| |_uptime|| |_settings|| | |_Blink LED|| | |_d100 (delay for 100ms)|| | |_d200 (delay for 200ms)|| | |_d300 (delay for 300ms)|| | |_d400 (delay for 400ms)|| |_reset\\=============================================================*/
(2) Is there a way to create a hardware defined debounce for the buttons I am using? This would make my script a little bit more efficient. Maybe someone could just point me in the direction of a thread or blog that has a schematic I could use?
In order to poll and debounce eight inputs, the proper way is on each pass through the master loop (and if a new millisecond has since passed), to step through each index of the multiplexer, shifting in sequence the corresponding pushbutton state into successive bits of a byte value which then represents the combined value of the eight buttons.You then compare this value to the previous state which you read on the last poll; if it differs then you reset the debounce count variable to its maximum - say, 20 - update this new value as the "previous" value and complete this section of code (back into the main loop). If the (byte) value just read is the same as the "previous" value read, you look at the debounce counter to see whether it is zero or not. If it is not zero, this means that the value has not been stable for a full debounce period (20 milliseconds) so you simply decrement the debounce counter and complete this section of code.Finally, if the debounce counter is zero, then the value clearly has been stable for a full debounce period so you then compare it to the "last stable state" that you have noted (in a variable). If it is exactly the same as the last stable state, then clearly nothing has changed and you just complete this section of code, but if differs from the last stable state then you conclude that this is a new stable state which should be acted upon, so you examine and act upon each bit which differs from that last state, re-writing the "last" state to match the bit acted upon until the "last" state now matches the current state and you move on from there.The importance of this is that it debounces eight (extensible to essentially any multiple of eight) inputs at a time, such as the code I wrote to service the keyboard of the Tandy TRS-80 "color computer" back in the 1980s.
(3) Is the I2C address of the LCD screen fixed, as in will it always be 0x27 with the LCM 1602 IIC controller or can this address be changed? I cannot seem to connect the LCD over this address when I am using the pull up resistors on the I2C Bus. Please note that I currently have 3 I2C devices involved with this project and I expect the addition of more when it comes to providing safety features.
The whole point of using a microcontroller is that it has "all the time in the world" to "waste" doing such mundane things as debouncing. If you are using a menu, you are waiting for user input and pretty much by definition, not doing anything else, so you might as well pay attention to the debouncing.
Can't tell, as you have not illustrated what sort of "backpack" you are using on your LCD(s). Many (?most) have three address jumpers, either as solder jump pads - either two or three pads for each - or six apparently innocuous unused "thrus" into which you can solder pins and jumpers.
The buttons are also wired to ground. I followed the schematic from the tutorial link I shared. Only I wired the buttons to digital I/O pins 2-7
The backpack on the LCD is a Funduino brand LCM 1602 IIC.
I do see the address jumpers on the back and wondered what they were for. I guess that answers it... I contacted the supplier before about getting more information about this particular board as the download link for the datasheet on their website was broken. I'll need to try contacting them again or seeing if I could find another place/tutorial that has more information.