Tag Archives: microcontroller

Review: TI’s High-Power LED Driver Evaluation Board

On my desktop, I keep a list of miscellaneous parts I’d like to buy at some point (e.g. power resistors, laser diodes, etc).  Parts not destined for any specific project, just things that I’d like to toy with.  Well for a long time, I’ve wanted to get my hands on some high-power LEDs.  I suppose I’m just a sucker for pretty lights.  But for some reason, I’ve never gotten around to ordering any – probably because I’ve never had a good means of driving said LEDs (and I’m too busy lazy to make my own driver circuit).

Well last week Farnell (Newark in the States) came to my rescue with an offer to send me any product from their site (within a certain price limit) for free.  All they asked of me was an evaluation (this post) and a link to the product on their site.  And which product did I pick?  The TPS62260LED-338, a three-color LED driver evaluation module:

TPS62260LED-338This board hosts three 500mA LEDs (W5SM) from OSRAM.  Each LED is driven by a TPS62260 step-down DC-DC converter.  A low-cost MSP430F2131 microcontroller controls all three drivers via pulse-width modulation.

Out of the box, my first impression: these LEDs are painfully bright (especially that red one – my vision is still spotted as I type this).  They’re not kidding about protective eyewear.  But I wouldn’t want it any other way. 🙂 For most of my testing however, I simply covered the LEDs with about four sheets of paper.  That brought their intensity down to a comfortable level.

I must commend TI on making this board very easy to use and probe.  They’ve provided several nice wire-loop test points for connecting scope probes.  And they’ve even broken out the power and ground connections for people like me who don’t have the proper barrel connector power supply.  I was also pleased to see how they’d integrated heat sinks for each of the three LEDs into the PCB itself using a plethora of plated drill holes.  In operation, the board only just becomes warm to the touch.

But let’s talk about the real highlight of this board: the LED driver circuits.  Because LEDs operate within such a tight voltage range (their operating voltage is actually assumed to be about constant), they’re normally powered by some type of current controller (since the brightness of an LED is proportional to the current flowing through it).  Any yet, this board features three DC-DC voltage converters – devices which take a high input voltage and convert it to a lower output voltage.  So how is this supposed to work?

Well, each converter IC provides closed-loop control over its switching output.  In other words, the TPS62260 measures a feedback voltage and uses this to adjust its output duty cycle.  So regardless of how much current (well, up to 600mA) is being drawn from the output, the converter is able to maintain a fixed output voltage.  But here’s the tricky part: you can attach the converter’s feedback measurement input pin to anything (within reason, of course).  In this case, TI has wired each feedback pin to a 2Ω current-sensing resistor (part R9, below) connected in series with each LED.  Each converter will adjust its output in order to maintain 0.6V at its feedback pin (as 0.6V is the internal voltage reference of the converter).  Using ohm’s law, and realizing that the current will be the same in both the sense resistor and the LED, since they are in series, we can determine the LED’s current to be I = V/R = 0.6/2 = 0.3A or 300mA.

LED Driver Schematic

But wait, the current-sensing resistor is fixed, the converter’s internal voltage reference is fixed… so how do we control the current delivered to the LED?  Simply put: we don’t.  Then how can we control its brightness?  Pulse-width modulation.  Imagine flipping a light switch on and off so rapidly that you can no longer detect a flicker.  Then, adjust the ratio of the on and off times.  The longer the on time, the brighter the light will appear.  This is precisely what the MSP430 microcontroller is doing to control the brightness of the LEDs.  In fact, you can see this happening if you wave the board around rapidly while one of the LEDs is being dimmed (in this case, the blue LED):

Pulse-width modulation in action!

That image was captured with a 0.1s shutter speed.  And actually, with that knowledge, we can calculate the frequency of the PWM signal.  I count about twelve blinks of the blue LED there – so twelve blinks in 0.1s yields a frequency of 12/0.1 = 120Hz (a result I confirmed with my IOBoard oscilloscope).  If you’d like to read more about pulse-width modulation, check out my previous post on the subject.

So out of the box, the microcontroller on this evaluation board is programmed to slowly turn on and off each LED in sequence, such that one LED is always fully on while another is being ramped on or off.  This produces a very pleasing color gradient.

