Software, technology, sysadmin war stories, and more. Feed
Saturday, July 2, 2011

Thinking fourth-dimensionally in EE classes

I had a class where we were supposed to do interesting things with a Motorola 68HC11 development board. This was a small bit of electronics with a microcontroller, a few connectors for power, a few more connectors for data input and some other things I don't remember. One assignment called for taking two four-bit numbers as input and rendering them in human-readable form on two seven-segment displays.

There were some fun parts to this lab. First, we only had 8 data lines leading out of our controller, but we had 14 things to control: 7 segments per display. Second, we couldn't use any other parts to generate the patterns which represented a digit. That is, the EVB had to drive each part of that display. Finally, we were only supposed to handle the numbers 0-9. While it was possible to enter something higher due to the nature of a 4 bit input (DIP switches), those were deemed invalid. We had to represent "error" somehow.

So okay, I started unpacking this problem. First up, 14 things to control individually with only 8 data lines? You just have to think fourth-dimensionally. The first 7 lines are wired to both displays. That is, pin 0 goes to "a" on both displays, pin 1 to "b", and so on. (You could mix them up, but why?). The trick is, you use that last pin, pin 7, to select which one of the displays you're addressing at that moment.

What this meant is that you'd either leave pin 7 low to select display 0 and set your values appropriately to send power to its elements, or you'd set it high to select display 1 and do the same thing. The fourth dimension comes in because while this does mean you're only really powering one at a time, you have a little while before they fade to the point of being noticeable, and your controller can refresh it well before then.

That addressed parts one and two, but what about that error state? The rest of the class handled it by having some non-digit pattern which meant "error". I think a bunch of people did an uppercase E or something like that, since it's halfway-human-readable. It also meant their program could be relatively dumb, with an array of 16 values and their error symbol repeated in the last 6 (for the values 10-15). Take your input, look up a value in the array, drop it somewhere, then feed it to your display every time through. It was... pedestrian.

That seemed so dull and boring to me. After all, here we were, spinning a tight loop, refreshing our patterns every time through, so why not make the most of it? I decided to have a pair of locations which meant "error here", one for each display. During my refresh loop, if it detected an error in the display it intended to update, it would switch to a different array with its own position index. In that array, I had stored a series of patterns which would make a pleasing animation. My display would animate, and a pair of segments would chase themselves around and around.

Lab day arrived. Our prof came around and started reviewing everyone's projects. His standard question was: what is your error symbol? I just said, it'll be obvious. He said, oh really? I just said "trust me" and stood back. He started flipping switches and poking, giving it valid numbers. So far, so good. Then he purposely put in an error.

*Spin spin spin spin*. My code did exactly what it was supposed to. He chuckled and said, you're right, it is obvious. I'd say he liked it.