chicken

More test gear with MSP430 inside: A MSP430F437 powers the Tonghui TH2822A LCR meter.
Teardown and pictures on KuzyaTech's blog: http://kuzyatech.com/tonghui-th2822a-lcr-meter

A starting point might be the LMFlashProgrammer utility. Its description on the TI Wiki lists "perform an ICDI update of the firmware on the LaunchPad debug interface" as a feature.
http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Blink_the_RGB#Optional_Files
 
I like the idea about the USB mass storage boot loader, but I would hate to lose the debug capabilities.

Given the ratio of FLASH vs. SRAM in MSP430, particularly the larger ones like the just announced MSP430G2955, it's also important to consider where the "bloat" occurs. It might be worth to sacrifice FLASH to save SRAM (and clock cycles).
 
In the UART example the template will integrate BUAD and MCLK_HZ as constants into the generated code. The C function call on the other hand will generate code to setup registers and/or stack to pass parameters and then the UART implementation will potential store them in a global structure for later reuse.
 
Multiple instance of the UART template will use more program memory, but the SRAM footprint should be little changed.

Re the AVR stuff: In practice, MSP430 is lower-power than AVR.  MSP430 generally uses lower voltage, and it is quite a bit more code-efficient and IPC-efficient than AVR.... and AVR is quite a bit better in these respects than is PIC.  People maybe think that I don't like the MSP430, but that is incorrect.  I think it's great for a lot of things.  However, I think the AVR is a piece of outdated crap.  The G-series MSP makes AVR worthless to me.
 
Anyway, more quantitative argument now:
 
I am also most interested in the power-down mode that preserves a timer and the contents of RAM.  I think this is the mode that should be compared between micros, and for this the 328P is listed at about 1uA.  In any case, what can matter even more is the active mode, and the speed of entry from sleep into active mode.
 
A common low-duty application has a timer and 1/1000 duty.  In other words, the MCU is active for 1 millisecond out of 1s.  If sleep is 1uA and active is 1mA, and duty is 1/1000, then average is 2uA.  This is actually the reason why STM32L works better for me than MSP430F5 does.  The sleep current is about the same, but during active mode STM32L uses 1mA to run the code in X ms, whereas MSP is using about 3mA to run the code in X ms.  AVR in active mode seems to need about double the current -- and often double the voltage -- to meet the runtime efficiency of the MSP430.  
 
To give some real numbers, the Atmega 328P needs to run at about 20 MHz to match the STM32L doing 4.2 MHz.  The voltage here is ~1.8V for the STM32L and ~5V for the 328P, and the current is respectively 1mA vs. 20mA (est).  So, the STM32L is using less than 1/50 the power of the 328P to run the same code.  If STM32L needs 2uA in sleep, that extra 1uA is nothing compared to the savings in active mode, and not to mention the ability to run on two alkaline batteries without an SMPS.  The extra cost in batteries or SMPS outweighs the cost advantage of using the 328P in the first place.

Point is, you're the only one arguing about what is best, and what is not.  My whole stance has been ( going back what now ? 2-3 months ). Be flexible, and use what makes sense.  Of course, if your experience is limited, your options for what makes sense  is also by default going to be limited.
 
I bet you would make little fuss about someone talking about using inline ASM right ? Same difference here, think about it.

Again . . . 
 
Being a bad programmer makes you a bad programmer. You and Linus can both agree all you two want, but that does not make either of you right.
 
C can not do function overloading . . . C can not do templates . . . C++ *can* do anything C can do and more.
 
Templates can lend towards faster, more efficient, and smaller code. Sometimes which can be hard to reproduce even with carefully hand crafted assembly language. 
 
Just a few points there, some being more significant than you, or Linus realize, apparently.  But running the risk of sounding like an ass, where I am not trying to be. It seems to me that you, and Linus are both of the mindset that C++ is bad, without actually laying hands on C++. However, I really have no idea how Linus actually thinks, just going by what you're saying. Whatever the case, it matter little to me, as I tend to think for myself.
 