Now, according to the manual that came with the board, you’re also supposed to be able to turn the knob on the board in order to manually adjust the color balance.  Unfortunately, this feature did not work for me.  When I turn the knob on my board, the automatic sequence stops and the LEDs hold their current brightness states.  However, they do not change brightness when the knob is turned further.  I’ve probed the knob (which is actually a digital encoder) and believe it to be working properly.  My guess is that somebody just botched up the software.  It happens.

This brings me to my final point of discussion: reprogramming.  The TPS62260LED-338 provides a JTAG header for the traditional four-wire JTAG programmer.  Unfortunately, I do not possess such a programmer.  I was hoping instead to use the MSP430 programmer which is integrated into my LaunchPad development board.  Sadly, I never checked into the details: the LaunchPad programs via the two-wire SpyBiWire (SBW) interface, not the standard JTAG interface.  And of course, the MSP430F2131 does not support SBW.  So for now, there will be no reprogramming.  Of course, thanks to all of the convenient test points, it’s fairly easy for me to just put the micro into reset and drive the LEDs using my own PWM waveforms.  If anyone out there has any tricks for reprogramming though, please let me know!

So in conclusion, I’d say the TPS62260LED-338 is a product worth checking out.  For just over $20, it’s a pretty good deal.  If they’d given it the USB programming interface of the LaunchPad, I’d probably be happier, but then they would’ve needed to lower the current draw of the LEDs, which would’ve been no fun, or required a separate power supply, which wouldn’t have been such a big deal.

Explaining the XMega XPlained (Dev. Board)

About two months ago, Atmel announced a smart new set of AVR development boards, the XPlained series.  One of these boards (which I’ve just recently purchased for $30) boasts a shiny new AVR XMega microcontroller.  What?  An XMega you say?  Why yes, haven’t you heard?  Come now, they’ve been around for fully three years at this point.  Well, don’t worry if this is fresh news, you’re not alone.  For some reason, adoption of the powerful new XMega MCU has been slow amongst hobbyists.

The XMega Xplained (click for high-res goodness)

When Atmel introduced their new XMega series of AVR microcontrollers back in 2008, I was pretty sure they’d be a quick sell.  Even in spite of their unavailability in DIP packaging, and this cheesy marketing video.  But sadly, a quick search of Hack a Day currently yields only four articles containing the term “XMega” (versus more than three hundred articles for “ATMega”).  I guess change is hard.  And yet, it’s really not.

The XMegas utilize the same AVR core as the ATMegas, and are fully supported by the free AVR-GCC compiler and AVR Studio (obviously, I guess).  Plus, you can still use your trusty AVRISP mkII programmer to load code onto an XMega.  In other words, the tool-chain is unchanged.  So, with a few register name changes, code from an ATMega will run perfectly well on an XMega.  Sadly though, the XMegas and ATMegas are not pin compatible, so you won’t be able to solder a new XMega onto your Arduino.

Alright, so for those of you keeping track, I guess I’ve now listed three strikes against the XMega which may help to explain its present unpopularity: no DIP packaging, no pin compatibility with the ATMegas, and changes to register names (plus the addition of new registers for new features).  Oh, and odd marketing tactics.  By the way, as a side note, it could be argued that the XMega register scheme is better than that of the old ATMegas.  They’re making good use of structs, so that you now address a port’s direction using PORTX.DIR, rather than DDRX.  And you output to that port using PORTX.OUT.

But let’s now take a look at the data in favor of the XMegas, yes?  To do that, we’ll compare the ATMega1280 (utilized on the Arduino MEGA) against the ATXMega128A1 (utilized on Atmel’s new XPlained development board):

Feature ATXmega128A1 ATMega1280
FLASH Memory 128KB 128KB
Max CLK Speed 32Mhz (PLL) 16Mhz
EEPROM Size 2KB 4KB
RAM Size 8KB 8KB
Voltage Range 1.6 – 3.6V 2.7V – 5.5V
ADC 16, 12-bit, 2Msps 16, 10-bit, 76.9Ksps
DAC 4, 12-bit, 1Msps N/A
USARTs 8 (one supports IrDA) 4
Hardware Encryption 128-bit AES, DES N/A
Timers 8, 16-bit 2, 8-bit and 4, 16-bit
Current Draw, 1Mhz, 1.8V 365uA 500uA
Event System Yes No
Price $10.20 $16.13

