A Disoriented and Disorienting Post About Emacs, Windows 8, and Driving Displays from an Arduino

Today is shaping up to be a supremely lazy Saturday.  The tentative plans I had to go to the beach with Jack and Floramae fell through.  I spent the morning learning a few new things about emacs, the editor I use for 99% of my programming, but really and truly had no idea how powerful it actually was.  In fact, to get some practice in, I'm writing this here blog post in emacs.  Fun stuff.

A quick aside before I actually get to the point of the post (which will be about driving little LED matrices with an arduino): so I've off and on used emacs throughout my life.  Not a ton, but when I need to quickly edit text in the terminal, it was always what I'd default
to.  It wasn't until recently that I went full-bore, use-it-for-all-the-programming on the new computer I have at work. Now, if IDEs and Visual Studio and all the other hyper advanced tools we had these days actually did their jobs, I might not have ever ended up using emacs, which probably would have been a big loss.

So I've been setting up this new computer at work.  It's a beautiful Alienware Aurora R4 with a six-core, overclocked Intel i7 processor(s?), 32 Gb of RAM, and dual Nvidia Geforce 780i GPUs.  The thing is a monster and we're going to be using for image reconstruction.  There's  a snag though: Windows 8.  While more people in the world definitely still use Windows than anything else, there's a reason that lots of people are switching to mac and/or linux.  For about the first week of working to get this thing set up, I was determined not to just blame the stuff I couldn't get it to do on Windows.  I've never been a big fan, but I also have never been a big user so I tried to work on the assumption that it was my lack of understanding, and not the system itself.  

My beautiful new Alienware work computer

My beautiful new Alienware work computer

Without killing you with all of the details, let's just say that two weeks in, when Visual Studio had set itself up incorrectly (had not set any of its path environment variables to its compilers) and Cuda couldn't compile using nvcc, its dedicated compiler, and the Nvidia drivers were arbitralily limited the amout of data I could transfer to our 3 Gb GPUs to 800 Mb, I broke down.  Forget everything I had done so far configuring this thing, I needed to not be trying to work in Windows. A mixture of the system itself and my lack of familiarity with windows as an operating system just broke me.  I was getting errors that didn't make sense, I was hating the "start" menu in Windows 8, nothing from Microsoft seemed to be configuring itself properly, etc.  I had to switch to linux.  But even THAT was more difficult because of the UEFI boot signature deal that Microsoft has. 

Anyways, now that this short story is already long, I finally got
Ubuntu installed along with some twitchy Nvidia Cuda drivers so that I can
program with OpenCL, and even the worst shit I'm dealing with in
Ubuntu is further along and simpler than what I was able to do with
Windows 8. So the moral of that story is if you're on the fence about
trying to work in Windows 8, I have one word: DON'T.  It's not worth
it.  

I should also throw in that I'm actually not as unfamiliar with
Windows as I pretend to be in the previous paragraphs: I work
exclusively with Windows 7 for my job with Toshiba and while I don't
love it, it's not that bad. While I may not be a super power windows
user, I'm a lot better than most folks.

Ok, so that brings us back to Emacs.  Like I said, I've off and on
used it, and after the nightmare of trying to configure multiple
different IDEs to properly build and link all of my programs, I gave
up.  It's not that I don't like IDEs, I just wanted simplicity.  If I
had to write out a huge call to gcc, fine, but at least I would
understand exactly what I was doing and not have questions about how
and when the IDE was linking this and that.  I've been basically using
emacs to edit all of my source code and then using makefiles to build
it.  My use of emacs though is like someone who buys a corvette
to drive around a retirement home a 25 miles per hour.
I. had. no. idea. what. emacs. really. is.

Slashdot has recently linked to a couple of features about different
linux text editors and everyone always leaves out emacs and vim in
those discussions due to the enevitable "religious" war that breaks
out over them.  I couldn't help but think "really?" I mean, I like the
way emacs does code, but it's nothing that fancy, and that's partly
why I like it.

... And boy was I wrong.  