So, if you have a specific case to bring up that does not rely on developer coding style/habits. Which are based on fact, then perhaps you're on to something. However, with that said, I really do not think you can bring anything up that has already been rendered as moot. C++ relies heavily on C. So I feel that if a bit of C code would do a specific job better, that it would be foolish to not use C in that given case. However, the reverse is also true.
 
So yeah I am of the opinion that purist ideals hold no real "value" in this context. But feel free to do as you please

I'd like to thank TI,Seeed and the designers involved for this first batch @ SeeedStudio. If you are ever ordering from Seeed and need a few boosters, check the following out. Also, don't forget, there always is The 43oh Store.
 

 
The BluePack - 43oh Bluetooth Launchpad Boosterpack The Locator - 43oh MTK3339 GPS Launchpad Boosterpack Wirefree - 43oh Wizfi210 WiFi Launchpad Boosterpack The Protopad - 43oh Prototyping Launchpad Boosterpack The SMDProtopad - 43oh SMD Prototyping  Launchpad Boosterpack      
 

Great stuff! I started prototyping something similar as low-power is what fascinates me most about the MSP430. Will definitely use your schematic and code as a starting point to build my own.
 
Thanks for sharing! :thumbup:

Always a sucker for displays of any form and shape I ordered one of the 1.35 inch SHARP LS013B4DN02 memory LCD when it made the rounds last year. At $20 apiece it's quite expensive for its size, but it's sooo pretty
 

 
I finally finished up the code and published everything on Github.
https://github.com/a...-memory-display
 
According to the datasheet, this display runs on less than 15uW. I was not able to measure current with my lowly multimeter, so I'm pretty positive that the MSP430 plus display use way below 1mA.
 
If the display looks familiar, that's because it was featured in the Wolverine teaser a few months back
http://www.43oh.com/...cd-boosterpack/
 
My code probably also works with the breakout board that fellow 43oh member reagle designed:
http://forum.43oh.co...akout-for-sale/
 
More information about the display at SHARP:
http://www.sharpmemo...memory-lcd.html
 
According to Mouser LS013B4DN02 is end-of-life. However LS013B4DN04 has very similar specs and should also work with this breakout and code. Both displays are in stock at Mouser:
LS013B4DN02
LS013B4DN04
 
I have two extra PCBs including matching FPC connector (10pos .5mm) sitting in my drawer. PM me if anyone wants one, I'll give or trade them away as long as it's within the US.
 
Regards
Adrian

Not OLED but low power Sharp Memory LCD (at least on the image above)
http://www.sharpmemorylcd.com/aboutmemorylcd.html
 
I did connect an older model of the display to the LaunchPad a while ago:
http://forum.43oh.com/topic/2902-sharp-memory-display-breakout-and-example/

43oh Store link   I found myself wanting a dedicated power monitor to use while developing battery-powered application circuits, so I built one using the MSP430G2402.    http://code.google.com/p/powerscope/   This device has already helped me identify and eliminate about 40% of the power usage of a project in-progress.   Right now, I just have the code as a zip file on the download tab, but if anyone wants to develop additional features, I can check the code into Subversion and create some branches.    The board can be ordered for about $12 (for 3 boards) by uploading the Eagle .brd file to http://www.oshpark.com I don't make any money from oshpark.   Greg Glenn
http://gravitastech.weebly.com/

This is a project for me to learn programming on the Stellaris,  with tons of materials, support from TI, this and other forums, I managed to get a working port going for this project.
 
I ported part of the FreeIMU library to the Stellaris Launchpad, just enough to support the GY-80 that I have in my "gadget box".
 
GY-80 consist of 4 sensors, L3G4200D (Gryo), ADXL345 (Acc), HMC5883L (Mag) and BMP085 (Baro). This is a cheap sensor board that is readily available on ebay or your favourite Chinese online store.
 
What is working?
 
