• Keyboard Scanning Functional

    Kevin Arne • 07/11/2019 at 22:12 • 0 comments

    After getting some help at an Arduino/Raspberry Pi user group Meetup, I've made some significant progress implementing the keyboard scanning. Now I can get it to output the correct button that I've pressed.

    Wiring Issue Fixed

    When I first plugged it in, I was getting garbage from my keyboard scanning algorithm (nested loops energizing a row and reading each column). It was registering a lot of nonsense periodically, basically noise. It turns out I neglected to include a pull-down resistor on the ends of the columns, which meant my values were floating, causing it to randomly trigger. After soldering on some 10k resistors the problem went away entirely.

    Debugging Issue Fixed

    I was also having trouble debugging with the Keyboard library because it would spit garbage out into my IDE. Someone at the Meetup pointed out that I could leave off the Keyboard library until I really needed it. I feel a bit dumb for not thinking of that, but it worked beautifully.

    Next Steps

    So now I need to implement some debouncing, likely just a time delay, and some way to save the state of the keyboard so I don't send a bunch of the same key press every time. That all feels pretty doable, so that's what I'll be doing in the next couple of weeks during my spare time.

  • PCBs Have Arrived! Debugging Without the Serial Monitor Sucks

    Kevin Arne • 04/20/2019 at 02:14 • 0 comments

    PCBs Have Arrived

    They look good, well, as good as they were supposed to look given my design. I soldered the components on and have started programming. I could've started coding before, but I find that I'm less motivated to code when I can't test out the code.

    Early Coding Problems

    So it turns out you can't both print to the Serial monitor and use a Pro Micro as a USB device at the same time, or I'm just too ignorant to figure out why my Serial.print commands are being ignored. When I started to code keyboard scanning (pulling each row high, then reading each row to see which buttons are pressed), I realized that my schematic didn't really match my board layout, so I initially labelled my row and column pins incorrectly.

    Without the Serial monitor, I'm basically printing stuff using the Keyboard library and a text editor. This works ok, except I have to have the Pro Micro plugged into the computer to load new code, but it's spitting out debugging info whenever it's plugged in. The way I found around this was using keyboard shortcuts to upload new code (ctrl-u on Windows), and have the cursor on a line that's commented out so it doesn't mess up the code during compilation.

    On the next version of the hardware I'll just include a switch that disables the keyboard output, like a normal person.

    I'm getting a little unexpected ghosting (given that I'm using a diode for each switch), which I haven't really figured out yet. I noticed that @David Boucher used a 1 microsecond delay between pulling each row HIGH and reading the column pins in his keyboard build, so that's what I'll try next. I noticed that his keyboard is hooked up in the opposite direction of mine, but I haven't dug down deep enough to understand that choice yet.

  • Waiting on PCBs

    Kevin Arne • 04/09/2019 at 20:57 • 0 comments

    Ordered PCBs

    I'm currently waiting on PCBs that I expect in the next week or so. This version of the board has no chance of being the final product because it lacks any sort of text output device, doesn't have the wiring for a rotary encoder (I broke out some of the Micro's pins for prototyping that part), has haphazard spacing of the buttons, probably has poorly-sized traces, and totally lacks mounting holes. It's basically something hideous that I can start coding with.

    Current Issues

    Programming Interface

    At the moment, I'm not sure how I'm going to implement an interface that the average consumer could use. That's partially going to depend on whether I provide this as a diy kit or as a finished product. I'm going to shoot for the latter, but might fail my way into the former. Having users modify a header file for the Arduino sketch would work, but recompiling and flashing the code to the Arduino isn't going to be very user-friendly.

    Display

    I'm also not sure how I'm going to allow users to switch between macro keyboards. At first, I thought that color coding would make sense by adding some RGB LEDs behind some frosted acrylic, but that limits the number of keyboards to the number of colors people can easily distinguish between and their memories. Each keyboard could be named and displayed on an LCD panel near the rotary encoder (knob), but traditional LCD panels are big and don't match the aesthetic I have in mind. OLED displays either for named keyboard or individual buttons that say the key functions are another option, but far more expensive than the other two options. I'll likely try some version of all three and decide which I like best.

    Rotary Encoder

    Finally, I don't really know how rotary encoders work yet, so I have some research to do.