Why Hardware Gotta Make Me Love It So Hard?

Often when working on an electronics project I experience a problem that takes me way too long to debug.  I don’t mind iterative debugging, it’s where I’m partially hanging my hat these days professionally, but it’s painful how often my lack of experience leads me up a dead end.  The last time I got so angry I felt the need to write a post about it was an hour lost to software debugging when I had just crossed a couple of wires.

My more recent experience was with my EtchASketch project.  I rewrote the code several months ago so that it would draw persistent pixels on the display, then put it away over the holidays.  I got it back out a couple of nights ago and instantly remembered the last problem I had.  When drawing, the cursor was all over the place (so, for instance, drawing a horizontal line would have a lot of vertical jitter even if the vertical pot wasn’t moving).  I tried lengthening my sample time from 10ms to 100ms with no effect (other than missing pixels in my drawing from the overly-long sample time).  I started designing (software) dampening systems in my head.  I redesigned the project to display positional debug on the display as well as have a clear button to make debugging this issue easier.

Right before I started writing code, I realized the behavior I was seeing was actually really strange.  I could see having a little jitter when you’re moving the pot, but I was seeing jitter even when I wasn’t moving the pot controlling the direction I was seeing jitter.  After a bit of experimentation I found that all the jitter was being caused by the vertical-control pot, and the horizontal pot didn’t show the same behavior.

This video shows the behavior pretty well.  It starts with me doing horizontal sweeps with my hand completely off of the vertical trimmer and they look pretty good.  Then, starting at around 00:42, I clear the screen and do a horizontal wipe with my finger just resting on top of the vertical trimmer and it goes nuts and a big blob shows up on the screen.  After that, right around 00:56, after a last vertical adjustment the horizontal wipe results in a diagonal line, even though I’m not touching the vertical trimmer.

So, since I happened to have an identical contrast-control trimmer on the LCD (upper left, next to the display), I swapped them to see if it would help.  And it did.  Replacing the vertical trimmer made the problem disappear (the trimmer swap was the only thing that happened between these videos):

Such a simple solution, but it’s still unnatural for me to suspect that hardware might be at fault.  Really happy to have solved the problem as easily as I did though.

The one outstanding issue for me is what’s wrong with that trimmer.  Is it bad luck?  Do trimmer pots have a known life cycle?  Maybe trimmers (as the name implies) are supposed to be set-and-forget and my use of them as primary input devices was too much abuse?  Dunno yet, just happy not to be writing dampening logic for this silly little project…

More Character Display Abuse

A few months ago I posted about a project I was working on whose primary goal was to drive single-pixel drawing on a 16×2 character display.  Of course the real goal of the project was just to move forward with electronics, trying new things in both software and hardware.

Where Were We?

When last we left the project, I had just realized that my plan to draw (persistent) pixels on the entire 16×2 display wouldn’t work with the LiquidCrystal library’s 8-custom-character limit.  Here is a very abbreviated version of the 4 possible next-steps I set out for the project:

1. Make the drawing grid 2×4 instead of 2×16, just to get the persistent drawing working.  Add as much physical “bling” to the project as possible just to play with new stuff and multiple components updating in the loop.
2. Investigate overcoming the 8-custom-character limit inside the LiquidCrystal library.
3. If needed, investigate bypassing the LiquidCrystal library entirely to bypass the custom-character limit.
4. Investigate methods for circuit documentation, using this project as the guinea pig (emphasis on versionable files and multi-platform support)

Goals 2 & 3: Getting More Than 8 Custom Chars

The easiest thing to discuss is what didn’t work out.  I never spent any time looking into #2 or #3, but a commentor on the previous post left a link to an Arduino forum post that implied that 8-custom-character limit is due to the hardware itself, not the library.  That link, plus a little more googling, leads me to believe this isn’t a path worth walking down right now.

Goal 1: Multi-Pixel Drawing