See, emacs can be as simple or complex as you want it to be, which is
really cool.  I will say that although I still want it to be my
friendly, simple text editor, I'm excited to start learning more about
what its true capabilities are.  I watch a video of a guy today
writing a spotify client that runs inside of emacs.  Wow.  So long as
it doesn't seem to actively inhibit my ability to get things done
(like Windows) I'll take it.  I'm still working on the keystrokes
though.  Jesus there are a lot of them.

Speaking of simple, easy to use things, Arduino!

(This post is all over the place, sorry about that. I've been meaning
to write for the last few weeks and just haven't gotten around to it.
Lotsa things going on lately!)

About a week ago I ordered the first electronics components I've
gotten in a while!  I got an Adafruit Boarduino, an Adafruit-boarded
small cell phone display, and a couple of other things.  I haven't
gotten to work with the display all that much other than to just throw
it on the breadboard with a few wires and run the Adafruit demo.  I'll
have more on my explorations with that hopefully soon.

What I've been working on though is two-fold: displays and learning
about writing arduino libraries.  Now that I'm programming in C more
and more these days, it's high time that I stopped writing shitty code
and actually learned a little bit about how to, you know, do things
like write a library and stash functions inside different source
files, etc.  

I've had two little displays I got a long time ago in one of the first
orders I ever placed from digi-key.  One is a three digit,
seven-segment led display (thing digital alarm clock numbers/letters)
and the other is a little 5x7 matrix of green leds.  On a day not
unlike today (slow, not a lot happening) I decided that it was high
time I got these bad boys up and running.

First, I worked on the numerical display, because I actually had the
slightest idea what the hell was going on with it.  It actually has 24
pins for driving (or something like that... 8 pins per digit not
including the decimal point) but if you're at all familiar with
Arduino, you know that you've got 13 digital pins, three of which can
be tricky, and six analog pins (that can also be used as digital if
desired).  So I knew that I needed to figure out a way to drive the
whole display essentially using 16 pins or fewer.  

I started by getting one digit up and running. Well actually I started
by using Ohm's law for the first time in years to figure out how much
resistance I needed to actually get the leds to light up.  (Usually,
with bigger LEDs one just needs ANY resistor to keep from blowing it
out, but these only require <100 ohms so... yeah... I was overshooting
it a bit when I started with 5k).  So once I had the resistance
figured out, getting one digit going was pretty easy.  It took eight
pins of the arduino: one for ground and seven for the different
segments of the display.  I wrote a few functions to display numbers
0-9 and once I had everything running, the only logical next step is
all getting all three digits going.  

To get the other digits to display numbers, we can't just hook them up
the same way.  In fact though, we're only going to need to use two
more pins on the Arduino and here's how:  persistence of vision.

Many things work on this principle, but basically the theory is that
after a light source turns off, it takes a short period of time for
the image to leave the human visual system.  We're going to turn each
digit on and off in quick sequence and when we do it quickly enough,
it will start to look as if all three digits are on at the same time.  

While the details are a little more complex, we basically just have to
connect all of the same segments across the different digits
(i.e. connect all three top segments to one another and then run one
wire from the connection to an arduino pin) and then strobe through
the three grounds.  Once we do that, sure enough, with a little
programming we can get all of the digits looking like they're on all
of the time and write cute little programs that count up and down,
etc.

Now, I know what you're thinking: this is boring.  Yes, it's like a
fishing story where only the fisherman actually finds it interesting,
but this is my website so I'm going to keep talking, because this is
the point where it gets really exciting.

So the seven segment display was fun, but other than displaying
letters and numbers, there's not a lot I could think to do with it. I
also didn't think that hard because I knew I had this other little
matrix display that was potentially much more interesting and I had
never touched. 