Not bad, right?  I’d say the XMega wins this round.  It’s faster, provides substantially better analog to digital conversion, offers digital to analog conversion (in other words, analog outputs – a feature not available on any ATMega), hardware-based encryption (again, not found on any ATMega), lower power consumption, and, wonder of wonders, a lower price.  I’m quite impressed (for what that’s worth) and am particularly excited about putting these new analog features to the test.  In fact, as I mentioned, I’ve just received my XPlained development board and have already written a quick test program to do ADC → DAC pass-through.  But I’ll describe my experiences with the XPlained board a bit later (spoiler alert: they weren’t all pleasant).

So what precisely does the new XMega series offer that makes it, in my opinion, such a substantial improvement over the ATMega series?  Let’s talk speed for a moment.  The old ATMega topped out at 20Mhz, at least officially (though overclocking is possible, as seen in the Uzebox gaming system).  But furthermore, there is no way to adjust the system clock on the fly (although you can, of course, adjust peripheral clocks).  You’d have to make fuse adjustments with an external programmer.  With the new XMega series, you can adjust the system’s clock frequency at run-time.  Both a 2Mhz and a 32Mhz internal RC oscillator are provided, plus a PLL which allows for clock multiplication (1x, 2x, 3x, …, 31x).  According to application note AVR1005, you can even use the PLL to increase the clock speed of your peripherals to a maximum of 128Mhz.  This might be useful for generating high-resolution PWM signals, for computing precise time intervals (think range-finders), or for just blinking an LED really really fast (although perhaps not this fast).  Man, I could’ve used this on my MS thesis

Another neat feature of the XMega series is the brand new event system which allows for high-speed signaling between peripherals.  This is not a communications bus in the traditional sense.  It’s actually more like a set of, shall we say, “personalized” interrupts sent between features.  Event signals can be sent quite rapidly – in no more than two clock cycles – and don’t require the CPU to be active.

The XMega Event System

The XMega’s event system opens up a whole new world of possibilities.  With it, you could tie a set of 16-bit counters together to form one highly-accurate 32-bit counter.  Or, how about this application note example:

You could use one event to synchronize two modules. For instance, you could use a pin change event to do an ADC conversion and an input capture on the Timer/Counter to get exact time-stamps for each conversion.

For more details on the event system, see the “Getting Started with XMega” application note AVR1005 or the “Getting Started with the XMega Event System” note AVR1001.

First Impressions of the XMega XPlained Dev Board

Alright, well let’s get down to business here.  As I mentioned earlier, I’m now the proud owner of a brand new Atmel XMega XPlained development board.  I was putting in an order with Digi-Key the other night when I thought to search for XMega products (yes, shame on me, I haven’t tried them out until now).  I found just one, but it was precisely what I was looking for: low cost ($30.16), USB-powered, and covered in blinking lights (well, nine of them anyways).  So of course I bought it.  I mean, it’s not quite as much of a steal as the $4.30 TI Launchpad, but even at $30, I didn’t even bother to do research before adding it to my cart.   I just figured it would work.  🙂  Bad idea, I know…

So what did I get for my money?  A pretty padded box and the board itself.  Nothing more.  No documentation whatsoever, only a printed messages on the outside of the box requesting I go online for any required drivers and data.

XMega Xplained Unboxing

Now the lack of paper is fine with me; if Atmel wants to save some trees, good for them.  I’d have gone online for datasheets and schematics anyway.  My only gripe here is that Atmel’s site isn’t all that easy to navigate.  In fact I don’t think I ever located a link to the ZIP file associated with AVR1927 (instead I just crossed my fingers, manually typed in the assumed link, and bingo).  But maybe I’m just bad at the internet.  Well for the sake of centralization, here are a few URLs I found helpful when getting started:

