I recently started playing with MSP430's. They are fun devices and I think there are lots of possibilities with those. I have no real experience with other uC's so I can't say anything about others or compare. Having said that, here are some very basic impressions:
TI's example code is often confusing and over-engineered. It is much better to find advice on blogs and forums instead.
The community has some great individuals that will produce great examples and tutorials. Unfortunately, it is very far removed from places like GitHub. Almost all code is shared directly in the forums at 43oh.com.
There are a couple of big projects surrounding MSP430's. Energia is, from what I understand, an Arduino-like IDE which lets you program at a much higher level, but at the cost of some performance. When you only have 512 bytes of RAM, it may or may not be an issue. Another one is BSP430 which is a lower level set of libraries. It promises much higher level abstractions at the cost of small performance penalties. I found the tutorials to be rather terse, but I may need to give it more time.
Outside of those big projects, there is lots of duplication of effort. It is typical to see 3-5 different implementations of bit-banging UART drivers that are all slightly different. I am no exception, as I started writing my own little set of libraries for dealing with various peripherals.
Lastly, a lot of the tutorials out there either use the register names directly (P2IE, P1SEL, etc) or provide really poorly named abstractions (cal_adc_15t30). Most of my time working with it so far has been spent on naming functions something like gpio_get_val(), uart_puts(), etc.
P.S.: Physical hardware buttons are terrible devices. Debouncing them is a must and most implementations in the wild are incorrect. [1] is a good read.
The problem with the raw register names is that they're not even consistent between compilers/libraries. However, they're usually the best route to go form an efficiency standpoint.
I think the core argument of the blog post is to use a voltage regulator with a low quiescent current. It doesn't really matter what uC you're using since it's only turned on every few seconds with the watchdog timer, however if you used common voltage regulators like the 7805, lm317, or lm1117, you'll use up the battery in short order.
The best thing is to NOT use a voltage regulator at all. The MSP430 line will happily run down to sub-1.8V levels, which means a pair of AA/AAA alkalines could power your project in time spans well exceeding the shelf life of your batteries (5-7 years, and this was an application coupled to a 802.15.4 radio).
For more performance oomph, there are Cortex-M3 parts which exceed or meet the efficiency of the MSP430 line, such as the Energy Micro EFM32.
I can highly recommend both MSP430 Launchpad and the STM32L discovery boards. Small investment if you want to look at something beyond the Arduino. I'd probably go with M3 cores at this point but the MSP430 has a lot of history and is maybe a bit easier to program because it feels more cohesive than the combination of ARM core with vendor peripherals.
If you want to extract the most out of your batteries, wouldn't you use a boosting reg so can extract every last bit? I think for most projects, the uC uses far less power than the auxiliary components around it, like a LED. If you boost the voltage you can use higher logic levels. There are many examples boosting a "dead" 0.5V AA battery to 3V at a lower current.
If you use a buck regulator, you could use starting voltages beyond the chip's max voltage limit and burn the power past a typical dead cell's voltage levels -- start with a 12V battery using 1.8V logic and burn the battery down to 2V -- probably around 98% used.
I think you'll find that most projects out there use a voltage regulator because you can use up "more" of the battery this way.
Boosting regulators are common, but there are efficiency tradeoffs, since: a) boosting regulators consume energy, b) boosting regulators with a sleep mode (so you're not spinning the wheels 24/7) don't start up immediately.
Two 0.9V alkaline cells can still power most microcontrollers, especially in sleep mode, and red LEDs will still light. If you really need higher voltage, than the boost is the way to go.
I previously worked off of an MSP430-turned-EFM32 product which had a MCU+radio lifetime of 5-7 years on 4-AA cells (two paralleled). Most switcher solutions we looked at wouldn't have netted a measurable increase in runtime due to the much higher sleep currents in those units compared to even the MCU.
A big reason most hobby boards use LDO regulators is that buck-boost topologies are comparatively complex. PCB layout is critical and protections are more complicated.
You'll have a really bad time if you try to build a buck-boost switcher in a breadboard and won't have a clue why its not working. On the other hand you can throw an LDO into a breadboard with a couple caps and be pretty confident it'll just work.
You are absolutely right: Once you get the uC power consumption down with sleeping, others components use the majority of the power and determine battery life for the most part.
The fruit power source made me wonder: Has anyone made a device that is powered by a growing plant? Plant-derived power could be much more robust than traditional solar cells. A solar cell fails if it gets dirty or broken, but a plant will just grow new leaves and branches.
