Under the Hood of the LaunchPad Challenge

A few weeks ago we sponsored the 2010 ITA Fall Challenge. It was a great opportunity for both us and the students, but to sweeten the deal we gave out some pretty slick swag. (See the previous post on Something Unimportant for background on the puzzle.) Today's post will be a bit more in depth, including some code and a walkthrough for anyone who didn't finish it.

The instructions we gave out with the kits were very simple, "Plug in the USB cable to power the board up and see what happens." This is where the fun begins. The LaunchPad comes with two LEDs on the board. We preloaded some code they immediately started to flash. Decoding the pattern is the first step in the puzzle.

Did you figure it out? No? Alright, here's the deal, the red light represents the beginning of the sequence and the green light is printing out Morse code. If you take your time and write down the pattern you should have come up with VCC TO PIN 1.4

Launchpad_small

Don't worry, we didn't pass out bare boards. We put headers on and tossed a bunch of wires in each kit.

If you spend a minute looking at the board you'll notice both VCC and P1.4. Connecting these two pins with a wire causes the LEDs to start printing out a new message. Writing out the dashes and dots, you should have come up with TINYURL.COM/37C5S8E.

The tinyurl above should take you to a secret Github account that was created for the LaunchPad Challenge. Now that the contest has ended the ita2010 repository has been moved to the official Centro Github account.

If you followed all the instructions in the README you should now have a second binary running on your MSP430. The source for this new executable (prog2.elf) can be found here. It's really not much different than prog1.c, in fact, it's simpler. It doesn't watch any of the input pins and it's been stripped down to only contain one message. Now that you've got the source you've probably noticed the message is actually a phone number. This number is connected to a Google Voice account we setup with a pre-recorded greeting congratulating the winner and asking for their email address.

Ok, enough of the boring details of the contest and onto some of the code. The following C is about as simple as it gets. This was mainly due to the fact that I wanted anyone to be able to recompile these examples regardless of their platform. Initially I had written prog1.c to use the Interrupt Service Routine (ISR) to detect the connection on P1.4, but I knew the pre-processor on a Windows machine wouldn't handle this the same way the setup on my Mac does. Without the ISR the interaction for the user is less than desirable as it might appear slow or laggy depending on where in the code you are when the wire is connected. On the other hand but the code remains quite clean and is therefore much easier to follow. If you're up for it, try to modify prog1.c to work with the ISR. It's really not too hard, I promise.

The meat of both prog1.c and prog2.c can be seen in the Gist below. This is an excerpt from the main function and is responsible for continuously pumping out Morse encoded characters.

The "#" character isn't actually part of the message. It's used as a marker to make it easy to determine when to flash the "starting" LED. Hitting a null terminator (\0) tells the loop to reset the pointer and start over. The only catch is we need to reset the pointer one extra space back because the next operation immediately moves the pointer one space forward. Finally, the default, when we have a real printable character.

Also included in the never ending for-loop above (only in prog1.c) is the following snippet which is responsible for checking the state of P1.4 and appropriately switching out the messages.

The only catch is comparing the value of currentState with state. This is done to make sure we only switch messages when the state has changed. Without this check the message would end up being reset to the beginning on every iteration and the user would only see the endless blinking of the "starting" LED.

The one thing you may have noticed in the first Gist, and referenced elsewhere in the code is the delay function (implementation seen below). It should be noted that simply burning clock cycles to cause a delay is probably the worst possible route one could take. This was done here to help ensure the code could be compiled anywhere, under ideal circumstance a timer based around an interrupt would be used.

Check out the code on your own and see if you can figure out how the ASCII to Morse lookup table works. Feel free to fork this and make it better or even turn it into your own contest.

And as always, we'd love to see what kind of stuff you're doing with your MSP430's so post comments or send us an email.