Dear Ladies and Gentlemen, my fellow crawlbots…

Hello there,

to not keep this release of information from the author of the original content, this post will make an exception in language and appear in English language on this blog. I may translate it some time, but thats rather unlikely (remember my promise to fix typos in my short stories?).

So… whats this about? Let me start my story a bit in the past. If you don’t want to read all the bibble babble, skip to the tech part way down there . A while ago, I played with Atmel Atmega Microcontrollers (µCs) during some summer internship at a local university. I did some rather boring stuff like a IR remote controlled Boat with a range of about 0.2m in daylight – not even enough to surf your kitchen sink. Some other project in that internship was about a serial bus based on RS232 which was multi-node capable and long range (9k6 at 4km with symmetric signal on bare insulated jumper wire). I was not considered capable of taking part in hat project, so I had to take the boring task – whch – because it lacked purpose – was no fun at all.
Some weeks ago, a friend of mine came to me, intoxicated by TI’s relatively new MSP430 development kit, called “Launchpad“. Its a fully featured development environment for the value series MSP430 µCs, no external hardware needed to start development – all that at the price of 4.30$ (what a coincidence ). He asked, if I also wanted to order some and I took two – guessing that if equipped with such nice and efficient gear, I could finally regain all the fun that I expected and vainly longed for in that internship years back.

The TI Launchpad

Defining the task
When the devices, that were in backorder nearly 2 months, finally arrived, I found the blog of  Kenneth Finnegan, a college student in his early 20s. He also gave the MSP430 a try on the launchpad and designed a minimalistic low power clock, that uses only 2 LEDs (or one dual color led) and a button for user interaction (a 3-state switch is added for setting the time). I liked that project and I am currently looking for discreet nerdy stuff for my living room, so I wanted to adapt his design and make it fit my needs – thereby learning the basics about the device and its features. Find his source code in the linked blog post. Since its written in clean and commented C, its quite easy to read, even for the inexperienced programmer.

Even though both designs are quite minimalistic, a bit of adaption was needed:

• Kenneth wrote his code for the compiler supplied by TI while I was going to use the mspgcc4 (find a good tutorial for setup here), a free and open source port of the GNU gcc to the MSP430 series of µC. Interrupt definitions and some includes had to be fixed, but it was much less work than I expected.
• Since Kenneth designed his clock for 12h clock format, that had to be changed to 24h format – the time format used here. This actually saves some bytes of code, which I didn’t expect.
• Kenneth designed his clock to be fully interactive – meaning: If you do not press the button, the clock itself will  not show the time. I at least wanted to show the time on relevant events, e.g. every hour. Because this would reduce battery life quite a bit, this features should be fully configurable.
• Kenneth’s code lacked debouncing for the button. Since this is not a huge problem on the launchpad, I decided to add this only after designing my own board (using a horribly bouncy but nice push button).
• Kenneth’s clock lacked a power reserve for battery changing (after looking again and asking him about it, we figured, that his noise filtering capacitor supplied enough power for changing the batteries – low power clock it is ). Since punching in the current time is quite annoying and the lifetime of the battery is until now unknown, increasing the size of this capacitor was also a task.
• I thought, only “one” LED and a button, drilled into the post of my living room storage rack would be nice and discreet enough. Kenneth designed his clock to stay in a closed box, so he would need the clock mode switch on the outside, while I was going to use an open design with the PCB tied to the back of the rack post. I would only need a 3-pin jumper, which would save a hole in the rack post.