The XMega XPlained comes pre-programmed with a cute little application that blinks its nine LEDs and plays different sounds (drums, trumpets, etc. – just one- or two-second clips) when each of the eight different buttons are pressed. And I’ve got to say, the little speaker actually impressed me with its sound quality.  It’s not exactly a M-Audio studio monitor, but it’ll probably hold its own against a speakerphone.  And it’s certainly not being driven by square waves; they’re making good use of the XMega’s analog outputs (DACs).  So what else does the XPlained offer?  Well, here’s the official list:

  • External memory (8MB SDRAM, MT48LC16M4A2TG)
  • Atmel AT32UC3B1256
    • Communication gateway
    • Programmer for Atmel AVR XMEGA
  • Analog input (to ADC)
  • Analog output (from DAC)
    • Mono speaker via audio amplifier
  • Digital I/O
    • UART communication through USB gateway
    • 8 mechanical button switches
    • 8 LEDs (plus one bi-color LED)
    • 8 spare analog pins
    • 24 spare digital pins

Programming the XPlained using FLIP

So the pre-loaded software entertained me for about sixty seconds, after which my desire to reprogram the board overcame my fascination with lights and sound effects.  I didn’t have my AVRISP mkII handy (left it at work again), so I started by looking into reprogramming via the board’s USB connection.  The first thing I needed was a driver for the virtual COM port (Windows 7 did not recognize the XPlained), a single INF file:

USB CDC Driver (Virtual COM Port) – required for USART communications.

I was pleased to find that the instructions provided in the “Getting Started” guide (AVR1927) for using the Flexible In-System Programmer (FLIP) for RS232 programming were quite simple.  I downloaded and installed FLIP via this link.  I also had to import an XML configuration file (provided here), although it sounded like this file should have been included in the latest FLIP installer.  But before adding this file to <Install Directory>Flip 3.4.xbinPartDescriptionFiles, I received an error stating that “the device does not exist” when using BatchISP (the FLIP command line utility).  I also attempted to use the FLIP GUI directly, but for some reason the RS232 communication option was greyed out.  No problem though, I simply threw the programming commands given in the instructions into a simple batch file:

batchisp -device ATXMEGA128A1 -hardware RS232 -port COM25 -baudrate 115200 -operation onfail abort memory flash erase f blankcheck loadbuffer c:xmegatestdefaultxmegatest.hex program verify start reset 0

pause

I’ve highlighted the elements you’ll want to change when using this file.  Including that pause command causes the command window to wait for you to press a key before closing, that way you can take a look at the results of your programming attempt:

FLIP (BatchISP) Command Line Programmer

So using BatchISP (FLIP) worked just fine for me.  The whole programming process took a bit longer than I would have expected (maybe 20 seconds), but it’s not terrible.  The one catch is that you have to unplug the XPlained board, and then plug it back in while holding down switch SW0, every time you want to reprogram.  This is required in order to activate the bootloader.  Doing this gets old fast, and it didn’t seem to please my computer (it would occasionally freeze for a few seconds when the device was quickly plugged back in).  But there is an easier way; keep reading…

Programming the XPlained using the AVRISP mkII

So based on the literature I’ve run across, it seems the preferred means of reprogramming (and debugging) an XMega is via JTAG using either the AVR Dragon ($50), the AVR JTAGICE mkII ($300), or the Cadillac of debugger/programmers, the AVR ONE! ($600 – perhaps this is the reason for the exclamation point).  The new XMega series uses the PDI (Program and Debug Interface) programming interface (as opposed to ISP).  However, it is possible to use the AVRISP mkII programmer (though you cannot use it for debugging), which costs just $35.  And if you’ve done anything with AVRs in the past, you’ve probably got one of these hanging around (I should note that the original AVRISP, the one with the DB9 port, will not work with the XMega series).

Now, to get your AVRISP working with the XMega Xplained, you’ll need to create a simple pin adapter.  You cannot connect directly to the board as the pins are arranged for a 10-pin JTAG connection (I guess Atmel really wants you to use JTAG).  However, you’ll only need to connect four of the six pins present on your AVRISP, as shown in this diagram (found on page 9 of the XMega “Getting Started” guide, AVR1005):

AVRISP Pinout Comparison

These pins can be found on the XPlained’s JTAG connector, as shown in the schematics:

XMega XPlained JTAG Connector