I'll leave the nitty gritty  explanation of how the matrix display is
set up circuit diagram and just give you this: each row is a cathode
and each column is an anode.  The cathodes are shared across all of
the leds in a row.  We can drive the whole display using only twelve
pins (or fewer if you actually know what you're doing unlike me).
Once I got the display lighting up and writing a quick program to go
through and turn on each led individually to make sure everything was
working, it became clear that writing the functions to make
this thing tick would be a hassle, and that I might also want to
integrate it into future project, so I decided to learn how to write a
little library. 

For those unfamiliar, a library basically allows you to alias a set of
steps into simpler commands. For instance, say I regularly need to
make all of the digital pins on the arduino low (0 volts) regardless of their
current state.  To do that in C I write:

//Zero all pins:
for (int i=0;i<14;i++){
    digitalWrite(i,LOW);
}

but it can get cumbersome having to type that every single time I need
to zero everything out.  Why not just be able to type "zero" and have
it happen?  That's exactly what we do.  In our library we type
something like this:

void zero();

void zero(){
     for (int i=0;i<14;i++){
          digitalWrite(i,LOW);
     }
}

and then, once we've been sure to include our library in our program,
whenver we need to have all of our digital pins be zero, we just type:

zero();

and low and behold, that call aliases over to the library where it
finds our code for what to do.

It isn't always necessary to write a separate library for functions
because they can be defined inside of the main program, but I'm not
the biggest fan of the arduino IDE and the display stuff was getting
ridiculous (functions to zero everything, functions to display
numbers, functions to wipe different states, functions display the
state of a matrix, etc.) and having all of it inside of my program was
getting tedious.  Basically I was having a hard time finding stuff.  

What program was I writing? Why, one-player pong of course!  Which is
not super fun to play on a display this small and is entirely predictable
given the dynamics that I've programmed, but still really fun to
create and learn about this display with!  I wrote my entire pong
program without the library and I'll upload the source code and link
to it.

After programming pong, I wanted to do a cute little implementation of
John Conway's the game of life and this was where I realized I needed
to write a library.  The library allowed me to focus on the
G.O.L. code in my program and just call display functions when
needed.  Lines and lines of code were reduced to things like
"d.disp_current_state()" and "d.disp_number(45)." This really cleaned
evertyhing up and made for a much neater main.c (or whatever arduino
uses... .ino?).  I'll also post the code and then link to it from
here.  It's an interesting comparison between pong and game of life to
see how things kind of grew and moved to different layers of
abstraction.  

My display stuff is not that good.  In fact, the matrix display has
dim pins the further away from the origin you get (bottom left of the
display) if many of the leds are on, and it can get downright twitchy
sometimes, although I've been working on that.  

Most displays actually have a dedicated driver chip that actually
handles the writing of each pixel but I use the arduino directly.  I
don't think it quite qualifies as "bit-banging," but it's close.  The
arduino spends most of its time looping through a command that just
displays the current state of the "world" and then every so often gets
interrupted by a function that actually calculates the new state of
the world.  It then defaults back to the main loop of displaying the
newly calculated state.  I think I've set the interrupts to occur
about 15 times per second for pong on "hard" mode and maybe 7-8 times
per second for the "easy" mode.  So we essentially have two frame rates:
the display frame rate (which I couldn't tell you, but pretty decent)
and then the game frame rate, or the rate at which the state of the
game world is updated.

I'm kind of curious how much you could push this setup until you
simply make too many demands on the single arduino; both of my
programs are very simple and the world updates are minimally
demanding.  I'll be you can get away with a lot more than you'd
think with a setup like this.  We'll just have to see. 

I've included the circuit diagrams in this post and links to my code
on Github (including the little library I wrote).  If you want use
something I've done, you'll need to use the same pin configurations,
or update the code to suit however you wire things (it's probably
easier to just use my wiring...).  

5x7 Matrix Display Circuit diagram can be found here.

Here's a link to my github page.  All source files can be found in the j_arduino repository.

I'm going to start playing with the adafruit display I got (48x84
pixels) but that may take a while because my cats somehow got into my
organizer and lost the level-shifting chip.  Stupid cats.  I don't
think they ate the thing, but I cannot for the life of me find it.
Seriously.  Of all the things they felt to need to play with that
night, the night I got that display! I didn't even get a chance to run
more than the demo.  

How could you possible be angry at us for eating your level shifting chip??

How could you possible be angry at us for eating your level shifting chip??

Speaking of cats, I may or may not be adding a separate page that's
just shameless photos of them.  We'll see.

Anyways, all of this exploration has let Jack and I to begin
discussions of building our own retro video game console... and not
just like those pansies that run an emulator on a raspberry pi.  We're
talking all the way down to bare wires. 

<3,
John