Reading and writing to the sensors by i2c bus (thanks to the code from "aBUGSworstnightmare").
calibration routine works but it is not saved to EEPROM.
Basically it display the Roll, Pitch, Yaw, compass heading and all sensor's Raw data thru the Uart Console (I am using BT on UART1, change it to UART0 for ICDI port.)
 
Overall it is still buggy and I still cannot reset the Roll setting.
 
Todo. 
1. save calibration data to EEPROM.
2. host software for graphical representation of data.
3. fix bugs.
 
As I am a RC fan, it will be thrilling to see the Stellaris on a Quadcopter, if this goes well, I will go on develop it further, with newer gens of sensors.
I dont know if I can pull it off or not, hopefully someone else can either help or work on it. 
 
The project is up on google code, anyone interested to work on it, please let me know. 
https://code.google.com/p/stellaris-lp-imu/
 

I've been watching this thread for a bit. Considering me walking the line on this one. As an owner of two currently operating businesses, I see TI's point and need in raising their prices.
 
Last year I raised my per irrigation zone rates and lost several customers, but only for a few months. They came back after realizing the service and finished products I offered were better than my competitors and my project turnover rates are faster too. So while I took a hit for a short time, revenue and customer satisfaction are higher.
 
Yes, TI's rate increases bite but think about it... An almost announcement of the g2995?? What else are they hiding? What does the LP v1.6 look like? Or v1.7? TI, let us see the roadmap and give us a bit of encouragement about the future of your products.
 
In my experience, TI's products and services have been top notch. Their e2e community has been extremely helpful. Their data sheets are flat out the easiest to read and most consistent among product families.
 
Also, the 43oh community has greatly increased usage and recognition. I believe more projects and boosterpacks have poured out of us here than the whole of the users on E2E. Maybe we (mostly meaning bluehash) can work on expanding our partnership with TI? I for one, plan to stick with the MSP430 for smaller projects and I'm really enjoying the Stellaris line, issues and all.

I'm a little afraid that I'll step into a big pile here, but I wanted to offer a couple of nuggets *please keep in mind that I usually only deal with University Partners, so I come from a slightly unique perspective. 
 
The LaunchPad has pretty much changed TI's place in the Microcontroller market and especially in Education. 
For me, I've been able to open up a lot of educational doors with the price point and what the kit could offer. However, the past year I've been watching it slow down a bit as the "4.30" on it's own isn't as compelling. The requests started to come in that I find ways to bundle the LaunchPad + Breadboard + Wires or , LaunchPad + BoosterPack combo or LaunchPad + Book + Training material... 
So, I went to look and see how I could get some of these requests fulfilled. 
Turns out--
The eStore can't do much than stock TI Standard kits, nor can they really bundle. 
DigiKey, Mouser, Newark -- have bundling options, but it's horrific to set these up, let alone have to manage the paperwork associated with the bill backs for services. 
I didn't even try with Arrow and Avnet because they weren't interested in anything that didn't generate serious money (e.g. Big Customers)...
 