Once you’ve made these connections, you can use AVR Studio to reprogram your device as usual.  Well, almost.  First, you need to make sure it’s fairly up-to-date (I used version 4.18, build 700 with success, but you might go straight to AVR Studio 5, which I’ve also tried with success).  You’ll then need to manually specify the ATXMega128A1 before programming or adjusting fuses.  Plus, and this is key, you’ll want to disable the JTAG interface by using AVR Studio to clear the JTAGEN bit on the fuses tab.  If you don’t, your programming may or may not be successful.  I actually got into an interesting cycle where alternate programming/read events would fail.  I’d perform one operation successfully, but on the next I’d see “Entering programming mode…FAILED.”  But disabling the JTAG interface took care of this issue.  And doing so does not prevent you from re-enabling JTAG later, or from using BatchISP (though you may need to reload the bootloader if you’ve erased it, which may be found in this ZIP).

For more details on programming and debugging an XMega, see this article (and actually, check out all of these “Getting Started with XMega” articles, they’re quite good).

A First Test of the Analog I/O

Now I think I’ve stated this already, but again, I’m pretty excited about the new analog I/O offered on the XMega series.  In particular, the 12-bit digital to analog converters (DACs) open up a whole new world of options.  I mean, there are all sorts of applications out there that might benefit from an on-chip DAC: function generators, analog power supplies, audio processors, lighting controls, you name it!

So the first bit of code I wrote for my XMega is a simple ADC → DAC pass-through.  It’s a touch long to include in this post (because of all the comments), but please feel free to download it here.  The code takes an analog input on ADCA1 (PORTA1, pin 96) in the 0-2.1V range and outputs a proportional analog signal on DAC0 (PORTA2, pin 97) in the 0-3.0V range.  Here’s a screenshot of the results taken using my RPI IOBoard and LabVIEW interfaces.  The bottom graph (red line) shows the sine wave signal being generated by the IOBoard and connected to the XMega’s ADC input.  The top graph (white line) shows the scaled sine wave being measured at the XMega’s DAC output:

XMEGA ADC-DAC Pass-through Test

You may be wondering: why the difference in input and output voltage ranges?  Well, here’s one additional problem I see with the XMega: Vcc (max 3.6V) is not directly available for use as a reference for the A to D conversion, only Vcc/1.6V (which is 3.3/1.6 = 2.0625V, in this case).  Now you can select AVcc (typically tied together with Vcc, perhaps via a filter) as a reference for the DACs, although according to the hardware datasheet, both ADC and DAC reference sources are limited to AVcc-0.6V, or 2.7V on a 3.3V source (which is what you get on the XPlained development board).

Now in testing these specifications, I have found the ADC limit to be fixed as stated, although when I’ve selected AVcc as the reference for the DACs I’ve seen max outputs reach just over 3V.  Honestly, I don’t know what prevents the XMegas from using Vcc as a reference, as this is commonly done with ATMegas.  Oh well!  You just may need to throw in a voltage divider and/or op-amp to compensate.

One other issue I noticed was noise in the ADC signal when measuring values near 0V.  This could be an issue with how I’ve setup my code, or with some other aspect of my hardware.  But you can see this effect in the slightly garbled low points of the sine wave shown in white in the above screenshot.  I guess the bottom line is that I’ll need to play around with this a bit more.  (NOTE: I believe we have solved this issue; it is a problem with the XMega chip itself.  The solution is to use a lower (e.g. 1V) reference for the DAC.  See comments section below.)  Apparently there are also calibration registers for the ADC, and some pretty advanced tweaks you can make.  Take a look at this page on configuring and tuning the XMega ADCs – it’s been a great help to me already.

Conclusions

Overall, I’m cautiously optimistic about the XMega and the XPlained development board.  I’ve encountered a couple of minor issues, and the list of problems in the errata section of the datasheet is frighteningly long.  I should also point out that a previous version of the XPlained, the XPlain, apparently had quite a few more serious issues.  You’ll find references and pictures of the XPlain if you do a bit of Googling.  I’m not sure who’s still selling it, but I can tell you that despite the picture and the name, Digi-Key is shipping the newer XPlained, not the old XPlain (this is where I got mine).

So I still say that the XMega a great leap forward by comparison with the ATMega series.  The only question left is what to do next?

