Monthly Archives: March 2012

WyFly Shield off to a rough start

Here you see my new WyFly shield!  This little guy will one day bring Wifi capabilities to my Arduino… but not yet… not yet.

Thankfully there isn’t a lot of assembly required for the shield.  All you have to do is solder in the headers… which is easy enough… even for me! (see the evidence)

Out of the box, the libaries didn’t seem to want to work.  First there’s the “no such WProgram.h” issue which is easy enough to solve… you change the #include to “Arduino.h”.. but then there were some strange Arduino API changes with the Print object.  Nothing was terribly wrong… the write() methods now returned a size_t when before they were void.

Compilation out of the way… I uploaded an example… and nothing happened. I was supposed to see a google search result for “Arduino” scroll past on the Serial Monitor… but nothing.  Looks like more digging for me.

Controlling multiple LCDs from one Arduino

Taking the previous Arduino project a step further, I managed to get two LCDs independently updating from a single Arduino.  My original plan was to have 4 of them updating independently, but two of the cables that I made for connecting the LCDs to my breadboard somehow stopped working.  I suspect that 14-pin header stopped making contact with one or more of its pins.

You can see in the image to the right, how I constructed this cable.  It’s essentially a ribbon cable that I cut down 14-pins wide.  On one end I connected the 14-pin header and at the other, I connected a series of Molex connectors.  I chose the to break the wire into three groups of four pins plus a single group of two.  The group of two corresponds to the Power and Ground of the LCD.  The first group of 4 has the LCD’s RW, RS, Enable, and Contrast pins.  The final two groups of four end up being the data pins. (In four pin mode, only the second group of data pins are used).

If you look at the assembly from above, you can see that on the larger breadboard, I have a similar setup to my previous project’s setup.  Essentially, I have a 3-8 Demultiplexer and a Hex inverter.  The input to the Demultiplexer comes from the digital out pins from the Arduino and the outputs run through inverters.  I connect the inverted values to the “G1″ of the LCD which, when set to LOW disables writing to the LCD.  Since I know that the inverted output of the demuxer will only ever have a single line set HIGH, I can use it to select which LCD to enable.  The other LCD pins are all connected in parallel to the controlling pins on the Arduino.

#include <LiquidCrystal.h>

LiquidCrystal lcd(11, 9, 5, 4, 3, 2);
int state;

