Jump to content
jpnorair

STM32L vs. MSP430F5: What's left for MSP430?

Recommended Posts

I guess MSP430 lost it's power advantage big time. On a dutch forum I attend this was posted (translation):

Everybode keeps yelling that this is a feature of the MSP430 series. What's wrong with the Atmel atmega 328P, 0.1uA in power-down mode or 0.9uA in power-save with 32kHz clock... If you take a smaller Atmel the powerconsumption also lowers. This way you can easily develop on the Arduino and later switch over to a more power efficient chip if needed.
(...)
PIC16F1827: 30nA standby current...

So, the 100nA in LPM4 isn't that impressive anymore I guess. Does this really give the final blow for the MSP430?

Share this post


Link to post
Share on other sites

If you're using an external XTAL with the AVR, your wake up time is somewhere in the millisecond range (not microseconds).  Maybe not a big deal for seldom-waking applications but noteworthy nonetheless.  It probably offsets some of the "power savings" so to speak.  The built-in RC osc only runs at 8MHz, not sure if its startup time is comparable to the MSP430's but it's faster than the external XTAL of course.  The AVR also doesn't have a built-in low-power oscillator IIRC, it relies on an external 32.768KHz XTAL for that Timer2 feature.

 

Plus another thing I like about the MSP430 is the *way* you enter LPM; by setting SR bits instead of issuing some SLEEP instruction.  I don't think it's really a huge deal since you can code around either method, but I just like it.

 

I'd pay for the MSP430 just for its Von Neumann architecture too, something I like to gripe about anytime AVR's mentioned on IRC.  You can't convince me to bother with PROGMEM anymore :-P

 