So, I turned to some of the "hobby" distributors (e.g. Sparkfun, some local ones in India and Europe), went to a couple of conferences, met with some of the decision makers...
and asked them, "What can I do to get you to stock LaunchPads and offer "bundles" and trainings/services.?" All of them were interested, but when they saw that they would be buying the LaunchPad at the same price that TI was selling it for... backed out. 
There was absolutely no money in it for them. 
It costs money to inventory, stock, manage paperwork-- and time. (that's not even developing training and marketing) Sure, some universities would pay for value added services, but what was incentivising someone to buy from them (person providing the service)? Plus, the amount of effort + the pay out... for most of them wasn't worth it. 
I talked to no fewer than fifteen different educational distributors... and got a similar story. It started to become really clear that TI was indirectly competing against the same people that we needed to offer more/better services (at least in Education). 
 
To make sure I didn't give up on the 4.30 model... I tried a few things. (A little lengthy story, but I think this illustrates the best one)
I donated the entire LaunchPad inventory to a few of my partners (IEEE groups who were doing ebay purchases and bundles). 
Great for the first semester, but come re-order time-- I had run out of budget. 
So, the IEEE group had to switch and instead used the Arduino... and found students were willing to pay the 50.00 (when the previous was 24.00). 
When semester came around and I had budget, I called asked them if they wanted to try again... and they declined me. They would rather set up the store to not have to manually switch everything over just because I couldn't donate the kits!
So, I asked, how about buying them? I'll make sure that you can always purchase them at a discount, (which was almost nothing because $4.30 was pretty much rock bottom). 
Declined again-- with the Arduino the IEEE group was able to get them at 21.00 and reselling the boards for 30.00. That was 9.00 of extra margin they could use, if I wasn't giving them the LaunchPads free... all the time, there was absolutely no incentive for them to move over. (Insert "using Industry tools blah blah blah" argument, still couldn't switch them over). 
 
Granted, one IEEE group is NOT everyone else, but the concerns were similar. 
It showed me (at least in my space) that the only way I could push LaunchPad was through my program-- which is limited by my budget and what other things that I wanted to accomplish that year. The only way that I could grow LaunchPad in Education--> was increasing the level of service and offerings around LaunchPad--> which was beyond what TI could do on our own and  I could only accomplish by getting good partners-->and the only way to get good partners... was frankly-- help them make money. Successful Partner with LaunchPad meant Successful TI University Program. 
 
So, although it sucks right now, I really see this as a good idea-- for a long term strategy. 
We really could have done a much better job communicating the price change... it is never fun to find out on your own. 
There were always be TI Deals, half off coupons, Tech Day incentives.... heck, come visit me at any of my University visits, write a request, or our trade shows and you will be able to get a LaunchPads for free or a discount. We owe a lot to the community and want to continue to support it, but at the same time we're fairly realistic that a community is a lot more than just cheap hardware, that's what got us up and running and started, but now we really need to focus on enabling the very people that helped build it up-- enabling them to potentially create a business model around all the work that is being put in. Take a look at the Arduino, it was an open sourced hardware, intuitive user experience platform (the LaunchPad is also Open Hardware and now has Energia), but what really differentiates the Arduino from LaunchPad is the fact that people can make money by being part of the ecosystem-- through their own Hardware, Software contributions, Training, Bundling... etc. etc. 
 
I'm by no means the official LaunchPad communication channel,  but I'm a rather large constituent of it-- we're working hard on the next few steps we need to take on finding ways to grow -- and how honest, vocal and engaged everyone is critical for that (WE ARE Listening), so please keep letting us know what you think. 
 
Anyways, that's just my 2 cents... 
-Larissa

I think my story echoes a lot of the others.  Two years ago, my only electronics experience was with a couple of AVR's.  The Launchpad showed up on Hackaday on a dev board review - and at $4.30 - there's nothing that beats it from a price standpoint.  It was cheap enough that I didn't have to justify the cost to my wife - and it left enough money that I could spend a bit more on booster packs and other electronics to use with the board.  Not to discount the great community we have here - but Arduino has a much bigger community and support.  But because of the price difference - I could easily justify putting extra effort into learning the device and lower-level programming.  I've got some gift cards to RadioShack - and for the first time - I've considered buying an Arduino - just to see what all the fuss is about.
 
As far as I can tell - Energia is taking off and has the potential of making the Launchpad even bigger.  Unfortunately - pushing the price into the $10 range brings in a lot of other competition - as others have mentioned.  If the original goal of the $4.30 price was to help you stand out from the competition and attract the next generation of engineers - raising the price removes a lot of the attraction.  It may also prevent hobbyists like a lot of our forum members - who create booster packs - from getting involved - and providing support to less-experienced people.
 