Technical Overview
Before we dive into the nitty gritty, I want to give you a short overview about what I’m going to do and about what I will achieve by that – or at least want to (At the time of writing, all tasks are done and the clock has been attached to the rack, so success assured ).
Kenneth Finnegan designed a clock, that uses 2 different colored LEDs (in his design combined in a dual color LED) to tell you the current time just when you want it. It uses color coded flashing sequences, to display the individual parts of the time. First hours, than minutes. The three combinations of color (green, amber and red) are assigned values (10,5 and 1) , that you have to add, to get the individual part of the time. <amber><red><red> <pause><green><amber><red> for example would be 7:16, which would during work days be the latest time to get out of bed without getting LARTed by the boss – for me at least. This clock design has its nerdy charm, so I will adapt the design, add some features to the code, that I think are missing, and build it into a post of my living room rack. Additionally, I will design an exhibition style face mask with instructions for visitors, so that they are able to use the clock (and hopefully be amazed or confused by its simplicity). So far, so good. But where to start?

Code adaption
Knowing what to do, I started with the code. When I was starting, I hoped that Kenneth’s code would compile using the mspgcc out of the box, but it didn’t. The mspgcc recommends another include scheme and will not include device specific headers, but subsystem specific ones. The device-type is supplied during the gcc-call instead and in-header defines take it from there. Additionally, the Interrupt- and according ISR definitions’ syntax differed.

Kenneth’s includes:

#include "msp430G2101.h"

My includes:

#include <io.h>
#include <signal.h>

Kenneth’s interrupt definitions:

#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void) {
...
}

#pragma vector=PORT1_VECTOR
__interrupt void Port_1 (void) {
...
}

My interrupt definitions:

interrupt(TIMERA0_VECTOR) TIMERA0_ISR(void) {
...
}

interrupt(PORT1_VECTOR) PORT1_ISR(void) {
...
}

After modifying the original code that way, I was able to get the code running on my launchpad. Great, isn’t it? The clock was not running, though – and not flashing at all, when I pushed the button. I searched the code for strange optimization issues but did find nothing. After a short moment of deep resignation it came to me by itself: I forgot the quartz. I read something about a low frequency fallback inside the MSP430, but at least, with this code, it didn’t work. Since there was a quartz for clock-generation (32.786Hz) shipped with the launchpad, I was saved. After soldering it onto the fresh launchpad, Kenneth’s clock performed the hell out of that MSP430. Since I was new to that device, I studied code flow and how everything worked. The code was very easy to read and written in clean C with nearly no shorthands and black magic (thank you for that Kenneth). I instantaneously understood, how waking up and putting the unit to sleep worked and was able to understand interrupt handling in only 10 minutes.
The first modification I made in terms of function and use was, to move from 12h to 24h format. This saved some bytes of code and in my opinion makes the time more easy to read. The 12h Clock has some advantage, though: The hour never reaches 0. This is a problem with this clock, because the presentation system does not allow for a separator between the hours and the minutes, so within the 24h-system, the times “0:14″ and “14:00″ would be very hard to distinguish. I tricked the 24h system by the same means like the 12h system does. The hour from 24:00 to 01:00 is presented as 24:xx.
Kenneth used only 5 of the 8 I/O Pins, the MSP430 Value line usually has. I thought that I could make use of the other ones – or at least some of them. This was the second modification. Since this device has more the character of an exhibit than any actual use, I thought, it would be nice, if the device would draw attention to itself from time to time. Since that would be a huge drawback on battery life, I wanted to make the features associated with that configurable in hardware. I used two I/O pins and tied them to GND via a jumper (the same way, the original code does this with the mode select switch). P1.4 controls display of the time at every full hour, P1.5 controls the display of the minutes, every full 10 minutes. Code for that was inserted the same way, the push button time display works and was kept out of the ISR, to prevent second incrementing from being missed while the time is shown.
The last modification of the code was fixing the debouncing issue. I failed a bit on that task, but it worked fair enough to work with the button, I finally decided to use (after wrecking 2 different models while soldering). I used the code that was already in place and facilitated the P1IN Interrupt and the TIMER Interrupt, to get the µC to ignore button presses for a while, after a button was pressed. To do so, I added code in the PIN1 ISR to store the current timer counter plus a defined value modulo the timer top end (32768) to a variable. Before any action, this value would be compared to the current timer counter and if not enough time would have passed, no action would follow and the ISR would return with no work done. In the timer ISR, I kept track of overflow handling. That whole thing did not work so well for the button I used, because even when pressed firmly, it would bounce like hell (also while being held). After all and thanks to my supreme soldering skills, it all worked out fine .
So much for the code modification. Get your copy here: Sourcecode