So is power consumption the reason?  Maybe, but the heat is on for TI.  There are plenty of other warts to point out with the alternatives though (i.e. AVR's "debugger" requires you reconfigure the RESET line for a 1-wire protocol, and since the SPI-based ICSP programming interface relies on RESET as the chip-select line so to speak, the only way to pull it out of there is to use a High Voltage parallel programmer which of course requires you design a disconnect system into your board or make sure it's a DIP package so it can be removed..... MSP430 you just add a few pins that don't interfere with anything else!)

 

I am not up on ARM yet though.  I suspect ARM Cortex-M0/M0+ is the real shape of MSP430's eventual coffin.

Share this post


Link to post
Share on other sites

Personally I wouldn't call msp430 dead for many years but things are getting pretty competitive recently so I presume new designs will go down. ARM has great marketing, that is for sure and a lot of software developers especially are focused on it and are increasingly selecting devices over hardware guys.

 

As a hardware guy I appreciate the simplicity of msp430, it is a very approachable micro and a lot of times ends up designed in even if the specs don't match up to other chips. One thing that is cool and new with MSP is integration with fram which will let you enter really low power modes for more applications when writing to mem is required.

 

Btw, I heard a few things about ARM becoming more universal across TIs uC products, it will be interesting to see how that unfolds.

 

Funny thing is that we're in this pro-ARM movement right now, i'm sure that the coin will eventually flip back to purpose driven processors, maybe that won't happen, I don't know...

Share this post


Link to post
Share on other sites

I think that you are right.  We will ultimately see more purpose-driven products again.  There is this huge ARM movement just like there was for MIPS on custom cores for nearly every application.  Now we see ARM on just about everything instead.

 

This movement to ARM is just a byproduct of mobile computers; iOS and Android.  Why use some arcane architecture that has limited support / one compiler, on Windows, and is managed by one company?  This is the problem that I have with C2K and that's one reason why it will ultimately die quickly and painfully.  Chip manufacturers fail to position their custom architectures in a way that makes them a better option than ARM right now.  ARM prices and an architecture for just about every application make it a better choice in most cases, especially considering that it has a great cross-platform toolchain that works with all ARM parts from any manufacturer.

Share this post


Link to post
Share on other sites

Agree, today things are just as much about ecosystem as they are about raw performance. With a cross platform product like arm, there's going to be more of that. As far as tool chain, I don't know, are the arm ones really that great? There's gcc for arm but its a pain for me to get used to using. Call me crazy but ccs is just fine for me-the hardware guy...

 

I do think c2k might die faster, for this cost and power are not niche at all and arms play real well in this area. C2k has a long heritage and reputation for on chip analog though but some of the new ARMs are getting there fast (by using the power and success of c2k as a benchmark).

 

About earlier comments, I am really looking forward to the energy micro Draco parts and other arm+radio socs, I think that they will fit a lot of applications.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I ran into an anomaly recently porting Contiki to BSP430 which is relevant to folks doing low-power programming, and is basically another example of the issue raised multiple times in this thread: DCO startup time can have a huge impact on how responsive and energy-efficient your low-power application will be.

 

As background: Contiki's scheduling and BSP architecture is relatively poor, and the existing MSP430 platforms use a 1 kHz alarm to update a tick counter and check to see if any tasks are ready to run.  When implementing BSP430 platform support for Contiki I noticed that the interrupt handler, driven off a 32 kiHz clock, was getting control 4 counts late.

 

Turns out this is exactly what you should expect: by default entering LPM2 on 5xx devices requires a "slow" wakeup that's about 150 us (t_{WAKE-UP-SLOW} in the datasheet).  The net result for Contiki is you have a 15% duty cycle just to maintain the clock.  You can force a fast-wakeup by configuring the Power Management Module, but of course the consequences of that include higher energy use in low power modes.

 

If and whenever I get back to Contiki I'm planning to rip out that tick code and do something more intelligent (there is absolutely no need to maintain a counter when the timer will do it for you), but in the meantime I thought folks might find the following results from this program interesting, since it shows that different MCU families have different behavior. (Wolverine/FR59xx is not shown in these results, but running the program confirms the datasheet claims for 7 us wakeup even in LPM3.)

 * Demonstrates delays in interrupt handling with different clock
 * peripherals, by setting to wake when a 32 kiHz timer reaches a
 * specific value and capturing the actual timer counter at the start
 * of the interrupt handler.  A delta of N indicates a 30*N usec delay
 * between the event and when the interrupt handler started processing
 * the event.
 *
 * See the data sheet for MCUs that support the Power Management
 * Module to confirm that 150us is the normal wake-up time in default
 * slow wake-up.
 *
 * The user guide documents that wake times with a FET-UIF or other
 * debug hardware attached may not represent the performance observed
 * when debug hardware is disconnected.
 *
 * BC2 results from exp430g2 with MSP430G2553 show no delay in any mode:

LPMx   CCR0  CAP0  Delta0   CCR1  CAP1  Delta1   SR
LPM0: 14487 14487     0    23339 23339     0    0008
LPM1: 32599 32599     0    41451 41451     0    0008
LPM2: 50711 50711     0    59563 59563     0    0008
LPM3:  3287  3287     0    12137 12137     0    0008

 * CS results from exp430fr5739 show delay in LPM3:

LPMx   CCR0  CAP0  Delta0   CCR1  CAP1  Delta1   SR
LPM0: 14624 14624     0    23475 23475     0    0008
LPM1: 32734 32734     0    41585 41585     0    0008
LPM2: 50844 50844     0    59695 59695     0    0008
LPM3:  3418  3420     2    12270 12272     2    0008

 * UCS results from trxeb with MSP430F5438A show delay in LPM2 and
 * LPM3, regardless of #configBSP430_CORE_DISABLE_FLL:

LPM exit from ISRs clears: 00f0
LPMx   CCR0  CAP0  Delta0   CCR1  CAP1  Delta1   SR
LPM0: 15812 15812     0    24663 24663     0    0008
LPM1: 33922 33922     0    42773 42773     0    0008
LPM2: 52032 52036     4    60888 60892     4    0008
LPM3:  4616  4620     4    13470 13474     4    0008

LPM exit from ISRs clears: 00b0
LPMx   CCR0  CAP0  Delta0   CCR1  CAP1  Delta1   SR
LPM0: 15812 15812     0    24663 24663     0    0048
LPM1: 33922 33922     0    42773 42773     0    0048
LPM2: 52032 52036     4    60888 60892     4    0048
LPM3:  4616  4620     4    13470 13474     4    0048

Share this post


Link to post
Share on other sites

 

As background: Contiki's scheduling and BSP architecture is relatively poor...

I agree on this, although I am biased in the sense that I author a competitor to Contiki.  It takes a lot of effort to engineer an RTOS for low power.  Low-power was never a primary focus of Contiki, made obvious by the fact it doesn't manange low-power modes in the kernel or even have a simple way to describe sleeping possibilities to the user at all.  Every MCU RTOS has a primary architecture -- it is the first one that it was designed on.  For Contiki, it is AVR.  For OpenTag (my RTOS), it is MSP430F5 (esp CC430F5137).  Most MCU RTOS systems have schedulers that run each tick, which is something I avoided -- in retrospect I can probably thank the influence of MSP430 roots.  Contiki's timer API is fairly rigid, and there is no support for sleeping in the kernel, so if you are trying to build a low-power product using MSP430, it might not be worth the effort to try to do it with Contiki.  It will take a lot of hacking to get it suitable, at which point you might lose compatibility with other Contiki libs.  If it's uIP that you want, why not just port that... my two cents.

 

Re SVM on the MSP430F5: this is definitely one of the sticking points for me.  The STM32L SVM has no overhead coming out of deep sleep, but the elongated wakeup out of LPM3 is a problem on the 430F5.  However, in practice it isn't really a huge problem. It is unlikely that your battery will fail during LPM3, because I don't think it is possible on the MSP430F5 to schedule a timer interval more than a few hours long.  You go longer with the RTC, but that requires powering the RTC, which often isn't worth it.  All of the apps I do have battery runtime measured in years, and on my products I only check the battery once every few hours -- sometimes less.  It is a lot simpler with the STM32L, which can maintain the SVM at all times, but on the flip-side it is extremely difficult to do deep-sleep asynchronous scheduling on the STM32L (it is easy on the 430F5).

Share this post


Link to post
Share on other sites

[offtopic]

Ohh... this OpenTag seems very nice. I will play with it (when I finally find some spare time to do so).

Since STM32L is supported, are other ARM processors an easy port? How about NXP's LPC series, or the EFM32 series?

Share this post


Link to post
Share on other sites

I agree on AVR, I really don't understand the appeal and why so many people use it over msp. 5v required to run at 16Mhz, really?!?

 

The only good thing I can say is that it is cool to see USB support on such low end cheap micros.

Share this post


Link to post
Share on other sites

[offtopic]

Ohh... this OpenTag seems very nice. I will play with it (when I finally find some spare time to do so).

Since STM32L is supported, are other ARM processors an easy port? How about NXP's LPC series, or the EFM32 series?

Porting OT to other Cortex-M devices will not be difficult, because the difficult part -- the multitasking core -- is universal to all Cortex-M devices.  Drivers will need to be ported, though, because different CM chip families has different peripheral designs.  Of all Cortex-M parts, the EFM32 is actually the most elegant match.  It is low-power and it has a nice timer architecture, almost like the MSP430 has.  But, it is expensive.

Share this post


Link to post
Share on other sites

I agree on AVR, I really don't understand the appeal and why so many people use it over msp. 5v required to run at 16Mhz, really?!? The only good thing I can say is that it is cool to see USB support on such low end cheap micros.

I think the AVR is so popular because of Arduino. Arduino has been around for a much longer time than the Launchpad.

With Energia and the Launchpad, the MSP430 ecosystem is about as accessible as the Arduino. Still lacking a good distribution of lots of different boosters/shields. Shield compatibility would be very nice, but not doable, as the MSP430 is 3v6 instead of 5v; lots of shields are 5v only.

I think the lack of a bootloader in the Launchpad is a big plus, since it doesn't require separate sourcing of "Launchpad compatible" MSP430G2553s, as opposed to "Arduino compatible" ATmega328s.

Share this post


Link to post
Share on other sites

I think the AVR is so popular because of Arduino. Arduino has been around for a much longer time than the Launchpad.

With Energia and the Launchpad, the MSP430 ecosystem is about as accessible as the Arduino. Still lacking a good distribution of lots of different boosters/shields. Shield compatibility would be very nice, but not doable, as the MSP430 is 3v6 instead of 5v; lots of shields are 5v only.

I think the lack of a bootloader in the Launchpad is a big plus, since it doesn't require separate sourcing of "Launchpad compatible" MSP430G2553s, as opposed to "Arduino compatible" ATmega328s.

Heh, reminds me, I have a small stash of ATmega328's and ATmega1284P's in my bin ... Think I should go ahead and burn the Arduino bootloader on them all and sell them on ebay or something.  They'll never get used; I have some TQFP atmegas too, if I am really hard-up for an AVR I'll just use one of them ;)

Share this post


Link to post
Share on other sites

I think the AVR is so popular because of Arduino. Arduino has been around for a much longer time than the Launchpad.

Until the G-series existed, the low-end of the MCU market included PIC and AVR.  I think most of us can agree that AVR is preferable to PIC, and if you wanted a DIP part, those were the ones available.  

 

Supposedly, there are more launchpads out there now than Arduinos, although I don't know exactly where TI is getting the numbers.  I should also mention that the STM32L is 5V tolerant.  It cannot use 5V or output 5V, but it won't break if you send 5V into the pins.  I'm getting the Haystack dev-kit boards in next week, which can attach to an arduino-type board.  I will post pictures when I get them.

Share this post


Link to post
Share on other sites

That guy from EEVblog was

that for production, PIC is much more preferable than AVR.

 

I think there might be more launchpads out than Arduinos purely because they used to be so dirty cheap; if I were a teacher I could buy one for every student in my class without much of a problem. A lot of people on this forum used to give them away to friends as well.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×