Yes, I’ve once again rearranged (and in some cases, rewritten) the entire Keyglove codebase. It was totally worth it, for reasons I will outline in a moment. Before I do, I want to get to some housekeeping stuff.

This is the first of a few could-have-been-backdated posts which chronicle the developments in the Keyglove project’s recent past, but which I didn’t write about at the time they occurred (oops). This miniseries of historical non-fiction covers the past 13 months or so, starting around the beginning of November 2014. “Over a year, again?!” I hear you cry. Indeed, and I apologize for another long period of silence—even though it fortunately wasn’t totally devoid of progress. For an extremely brief explanation, here’s a list of the “life stuff” that has happened during the same period of time:

  • Bought a house
  • Had a child (which is to say, my wife did)
  • Moved into the aforementioned house
  • Employer got bought out by Silicon Labs
  • Unexpected family medical issues
  • Took a new job opportunity at Cypress

I had no desire or intention of staying so silent, but…well, I’ll just say that it’s been quite a year.

Okay, back to the stuff you came here to read.

My adventure with this huge refactoring endeavor started with a bug that I couldn’t figure out. It made zero sense, and the behavior changed without any detectable reason based on seemingly unrelated code changes. My announcement to the world of this fact came in the form of this tweet:

After continued troubleshooting yielded no progress, I eventually posted my predicament to the Arduino Forum.

I am running into a problem which seems to have to do with the code execution pointer, and the behavior makes zero sense at all. There is a conditional statement which doesn’t match, and since the code it controls is only one line, I omitted the surrounding { } braces for brevity. This is a pattern that I have reused many other times all throughout this fairly complex project without any observable bad consequences. However, when I let the code run this way, execution apparently stops at that line…

Three pages of sometimes maddening miscommunication or misinterpretation later, I got a startling revelation when the patient and wise Nick Gammon pointed me towards a pre-written resource he put together quite some time ago on Arduino project structuring.

This was a big surprise to me, because the last I’d heard, Arduino’s IDE imposed some pretty weird restrictions on code structure (one of its presumed weaknesses), including that you could only have typical .cpp/.h source/header file pairings in included libraries, from the official “Libraries” folder. This meant that the main project had to be one .ino file and a big collection of header files, each of which actually had a both declaration and implementation code inside (typically a bad idea). Nick’s guide proved that this was an incorrect assumption on my part.

After no small amount of work completely restructuring the whole Arduino project, I had all of the code back in line with conventional organization, and the inexplicable bug disappeared. Nick Gammon is my hero.

I pushed the massive commit to the Github repo as soon as I got it to compile and function as well as it had before the refactoring started—except for the fixed bug, of course. In addition to that fix, the new standardized code structure allows me to avoid some really strange “workaround gymnastics” that I had to include before. The order of #include lines in various places had been extremely delicate, with way too many compile-time dependencies built into the order of those lines. The new code is much safer, more obvious, and more forgiving. Three cheers for collaboration!

8 Comments
  1. Glad to see you’re still around. Recently the resurgence of VR and AR hype has had me wishing for a keyglove.

    • Thanks for checking in! The Keyglove project is very much alive; my current prototype controller is on my desk, plugged in and ready for the times I can jump back into the project for an hour or two. It’s amazing how difficult that can be with everything else I have to get done. I “just” wrote the blog post above, but now–BAM! Two weeks later. Incredible.

      Stay tuned for more updates. There is some exciting e-textile stuff in the works.

  2. I am enthralled with this project. Please keep me updated

    • Thanks, Kevin! I’ve continued to be way beyond occupied with work and family responsibilities, but the project is still alive. Technology has evolved around the original design, and I’m considering more compact/efficient platforms for some of the hardware now, but the basic goal is the same.

  3. The way of the future…

  4. I just ordered some stuff to do Isolation milling at home, and am gonna start using the Voltera printer as well. I can do prototypes pretty quick like this. It relates to other work things regarding sensors, etc but all to be worn, or close to desk.

    I like the concepts, and I know it has its pros/cons.. but I hope to continue to follow the progress.

    If I can help in any way then let me know.

    Maybe I could 3D ink print you a test board, or CNC a PCB if you need just 1… it shouldnt be a problem.

    I hope all is well,
    Mike Guidry

  5. I still have very fond thoughts about this project, even after all this time. I was a Kickstarter backer.

    • Thanks! I, too, remember it fondly. Readily available technology and my own skillset are improving every year, and I think the design still has promise for many applications. I see a new similar design pop up from time to time, with the most complete one recently being the Capto Glove. Although I was too naïve and overly ambitious during the Kickstarter project; e-textiles were always the hardest part, and they’re still not easy. I never tossed out the materials and development work. The latest hardware is still in one of my project drawers on my main workbench. Maybe someday…

Leave a Reply