RFEE

I feel bad about saying this on an MSP430 site, but really, really, really... the MSP430 is not getting chosen for new designs in IoT stuff.  If you are a TI dedicate, this might be OK, since there is a little bit of leaked information about CC13xx on the internet... you can probably guess what it is (good night CC430).  And no, I do not have an active NDA with TI.  I've said for a long time that TI should upgrade MSP to CM0+ and just keep the same clocking and peripherals.
 
A good Cortex M0+ like the STM32L0, EFM32-Zero, or the equivalent Freescale part (I am not familiar with their naming, but I know they are doing a lot of ARM CM devices) will be able to run the same code (let's say, C) a lot faster than MSP430 will.  For the most part, the CM0+ devices have roughly similar figures for current usage at 16 MHz, and this figure is about the same as the MSP430F5/CC430 at 20 MHz.  It's somewhere in the area of 3.5mA.  However, the CM0+ at 16 MHz is still more than twice as fast as the MSP430F5 at 20 MHz.  CM3 is almost exactly three times as fast, in my personal measurements with OpenTag.
 
In terms of sleep current, this is important too.  In ARM language, your main sleep mode will be DEEPSLEEP with all buses powered-down.  STM32 calls this "STOP."  EFM32 has some LPx nomenclature.  In any case, on these devices, STOP current (or equivalent LPx) is in the 0.4-0.7 uA range, and you can go from STOP to full speed run in about 4us.  That's pretty damn impressive.  The light-sleep that you can use during certain, blocking operations is in the 600 - 800 uA range.  That is still impressive.  Additionally, one of the things I do with STM32 is have OpenTag (an RTOS) automatically determine the optimal run speed.  Tasks can also request a speed.  The most efficient run speed of the STM32 is 4.2 MHz, but for doing protocol processing you definitely want to jump to 16 MHz in order to turn-around the packet faster.
 
Other benefits:
- ARM CM DMA is a lot better than the MSP430 DMA.  If you are smart, you can write fast memcpy and SPI routines that also go into light sleep.  This adds up.
- ARM CM has a nested-vector interrupt controller, which can be nice for working with multiple I/O.  This is most prevalent on CM3, 4, 7.
- ARM CM has a hardware-based dual stack configuration, which makes running a lightweight RTOS much more efficient and reliable than with MSP430.
 
IMO, the best CM3 device is the EFM32 Gecko, but the best CM0+ device is the STM32L0.  It beats or matches the zero gecko in most respects, it has HW CRC, HW AES, and also a bunch of special low-power features.  It also has onchip EEPROM, which is really important if you want to store non-volatile data, even if it is just a mapping table to a flash wear leveling system.  It is also priced much better than EFM32.  Nonetheless, it might be worth it to wait for more info on CC13xx.
 
RF Element:
The biggest power user is going to be the RF transmitter.  In addition, you need to worry about the RF startup time.  The SPIRIT1 from ST has an onchip SMPS, so it has the lowest TX current by far.  It also has a very fast fractional-N PLL and crystal driver.  However, I think it is not so fast from a truly cold start.  You will need to seriously inspect the startup-time for all the transmitters you are considering, in addition to the transmission current.  I still bet SPIRIT1 is the best choice.

I tend to agree with what is posted before; you do need to care about low power modes, since that's the whole point of using an msp430!
A tiny teeny example: you need an ADC to measure...
Then start the ADC S&H circuit, go to low power, get an interrupt from the ADC that it's done, wake up and copy the value.
 
As you can see, even for such a simple task as reading the ADC (which may take only a few milliseconds, maybe even microseconds) it's worthwhile to consider implementing low power. If you choose not to, than you're burning precious energy.
 
Same for RF transmission, let's assume your RF module accepts serial data (UART or SPI) and you need to send 4 bytes of data.
You load the first byte in the USCI (or other serial peripheral), go to sleep, get an interrupt when the TX register is available again.
Then you wake up and load the second byte.Same for third. Same for fourth.
Then you get an interrupt, wake up, since you have nothing else to, you return to low power again, but now without any clocks, you don't need them anymore, but the RF module is not yet done with the last byte. This way you can drop your msp430 power consumption to a few hands full of nanoamps.
 
If you ignore these scenarios and let your MCU just spin until it's allowed to do something (read a sampled ADC value, send a next byte, etc) then you're not giving the msp430 the fair chance it deserves.

@@rockets4kids While I tend to agree with alot of your points, we should assume that @@RFEE has done enough background work on his design to know which parameters he is using as a metric.
 
This statement makes sense with where he is coming from with thew startup times.
 
Take the vibration for example. the system might be completely dead, i.e. not enough enough power to sleep. then when a large vibration occurs the system needs to wake up, and transmit some signals using only the energy it gathered from that shock.
 
Ignoring a few extra things, like the RF system requiring energy to wake up, and any sensors etc.
 
TI give a great table in their datasheets, Table 5-10 "Typical wake-up charge" Taken from the FR5969 datasheet Pg 31.
 
 
A*s or Ampere Seconds is just Coulombs, the standard unit for charge. This is literally the energy required for the IC to power-up before it will execute any code.
 
Looking at EnergyMicro's M0+ they don't have any comparable values.
We can compute a value to try and compare. however during a MCU start-up not everything is running as it is in active mode, so these figures will be larger than if tested.
 
Gecko zero M0+
typical startup time 163us (Device datasheet, table 3-5 power management)
Startup speed 14Mhz (reference manual pg 106)
Active mode current: 117uA/Mhz  * 14Mhz = 1638uA (device datasheet, operating current)
 
Startup charge = 266nAs
 
 
Personally, I would build your device using both MCUs and personally test the difference. Asking about product comparisons on a forum about one of the products is inevitably going to return biased results.
 
Full disclosure I have never used any energyMicro devices. I just spent a few minutes on google and reading datasheets.
 
 

If you want it to last as long as possible, you should use a buck regulator like http://www.ti.com/product/tps62736 so the voltage regulator inside the MCU doesn't burn up excess voltage.  If the current draw of the MCU at 3.6 and 1.8 is the same, then there's a regulator in there, thus running it at 1.8 will make it last the longest.