Bug Removal

“If debugging is the process of removing bugs, then programming must be the process of putting them in.” (Edsger Dijkstra)

(This post comes straight from Luke, as only he can describe the details of his work over the last few weeks. Stay tuned for his report of his meticulous work from the last few days.) 

The Debouncing Continues

 The prototype keyboard depends on a single button press triggering a single corresponding action. As any engineer knows, a project like this requires a lot of testing. However, testing in this case means pressing buttons many, many, MANY times. :) So what I needed was a test harness to push buttons for me! I read several posts online about people having similar bounce issues when working with relays. I tested a few on the oscilloscope and found that they bounce similarly to the buttons I am using for this project. The end result was that I was able to use a second Arduino to drive the relays in specific patterns, then monitor the inputs of the prototype keyboard controller connected to a computer to ensure the pattern is received without error. 

Shown above is the test harness circuit. The Arduino Uno is at the top of the image, connected to one of the MCP23017 chips that I have been playing with for The Styra Project. The MCP23017 is connected to a bank of eight transistors that drive the 12volt relays at the bottom of the image.

This picture shows the test harness connected to the button inputs of my prototype keyboard controller. The laptop is capturing the button presses and tracking any errors. When the test harness is running it sounds like a swarm of crickets in the garage. With the lights off it is like a scene from the Star Trek TNG Schisms episode.

Using the test harness I was able to diagnose several intermittent problems with my initial design. The first was that after five to ten minutes of pressing buttons, the prototype controller stops sending button presses. This was traced to an issue with the i2c bus and a lack of pull-up resistors on the signal lines. A second issue was found in my software debouncer that limited how well it would scale as I increased the number of buttons.

The prototype keyboard project is designed around the idea of assembling panels of buttons into modules that can be connected together.  Up until this point, my testing has been with a single panel, but to prove my design, I need to connect multiple modules together.  The above picture shows a total of five i2c devices connected to a single bus. This configuration supports up to 64 buttons, hardware or software debouncing and hardware interrupts. The oscilloscope is tracing the clock signal to make sure I have good values for the pull-up resistors.  I need to do further testing to determine if I can fine a single resistor value that will work for multiple devices or if I will need to build a chart of values to use depending upon the number of modules attached.

One final note, the gray button panel shown above is Phill's latest design from the 3D-printing side of the project. We had some initial trouble successfully printing larger parts, but Phill has spent many hours perfecting the process and we are now able to print designs the full width of the print bed. Phill made this design specifically to help with my testing as I needed the ability to connect (and manage) 16 buttons to a single module.  Phill is currently working on panel layouts for specific navigation and browsing functionality.  Picture coming soon!  :)