For Kenneth to know: I left your Top of file comment intact for attribution.

// 2010 Kenneth Finnegan
// http://kennethfinnegan.blogspot.com/
// Two color blink clock running on MSP430 controller
//
// Ported to mspgcc and modified for 24h mode
// 2010 by Joel Garske
// http://blog.jpoetry.com

Choosing Hardware
I chose to use the shipped MSP430G2231, simply, because it was already sitting on the launchpad and I am really lazy. around that, I used the schematics from Kenneth’s blog. The only two things I modified were:

• Increased the electrolyte capacity to 2200µF
• added 2 jumpers to GND on P1.4 and P1.5

Routing this on a striped breadboard was not hard, but needed some consideration, to use as few wires as possible. I also did not use 2 AA batteries. Because of the size, I decided to stick with the good old CR2032. I took the battery cradle from an old motherboard I had at hand, as well as the quartz, the jumpers and the DIP14 socket. My hardware workshop is not that well equipped as many others. For the connection to the “peripherals”, I decided to use pressure terminals, that can take bare wires.

My custom board (yes, I already noticed that the black wire is too short...)

After assembling that piece and testing it, I was ready for the next part.

Assembly and mounting of the components
As I already mentioned, the devices peripherals were to be placed inside a post of my living room’s furniture. Since I am prepared for late night intruders, I own a battery driven drill. The kit of wood drills instead I had to search for about an hour. Since searching stuff makes me very tired, I at first designed the face mask for the clock and thought of a nice name – tribute to Kenneth .

Front mask - in the last two lines, you can strike out the "not"s, if the corresponding jumpers are set and the mask is laminated

The circle marks the place, where the LEDs should be visible later and it is exactly 6mm in diameter (at 300dpi), to hold 2 3mm LEDs. Later, I (not joking) accidentally placed the button exactly in the right height to match the arrow on the left .After marking the spot for the LEDs, I started drilling. Since the button should sit on the side of the post, I had to drill a channel from the side and another one from the back, where the wiring should be connected, connecting to the other one. That also worked very well, even though I feared, the post would break (who knows – maybe it will, later). I am ashamed to say, that I did not measure or mark a single spot for that button.

Drilling holes for LEDs and button - the two upper holes are for the button

After that, I went back to my desk to build the wire harness. I decided to use a common ground for button and LEDs, which was proven to be a bad decision later on by my stupidity.

Connecting the LEDs to the wiring harness

I had to cut off he small frame on the bottom of the LEDs body to get them into the 6mm hole. After wrecking the push button I used for the testing board (a nice big red push button like on old arcade consoles, just a bit smaller), I decided to stick with the cheaper one. When I was done with the harness, I attached it to the rack post.

Button and LEDs in their place

The button looks fine on the picture, but it is not. even though it perfectly fits into that hole, I managed to destroy it, while soldering the wires to the contacts. The button would not even move anymore. Since I decided to fixate at least the LEDs, I went and got the hot glue and filled the LED hole … front… and back. When I thought, I was filling the LED hole backside, I really was filling the push button hole backside, which was a total mess, because I had to take the button out again and replace it. This would get hard with the hole filled with glue… :/. I cut off the button and drilled the hole a second time. After fixing the button, I was nearly done.
I laminated the front mask, removed the glue spill from the post and attached the mask. After finishing that, I was ready to give my new clock a try:

The clock in action

Well done! Thanks again Kenneth for introducing to me the MSP430 and its basic features and as well for inspiring me for this great nerdy exhibit.

Greetings from Germany,

The starseeker