If it all boils down to $ (which I'm guessing it is considering there was no indication of a price increase before) - then I'd suggest charging for shipping - and possibly providing a slower shipping option.  The two-day Fedex shipping must be costing you an arm and a leg.  People are more willing to pay shipping if it's not a hidden cost - and they usually get a better deal when they buy more than one.  
 
Unfortunately - Mouser and Digikey have already raised their prices.  As of right now - Mouser is up at $12.80, and Digikey is at $5.01.  I was hoping they'd keep their price low - but honestly - if there's no place to buy it cheaper - why would they?
 
I've honestly got a pretty good pile of launchpads - especially with the 5 I ordered when the price went down temporarily.  However - I'm worried that this will keep others from getting involved and that the community may dwindle over time.

Sometimes an MSP430 pops up in unexpected places, like in the Microsoft Surface. In a teardown by iFixit a M430G2402 is found among 4 Atmel touch controllers on a daughterboard.
http://www.ifixit.com/Teardown/Microsoft+Surface+Teardown/11275/3
 
Any guesses what it's used for?
 

Talking about EEVBlog, today's teardown, the Fluke CNX3000 multimeter and wireless accessories featuring a whole bunch of MSP430's:



M430F5435A in the main unit (7:30), M430F47163 (25:26) in the first slave unit and presumably the others too. Using a CC2530F128 for communications.
 
--edited to fix broken link

Ah, love these kind of threads! Anonymous Teardown Addicts anyone?
 
Jawbone UP Pedometer uses a MSP430F5548, as seen on EEVBlog: (7:30)
http://www.youtube.com/watch?feature=player_detailpage&v=sRjHAGsl6ws
 
Interestingly the fancier Nike+ Fuelband also contains a MSP430F5528, but seems to be dedicated to Bluetooth communication: (13:27)
http://www.youtube.com/watch?feature=player_detailpage&v=7xdajSS_cOU

Actually the display is really dumb. The MSP is in charge of doing the refresh and fetching the data. The Stellaris mostly supplies the memory needed to hold the display data. The Driver chips on the display have enough memory to hold one LINE of data at a time. So the max refresh rate is limited by how fast the MSP can process the data. This display was originaly meant to be driven by something like a SED1335 controller chip. But that would have been too easy
 
By having the MSP handle all of the display timing and refresh, the Stellaris only needs to use ~4% CPU time to manage the display, leaving plenty of CPU time for generating the Data to display.
 
Here is some more info on how to drive this particular display: http://tinyurl.com/8j9jkvv

This project attempts to control a surplus LCD (http://www.goldmine-elec-products.com/prodinfo.asp?number=G18246) using a MSP430 and the Stellaris Launchpad.
 
Brief Description:
 
This project is designed to run a 320x240 monochrome LCD with minimal CPU overhead.
A seprate controller board supplies the VEE for the display, controls the Backlight and has a MSP430G2542 running as a SPI Master. The MSP also controls the clocks for moving the data to the display.
The Stellaris side sets up a 1BPP offscreen display for Grlib and also sets up a UDMA job that transfers the display buffer to the SPI port for the MSP to collect.
The SPI connection is set up to transfer 16 bits at a time, allowing for 4 pixel updates for each transfer. With the SPI clock running at 8Mhz, the display can update at ~51 Hz.
 
I had the first PCBs made by OSH park and am currently trying to iron out some bugs in the bias voltage section. As soon as that is done, I will be adding schematics and the board layout on github.
 
Code and documentation can be found here:
 
https://github.com/hvontres/LCD-Controller
 
 
Here is a picture of the current project:
 

 
Here is the first prototype:

 
a picture of just the controller:

 
controller mounted below launchpad:

 
 
Here is a video demo showing the different modes of the main application:
 

 
The video starts with the splash screen, inverts the display, animates the splashscreen using grlib, displays text using grlib functions and finally shows some test images downloaded in 8 pixel chunks from the host. The current code allows for 30 chunks per transfer, so that is why the screen updates are a little slow. I'll try to get some better video soon.
 

Hi,
 
I wanted to share a bootloader I wrote for the Stellaris Launchpad (and other boards/chips if you change it up a bit).
The bootloader acts as a mass storage device, and allows for software update by simply moving a file to the device. No software or drivers needed!
It's inspired by the bootloader found on some NXP LPC microcontrollers.
 
The project was surprisingly easy thanks to the awesome Stellaris USB Library.
 
Grab the source here: https://github.com/Emeryth/Stellaris-mass-storage-bootloader
 
Pleas report any issues you encounter.
 

After 4 months (to the day) of hard work by the Energia team, Energia release 0101E0009 - 12/06/2012 it is ready to go! A full list of new features and bug fixes will be posted on the github wiki page later this week.
 
Highlights for this release are:
 
- StellarPad aka EK-LM4F120XL support (http://www.ti.com/tool/EK-LM4F120XL).
- FraunchPad aka MSP-EXP430FR5739 FRAM support (http://www.ti.com/tool/MSP-EXP430FR5739).
- Lots of bug fixes.
 
The release is available for download @ http://energia.nu/download/
Pin mapping for the new boards is posted here: https://github.com/energia/Energia/wiki/Hardware courtesy of @rei-vilo.
 
Thanks to all Energia users for your continued support and providing us with invaluable feedback!
 
Thanks to Energia team members @StefanS, @ReaganR, @rei-vilo, @Rickta59, @pbrier, @clyvb for making this release possible.
 
Special thanks to @bluehash for his continued support with 43oh.com.
 
Enjoy the new release!
 
Robert

Mine arrived a few days ago, this is what I came up with:

Not tested yet, but nothing exciting there.
 

I used a 6 pin header, pulled off the sixtht straight pin and put in a rectangular one, which is soldered to the next available ground.
 

random beauty-shot :grin:

You might want to check out oPossum's first link.
 
You're right with your concerns regarding performance and memory when using regular C++ classes. My experience as well, at least if your project does not require OOP features (inheritance, dynamic dispatching etc). Though your point about "easy to navigate" is arguable and probably more depends on the author than the language.
 
However oPossum does use C++ templates. As shown in his first post C++ templates have some advantages when implementing reusable and configurable libraries. Check it out - initially I was skeptical too.
http://forum.43oh.com/topic/2358-software-iic-master-in-c-c-class-and-c-template/
 
Regards
Adrian

[EDIT: This code concept has evolved into "fabooh" find it here on github https://github.com/RickKimball/msp430_code/tree/master/fabooh ]
 
I've been experimenting with msp430-gcc uniarch trying out different approaches to implement a fast GPIO abstraction layer that hides some of the bitmask gymnastics we all seem to do when programming the msp430. I think I've come up with a reasonable approach and I'm hoping for some feedback from all of you.
 
Normally to access the gpio ports on the msp430 with 'C', you use a bit ANDing (P1OUT & BIT4) and ORing ( P1OUT | BIT1 ) style of programming to read and write the bits. In the Arduino world, they hide all the bit magic using digitalRead and digitalWrite. The downside, at least on the Arduino, is those instructions aren't very efficient. However, reading code written for the Arduino API does seem somewhat more understandable than a bunch of ANDs and ORs.
 
I want to make my code more readable, but I didn't want to sacrifice efficiency. After rejecting a few different methods, such as macros and functions with port tables, I came up with a C++ template that can be used to hide most of the bit mask programming and still manages to be reasonably efficient.
 
Here is an example of toggling some leds on and off using a timer:
/** * gpiotest.cpp - experimental c++ template based gpio abstraction * * author: rick@kimballsoftware.com * * 2012-01-14 - this version is about 168 bytes using msp430-gcc -Os */ #include #include #include "gpio.h" GPIO<0> LED1; // P1.0 GPIO<6> LED2; // P1.6 /** * millis - access to milliseconds since startup * * Note: because the value is stored in a 16 bit int, * it rolls over every 65536 milliseconds or 65.536 seconds */ static uint16_t millis; int main(void) { WDTCTL = WDT_MDLY_0_5; // Configure Watchdog as .5 second interval timer // use default ~1.024 MHz DCO clock digitalWrite(LED1,HIGH); digitalWrite(LED2,LOW); pinMode(LED1, OUTPUT); pinMode(LED2, OUTPUT); IE1 |= WDTIE; // Enable WDT interrupt while(1) { // Go to sleep until the Watchdog wakes us _BIS_SR(LPM0_bits + GIE); // The WDT_INTERVAL_ISR brings the CPU out of sleep mode // and we end up here, every 8 seconds or so if ( millis % 8192 == 0 ) { volatile int i=0; i=i; } } return 0; } /** * WDT_INTERVAL_ISR -Watchdog Timer ISR handler * * Note: assumes MCLK is 1.024MHz and we are using the * WatchDog Interval timer mode of WDT_MDLY_0_5 */ #ifdef __GNUC__ __attribute__( (interrupt (WDT_VECTOR)) ) #else #pragma vector = WDT_VECTOR __interrupt #endif void WDT_INTERVAL_ISR(void) { static uint8_t _500uSCount= 0; // count each .5mSec tick // every 2 ticks update the millis counter if ( (++_500uSCount % 2) == 0) { millis++; if ( millis % 64 == 0) { // toggle every 64 mSec, uses power of 2 value for smaller code LED1.toggle(); // our 2 leds are out of sync LED2.toggle(); // one is on when the other is off _BIC_SR_IRQ(LPM0_bits); // leave the ISR and exit sleep mode } } } To use the code you include "gpio.h" .. this declares the GPIO template and provides accessor functions for reading / writing and configuring the ports and pins. 
To use the launchpad leds, just create an instance of the GPIO object for each pin:
GPIO<0> LED1; // P1.0 GPIO<6> LED2; // P1.6This gives you an object that allows you to manipulate the pin values. You can do things like LED1.setHigh() or LED1.setLow() to toggle that pin HIGH and LOW. LED1.setHigh() is doing a P1OUT |= BIT0; under the covers. LED1.setLow does a P1OUT &= ~BIT0. 
To use the pin as output you need to configure it. Normally you would do a P1SEL |= BIT0; to make it an output pin. With the gpio.h you can just use LED1.configureAsOutput(). As an example of how we can be more Arduino like, I provided a macro so you can also use "pinMode(LED1, OUTPUT)" instead.
 
Because we are using c++ templates, the compiler is very efficient at optimizing the code. In the example, I use two 'C' statements to set the pin modes. However the compilers optimizes it down to a single msp430 instruction.
pinMode(LED1, OUTPUT); pinMode(LED2, OUTPUT); c04c: f2 d0 41 00 bis.b #65, &0x0022 ;#0x0041 c050: 22 00 In fact, the example code is only 168 bytes of msp430 object code. This seems very reasonable to me for readable C code. Using C++ templates with structures has another advantage over traditional C++ classes done Arduino style. if you don't use a function you don't incur any overhead. The compiler only generates object code for the functions you use. This allows you to create all the various helper methods you might want and not end up with giant code bloat. 
I've concentrated on making the experiment work with the msp430g2553 and msp430g2231. However it should be fine with any of the 'G' series of chips. You need to look at the way the GPIO structure is laid out and make sure it maps to the special memory areas for your chip.
 
This isn't a finished work, it is just a starting point for those hoping for some GPIO abstraction that that still yields efficient code. Take a look at the gpio.h and the sample code and tell me what you think. It should compile with both CCS and msp430-gcc ( although I haven't tried CCS )
 
You can find the latest version of the code here:
 
https://gist.github.com/1597239
 
It has the following files:
 
gpiotest.cpp - is the sample program
gpio.h - the GPIO template declaration
 
[Edited 1/28/2012] updated code with more implementation methods
 
-rick