I’ve been thinking about going further with this ADC-DAC application and creating an audio compressor and volume control.  You see, I’ve got this cheap portable speaker that I use with my Blackberry for listening to MP3s.  The trouble is, there’s no remote, and each track seems to play at a slightly different volume.  So I’m thinking of using the XMega to receive IR signals from a remote and then adjust the volume accordingly (by scaling the ADC result before sending it to the DAC).  And at the same time, it could automatically adjust volume, based on the incoming audio signal, within a certain range.  This is called compression.  My setup would require a bit of analog work to get the signals into the correct voltage ranges before and after processing, but a couple of op-amps would likely do the trick without much work.

That said, I’m open to other ideas.  Has anybody out there got suggestions for projects?

Testing TI’s LaunchPad

TI LaunchPadEver since I read Hack a Day’s post on TI’s $4.30 LaunchPad development board, I’ve been itching to get my hands on one. So two weeks ago, while putting together a small DigiKey order, I checked to see if the LaunchPad was in stock. Lo and behold, it was. So of course I immediately added it to my order. This past week, my LaunchPad arrived.

I must say, what you get here for your four bucks and change is pretty impressive. The development board is USB powered and contains all the necessary hardware to program and debug MSP430 microcontrollers (MCUs) in up to 20-pin DIP packages. The kit includes two MCUs, the MSP430G2211 and the MSP430G2231. Both chips have 2kB of flash memory, 128B of RAM, and 10 GPIO pins, but the 2231 also provides a universal serial interface (I²C and SPI only), an 8-channel 10-bit ADC, as well as an internal temperature sensor. The board ships with the 2231 in place and programmed with a nifty temperature sensor program that’s ready to run.

The kit also includes two optional headers you can solder into the 0.1″ pitch breakout connectors on the left and right sides of the board. There’s even a 0.5m USB cable included! The only thing lacking is software, but who wants CDs anyway? Instead, TI offers two free (but limited) IDEs for download on their LaunchPad Wiki.

Now before I delve into my experiences with the LaunchPad, I should let you know that I’m very much a fan of Atmel’s AVR line of MCUs. I’ve been programming 8-bit ATTinys and ATMegas for about five years now and am quite satisfied with their performance. I’ve never touched another Texas Instruments MCU and have only had limited experience with PICs. So, just understand that this is where I’m coming from. I’ll also include a short comparison between the MSP430G2231 and the similar ATTiny24 at the end of this post.

The Project: Does Your Fridge’s Light Really Turn Off?

Ok, call my crazy, but the first thing I thought of when I found out the 2231 had a built-in temperature sensor was, “I wonder how cold my fridge is?” My second thought (having been running tests with a phototransistor last week) was, “I wonder if that light in the fridge actually turns off?” It’s a question I’m certain everyone has asked themselves at one point or another. Of course normal people might just test this by pressing the door switch, but not me (and yes, I know what that means). So here’s what I had in mind:Launchpad Fridge Test SetupI started by modifying the demo program provided with the launchpad to read two analog inputs: the temperature sensor and input A7. I then connected A7 to a phototransistor (which you can think of as a light-dependent resistor) wired in series with an adjustable resistance (a 500kΩ potentiometer) as shown here:

Phototransistor CircuitThe potentiometer is used the adjust the sensitivity of this circuit for varying lighting conditions. That extra 2.2uF capacitor isn’t strictly necessary, it just removes noise caused by EMI and flickering lights. So, I connected the UART TX pin from the LaunchPad to my SparkFun BlueSMiRF module (a nifty Bluetooth serial modem I picked up a couple of years back for a different project). Power for the entire setup is provided by a 9V battery run through a 3.3V DC-DC converter (see my previous post on regulator efficiency).

LaunchPad in FridgeWell there it is – the entire setup powered and running inside my refrigerator. The green light on the BlueSMiRF tells you it’s connected. But as you might imagine, with the fridge being a large metal box, Bluetooth reception was quite poor with the door closed. I had to put my laptop right up against the side of the fridge to get a good connection. But other than that difficulty, the system worked great. And of course, I built a small LabVIEW VI to plot and display temperature and light data on my laptop:

LabVIEW Data Graph (Arrow Indicates Door Closing)The graph on the top indicates temperature in Fahrenheit while the bottom graph plots phototransistor voltage versus time. The red arrow indicates the point at which I closed the fridge door. Now, voltage and light intensity are inversely related in this case. In other words, a low phototransistor voltage means high ambient light. A voltage of 1.5V indicates a total absence of light. So, since the voltage at the arrow jumps from almost zero to 1.5V, we can be confident that yes, the light inside the refrigerator did in fact turn off. Yay!