I did decide that my itch for this project wouldn’t be properly scratched until I had persistent, multi-pixel drawing working.  By this I mean that you have a cursor of one pixel, and anywhere you move that cursor lights up and stays lit (unlike the last version, where the pixel could travel anywhere, but they didn’t stay lit).  I was able to get this implemented without too much pain.  Actually, the vast majority of the time I spent on this was debugging a hardware issue outside of my control that I didn’t have enough experience to recognize at first (quicky blog post later on that).

Also while working on this I added a clear button to the circuit and some positioning debug information to the display.

Goal 4: Documenting Circuits

I looked at a few different solutions.  I knew the name Eagle as it gets thrown around all the time.  I downloaded the free version and couldn’t even figure out how to draw on it.  Granted, I didn’t spend much time on it because I didn’t think it was going to be the right solution, but still…

I considered a few more-generic layout tools like dia, Graffle, or Visio, but none of them felt right.  I didn’t really want to use an X11 server on Mac OS X, which I would need for dia, and the others aren’t cross-platform.  I think I tried a few others whose names I can’t remember, but none of them felt right.

I had basically deferred this goal when, while looking at the Arduino docs and sample, I noticed they were made with Fritzing.  I downloaded it and it was exactly what I was looking for.  It saves in versionable XML, it’s very easy to lay out circuits, and it’s available for all three major desktop OSs.  I get the impression that, if I were an experience EE I would feel limited by Fritzing and prefer something like Eagle, but at my current skill level I’m happy to grow with the still-young Fritzing.

Real life...

Fritzing!

Now What?

Here are my new goals:

1. More bling!  My current ideas are a new button which changes between three modes (draw, erase, and invert); one or more LEDs which indicate the mode (which will possibly also be drawn on the extra parts of the display); and, more maximum bling, a piezo which clicks when the cursor moves.  Shouldn’t be too hard to bang out now.
2. I want to be done with this project.  To me that meant having the circuit documented, which is now done.  Also, I couldn’t just (easily) ditch the breadboard and use another because my only Arduino is physically attached to one of the two breadboards I was using.  Toward this end I re-did the project last night using only one breadboard.  This will allow me to just set the breadboard aside after accomplishing #1 above, though to be honest I think I’ll be done with this entirely at that point.  Love having it documented though.  Frankly, having the circuit in Fritzing was a large reason why I felt comfortable changing the layout to just one breadboard – I knew I had reference if I made a mistake

Here’s what the project looks like right now after being consolidated to a single breadboard:

Woo! I didn't change LCDs, that model supports RGB backlighting and I just wired it up to the red pin instead of the blue pin for a change.

This is so much prettier than the previous circuit...

Onward!

Fun For Young and Old

One of my goals for the 2011/2012 Christmas break was having fun stuff to do with my daughters to cut down on the boredom and minimize slack-jawed TV watching.  While planning this out I stumbled across the Wayne and Layne kits, and the Blinky POV kit looked really nice.  It looked like a great kit to use to teach my daughter Mary (5) how to solder – it didn’t have too many components, it looked like it would be fun to play with when it’s finished, and I’m really, really intrigued by the “hold it up to the screen” programming method.

Right before I ordered the kit my Mom contacted me and asked for gift ideas for the girls. I immediately suggested this kit for Mary and sent my Mom the link to the project.  She said it looked like a great gift for Mary (which I expected) and she also said she really liked the idea of the Tactile Metronome kit (which I did not expect). I couldn’t pass that up, so I bought both kits.

We decided that both Mom and Mary could learn together, so Mom brought the Metronome kit over with the intention of both of them working on it.  We started with soldering some resistors onto a junk PCB I got in an order from Evil Mad Scientist Labs.  I added these to an order (for free) on a whim last fall and they were perfect to practice with.  It’s very cool that EMSL offers them.  I did a resistor to show them the basic action, then they each did a resistor.

I admit, I forgot she was left handed when I set this up...

Read the rest of this entry »