void setup() {
  pinMode(12, OUTPUT);
  pinMode(10, OUTPUT);

  // Pin 6 controls which LCD. If I had more than
  // two LCDs, I would need more pins to select them
  pinMode(6, OUTPUT); 

  state = 0; // Pin 6's value 0 -> LOW, 1 -> HIGH

  // Initialize the first LCD
  digitalWrite(6, LOW);
  lcd.begin(20, 2);
  lcd.print("I am Tweedle Dee!");

  // Select and initialize the 2nd LCD
  digitalWrite(6, HIGH);
  lcd.begin(20, 2);
  lcd.print("I am Tweedle Dum!");

void loop() {
  digitalWrite(6, state == 0 ? LOW : HIGH);
  lcd.setCursor(0, 1);

  state = 1 - state; // toggle which LCD to display on

The program itself was based heavily on the LCD Hello World example.  I changed a couple of pins around to be more convenient for my wiring… but the loop() function was copied almost verbatim.  The intent of the program was to have one LCD display “I am Tweedle Dee!” and the other to display “I am Tweedle Dum!” then Tweedle Dee will start counting all even numbers while Tweedle Dum counts all odd numbers.  As you can see here… it worked out fairly well!

PGM Class and Octave

About a month and a half ago, I signed up for an on-line class called Probabilistic Graphical Models in an attempt to learn a bit more about some of the math that we use at Topsy Labs.

The strange logo to the right is the Octave logo.  To quote the Octave website…

GNU Octave is a high-level interpreted language, primarily intended for numerical computations. It provides capabilities for the numerical solution of linear and nonlinear problems, and for performing other numerical experiments.

Based on that description, it makes sense that this and Matlab are the two languages recommended for this course.  Yeah. This means that I’ll be learning yet another language… but I’m hoping that octave will allow me to quickly generate cool visualizations for large data sets if not directly, then through gnuplot.

Layers of Detail with Blitting in SDL

Continuing with my efforts to learn SDL, I’ve drawn kind of a silly set of bitmaps that will be sewn together to form a landscape.

To the left you see a composite of 11 distinct images.  Each image falls into one of 4 layers, Foreground, Middleground, Background, Clouds, and Horizon.

The point of having multiple layers is to simulate depth in a simple side-scroller.  The “closer” the layer is to the user, the faster it’ll slide across the screen.  In the case of the “Clouds” layer, it has a slow but constant motion of its own.  In my simple tileset, I imagine the player to be somewhere in between the “Foreground” represented by the green/orange things stuck to the bottom of the screen and the “Middleground” which are the bent looking rectangular structures in the middle of the image.

For the programming part of this exercise, I’ve been simply following this SDL Tutorial.  That tutorial basically gets you a class that manages the lifecycle of your game along with the main() method.  I had a little bit of trouble getting this to work in OSX, but it turned out that I simply needed to RTFM.  If you’re trying this on a Mac, be sure to copy SDLMain.h and SDLMain.m from the “Extras” folder in the .dmg.

The lion’s share of the work in this SDL_BlitSurface(). This method is well described in the second SDL TutorialBlitting is really just the act of drawing one bitmap on top of another.

To implement layers as described above, I’ll create a class called an ImageLayer which takes an array of SDL_Surface objects (images) and an array of coordinates representing the upper left corner of each instance of the image sorted by X coordinates.  As the layer gets scrolled left or right, it’s a simple matter of keeping track of which image instances represent the extreme edges of what’s visible. All images in between these extremes get rendered.

With multiple ImageLayers populated with images and where they are, you render each layer from furthest to nearest.

Controlling 6 LEDs with only 3 pins

The Arduino Uno has something like 13 digital I/O pins and 5 analog I/O pins which can be re-tasked to act like digital pins bringing the grand total of 18 possible Digital I/O pins to work with… so what happens when you need to work with more than 18 different devices?  For example… what if you wanted to independently strobe 19 LEDs?

Here, I've connected 3 LEDs directly to the Arduino UNO's digital I/O pins 2,3 and 4. In this configuration, I could control at most 18 LEDs independently.

I’ve come up with a project which faces just such a problem… I want to be able to independently light up and update 32+ little 20×2 LCDs with a single Arduino.  To give a little context, each LCD has 16 pins, 8 of which are data pins.   This means that 8 of the 18 digital out pins from the Arduino must be used for sending data to the LCD.  That hardly seems like more than one could possibly be driven by a single Arduino!  Clearly, if my plan is to be realized, I need to come up with a scheme that doesn’t involve directly driving all the LCDs from the Digital I/O pins.

Remembering back to my Structural Computer Organization class, I realized the answer: Demultiplexing.

Here, I'm controlling 6 LEDs with only 3 pins through a 3-8 multiplexer. Chaining multiplexers together, I could control 2^N LEDs with N pins.

A Demultiplexer or Decoder is a component made up of logic gates that takes a combination of inputs and chooses a corresponding output.  Generally, for you can choose from 2^N outputs with N inputs.  Learning about them in class is one thing.. but actually sticking them on a breadboard is another.  I chose this Demultiplexer: the HD74LS138P.  It’s a 3-input 8-output multiplexer. It turns out, though that it works counter to how I expected it to.. instead of the selected output being high, the selected output was low and the other outputs were high.  When I hooked it up to my LEDs… all of the LEDs were on except for the one currently being selected!

Using a hex inverter, I was able to invert the outputs of the Decoder and make the selected output be on while having the other outputs stay off.

Ok… well, If I want the unselected outputs to be low while the selected is high, I need to invert the output of the multiplexer.  It turns out that there are little chips that have a bunch of inverters built into them.  The popular form factor seems to be the “Hex Inverter” which is simply 6 inverters crammed into a 14-pin package.  I ended up using a MC54F04 to do it. It seems like every semiconductor makes identical hex inverters, so Jameco‘s catalog just says “popular manufacturer”.  Anyhow, you can see from the photo to the left, using the inverters, we now have selected output being on and unselected outputs being off.

If you’re curious about the code that I used for this setup? Here it is.. It’s pretty simple:

int count = 0;
int values[8][3] = {
   { LOW, LOW, LOW },  
   { LOW, LOW, HIGH },  
   { LOW, HIGH, LOW },  
   { LOW, HIGH, HIGH },  
   { HIGH, LOW, LOW },  
   { HIGH, LOW, HIGH },  
   { HIGH, HIGH, LOW },  
   { HIGH, HIGH, HIGH },

void setup() {                
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);     
  pinMode(4, OUTPUT);       

void loop() {
  count = (count + 1) % 8;
  digitalWrite(2, values[count][0]);
  digitalWrite(3, values[count][1]);
  digitalWrite(4, values[count][2]);

In the setup method, we say that pins 2, 3, and 4 are assigned output roles.  In the loop, we increment our count variable and if the count exceeds 7, it gets set back to 0.  We then set our pins HIGH or LOW depending on the count’s offset in our table of values.   We also put a 1 second delay between loop executions so that the loop doesn’t happen too quickly to see.

One kind of annoying problem that I ran into while stringing up my Decoder was, it has 3 pins called G1, G2a and G2b which are effectively enable pins.  G1 must be HIGH and BOTH G2a and G2b must be ACTIVELY LOW in order for the demultiplexer to work.  I didn’t realize it and only connected G2a to ground… so naturally nothing worked because G2b was not actively being set to LOW (not directly connected to ground).  It wasn’t until I grounded both pins, that the decoder started decoding.