My Impressions of the LaunchPad

As I was working with the LaunchPad, I kept a few notes about my experience which I’d like to share here. The first thing I’ll mention is that TI is doing a great job keeping lots of useful information on their LaunchPad Wiki. I had no trouble finding the software and information I needed. Plus, they’re maintaining a Learning Community with links to many interesting LaunchPad projects. So good marks for TI there.

In looking through the available IDE options on the LaunchPad site, I decided to go with Code Composer Studio (CCS) because of its higher compiled code size limit (16kB vs 4kB for IAR) and because it’s produced by TI. I must say though, the download and installation of CCS took quite some time, even on my fairly modern T61p laptop, even with just the MSP430 components selected. However, the default layout of CCS suited me fine:

Code Composer StudioAs I mentioned, to develop the code for my fridge project, I started with TI’s demo application, then added and removed bits as needed. Before even touching the code however, I went through it line by line with the datasheet open next to me so that I could start to understand the MSP430 line a little better. I was slightly disappointed in the amount of commenting provided, given that this was a demo application. My feeling is that in demo code, just about every line should get a comment. Also, I noticed one or two comments that appeared to be incorrect (specifically, near the clock divider settings).

I was further impressed by the LaunchPad’s ability to perform debugging with hardware connected. This is something I’ve not done with the AVRs because I’ve never had the proper equipment, only a programmer. But with the LaunchPad, you can actually step through your code line by line and watch the results on your MCU. Very cool.

One thing that struck me as strange was the need to stop the watchdog timer at the start of every program (unless your program makes use of its default settings). It looks like the WDT defaults to a reset every 32768 cycles unless stopped or handled properly. This seems like something that could trip up even seasoned users every now and then.

Comparison Table

Finally, I’d like to show you a feature-by-feature comparison between the MSP430G2231 and the ATTiny24. I’ve selected the ATTiny24 because it provides exactly the same amount of RAM and flash memory as you get with the 2231:

Feature ATTiny24 MSP430G2231
Price $2.52 $2.17
Program Memory 2kB 2kB
RAM 128B 128B
EEPROM Size 128B 256B**
Max. Clock Rate 20Mhz (10Mhz*) 16Mhz
Max. I/O Available 12 pins (inc. reset) 10 pins
Voltage Range 2.7 – 5.5V (1.8 – 5.5V*) 1.8 – 3.6V
ADC 10-bit, 8ch 10-bit, 8ch
Internal Temperature Sensor? Yes Yes
ADC Sampling Rate 15ksps (at max res.) 200ksps
Timers 1x 8-bit, 1x 16-bit 1x 16-bit
Serial Interfaces I2C, SPI I2C, SPI
Architecture 8-bit 16-bit
Active Power @ 1Mhz 540µW* 484µW
Lowest Power Draw 0.18µW* 0.22µW

*Data for the slower, low-power ATTiny24V.
** This chip does not have EEPROM but instead uses flash “Information Memory” for permanent storage, 64B of which is for calibration data by default (this can be changed).

In the above table, I’ve used green to highlight better features, where it seems a clear distinction can be made. Now although the ATTiny24 truly can provide 12 I/O pins, I should note that this requires you to disable the reset pin (via fuse settings). So unless you have a high-voltage programmer available, the code on your chip will be permanent.

Well as best I can figure, these two chips are about equal in terms of hardware. It really comes down to your specific application. Do you need high ADC sampling rates? Then go with the MSP430. Do you need an extra timer? Then get the ATTiny24. Of course, there are other chips within each family that may provide a better match for you. Ultimately, I suspect most people will pick the chip they’re most familiar with. For me, it’s the AVR.

There’s one last cool feature I should mention about the LaunchPad before closing. It can be used program some of TI’s other MSP430 products like the Chronos watch module.

LaunchPad with Attached eZ430-RF2500 Target BoardIn closing, I’d say TI has done a great job with this board. I’ve certainly enjoyed toying with it. Plus, at $4.30 it will certainly help to grow the MSP430 user base. I’m looking forward to using it more in the future. Thanks for reading!

Project Files