So it dawned on me that the TI MSP430G2 Launchpad Evaluation board isn’t very small and probably wouldn’t fit in any models smaller than G scale. I also realized that buying a bunch of the Launchpad Evaluation Boards at $10 is still cheaper than other alternatives, but not as cheap as buying the raw MSP430G2 chips by themselves (MSP430G2553 is about $2.50 for just the chip). Therefore I set out on an endeavor to figure out how to minimally power an MSP430G2 chip without the Launchpad Evaluation board.
Sometimes Linux is simple. Other times, its a PITA. As part of resurrecting a older laptop that hasn’t been used in a while, I needed an OS to go onto it. Lacking any Windows licenses, I returned to my roots of Linux. Ubuntu is the current hot linux distro and one that I am familiar with, so it was a natural choice.
One of the first things i wanted to accomplish was to get Code Composer Studio installed and working so I could continue R&D of the Launchpad. I’ve got a loooong list of things I’d like to research, develop and share, but seemingly never a proportional amount of time to do those things in. Heh, such is life.
Well I made the assumption that TI Launchpad development would be harder on Linux and so I unfortunately went looking for solutions before I actually had the problems. Spun my wheels for a good little bit, but in the end I realized that TI hasn’t written any USB drivers for CCS yet. That’s a kill for using CCS to upload programs to the MSP430 chips.
The fall back is the good old command line. Much to my surprise, using a text editor to write the code and cmd line to compile and upload the program was actually *easier* than setting up a project in CCS. As seen in the picture above, you need to enter 4 commands on the command line (Compile, erase chip, upload to chip, run on chip) and, voila, you’re program is uploaded to the MSP430.
Granted, there are still lots of things to work out and this was the simplest of tests. But it does lead me to think that CCS may not be needed for those who just want to download a compiled program and upload it to a MSP430.
So it turns out that powering a TI Launchpad off of something other than the USB Power (I dunno, say batteries?) is very very easy. All you need is to get a power supply that can provide anywhere between 1.8 to 3.6Vdc and then hook it up to the VCC(+) and GND(-) pins on a launch pad. So far, I’ve successfully tested this with a set of two AAA batteries (1.6Vdc x2) and also with a single CR2032 battery (3Vdc)
The only issue I can see is the minimum voltage required for some LEDs. For instance, high intensity Blue and White LEDs require a higher minimum voltage of 2.8V to 3.6V (avg 3.2V). Should battery supply voltage drop low enough, certain LEDs may fail to illuminate.
Between dealing with a terrible manager at work, switching jobs and the family being perpetually sick, all hobby dollars and time were sucked into the void. 🙁 The parts I ordered from http://futurlec.com/ finally arrived recently, so I finished up the initial attempt at building a light bar.
And it was a total failure. The 1206 SMD LEDs weren’t getting good connection and some where blowing out. So I scrapped it and started fresh.
I hit upon a decent manufacturing process and refined it in the build, so the current (2nd) prototype still needs improvement but is infinitely more stable than the first. Solder traces are not very tidy, wire management could be better, etc, etc. But it works and sure looks purty!
Last round of modifications to this project for a while. Rev 2 was pretty good, but the memory limitations of the MSP430G2553 chip posed a challenge: 512 bytes of ram! I was only able to get three flashing sequences plus the logic loops into that little memory. So another rework was needed.
Instead of using a byte broken down into 1bit/7bit status/time chunks, for Rev 3 I went with a hardcoded 50ms time chunk constant and used every bit in each byte as a status flag. Example: 00111100 would tell the logic loop that the first two 50ms steps are ‘OFF’, the next 4 steps are ‘ON’ and the last 2 are ‘OFF’. This allows me to compress 8 steps into one byte… an initial 8x memory efficiency increase.
The trade off to this is that counters like ‘CurrentStep’ are now moved out of the flashing sequence. Which, when you think about it, the notion of which step a sequence is on is not necessarily an attribute of the sequence itself, but rather a bookkeeping value by the logic loop. This increases memory usage however, stealing the thunder of my previous 8x decrease in memory use.
The overall effect is still a large reduction in memory use. Rev 3 ups the number of LEDs controlled from 8 to 11 (3 red, 3 blue, 2 yellow, 1 white takedown light, and 2 headlights.) as well as increasing the flashing sequences from 3 to 10 (Technically 15). The LEDs are also now grouped into 3 groups which allows for changing of the flash sequence on one group without interrupting the sequence of the other groups. Rev 2 had a ‘jitter’ problem when the sequences changed. Barely noticable, I think, but the power of my OCD compelled me to fix it.
The final feature enhancement is the concept of ‘Modes’. Currently, there are only two modes installed: Demo and Random. Demo will iterate through each sequence, spending about 8 seconds on each sequence. Random will pick a sequence at random and spend 2-6 seconds on that sequence. (Note: There is some room for improvement on the random chooser)
Anyways, code and how-to are posted below, so for now here’s a video of what Rev 3 can do: