I don't know if this is still the case with newer parts, but it has been my experience in the past that Microchip parts looked good on paper, but sorely lacked when it came to actual real-world use. For instance, they would brag about ultra low power, but the only way to wake up the part would be to reset it. There were other things like that.
Also, uA/MHz is an irrelevant number when comparing PICs with MSP430s. PIC is the Pentium 4 of microcontrollers: it gets very little done per clock cycle. So it needs to run at much higher MHz to get the same amount of processing done as the extremely efficient MSP430 architecture. A comparison in uA/DMIPS, taking the difference in DMIPS/MHz into account when running real code, would be much more useful for real-world comparisons. I can guarantee the picture would not look pretty for Microchip.
Disclaimer: I do not work for either Microchip or TI, but I've compared the architectures in the past.
t.alex: I agree totally. Parts should be evaluated for what they will eventually end up doing in a system design. Variations will always exist between what is published and what is designed in. The proof is in the pudding, and that is what distinguishes a system engineer from a parts buyer.
Thanks for your comments regarding Microchip’s PIC® MCUs, and you are correct that newer parts are much lower power than prior parts.
For Sleep modes, Microchip offers up to three; Sleep, Low Voltage Sleep, and Deep Sleep. In every mode, PIC MCUs with eXtreme Low Power (XLP) Technology have multiple methods for waking from sleep, such as an RTC, a Watchdog Timer, Timers, and Interrupts.
Regarding work done per clock cycle, I would ask you to examine the number of instruction cycles listed in the MSP430 User Guide, SLAU056G, Page 3-71. Depending on the type of memory addressed, the instruction can be up to 6 cycles for a single instruction. By contrast, 90% of PIC24F instructions are 1 cycle, which is 2 clocks.
We tested this with the following C-code, which merely copies 32 bytes from one memory location to another:
LATBbits.LATB2 = 1;
LATBbits.LATB2 = 0;
At 4 MHz, this resulted in an execution time of 32 µs for PIC24F, and 80 µs for MSP430. The resultant energy saved by the PIC24F over the MSP430 is 2X!
We also ran side by side comparisons of PIC24F and MSP430 using industry-standard benchmarks and found that PIC24F executes code 1.5 to 5 times faster at a given frequency.
I would ask you to take a second look at Microchip’s PIC MCUs with XLP Technology and reevaluate our performance in a real-world example. I think you may find that Microchip looks a lot better than you first thought.
Disclaimer: I work for Microchip Technology Incorporated, which is committed to delivering outstanding value in low-power MCUs.
-Jason Tollefson, 16-bit Microcontroller Senior Product Marketing Manager, Microchip Technology Inc.
I note only this detail: to win over the MSP430, Microchip take the sleep/standby current of one item(PIC 24FJ12 etc, 16-bit), and the Active current of one other Item (PIC16LF etc, 8-bit). It seem to me a non-correct method of comparison. It would be the same if TI proposed the best data taking them from several devices, taking the best from where TI have convenience (but TI doesn't acts so). I think that these tricks aren't honourable for a big firm as Microchip. As PM EDT, I don't work for any of two rival.
Indeed, as KaiserSoze brings out, it looks as if you're deliberately trying to mislead when you mix the best of each of your architectures as if there were one part that does it all, which isn't true. Unfortunately, I have gotten this feeling pretty much every time I have investigated Microchip parts when some impressive marketing claim had drawn my attention. Upon further investigation, there usually was some gotcha or clever specmanship involved, which has made me wary of any Microchip marketing claims.
I couldn't find full specs on the MSP430 Wolverine parts, but just taking a quick look at your datasheet for the PIC24FJ128GA310 and the datasheet for the MSP430FR5720, I couldn't help but notice that Microchip's typical power consumption column on page 361 has a note saying "Data in the Typical column is at 3.3V, 25°C unless otherwise stated". But each row states -40°C to +85°C. Which is it? The MSP430 power specs seem to cover -40°C to +85°C.
I'm not saying your claims are untrue, but previous experience has taught me to be very cautious of "the Microchip spin". I have also not evaluated the performance of the PIC24 series, I have previously compared the MSP430 to the PIC16 series, based on similar cost, and there was no contest there.
I would suggest to anyone doing this evaluation to look carefully beyond the marketing and into the technical details. Also, there are other low power contenders around, the Renesas RL78 comes to mind (66uA/MHz).
KaiserSoze and xorbit,
Microchip submitted the above table to EE Times, to provide their readers with an at-a-glance comparison of published data. I agree with xorbit—don’t take either company’s word for it; investigate the source documents and decide for yourself which MCU will best meet your needs. Better yet, obtain samples and do your own comparison.
-Jason Tollefson, 16-bit Microcontroller Senior Product Marketing Manager, Microchip Technology Inc.
Hello Jason, Thanks for your answer. I agree with your thought "Try samples and examine results". And, overall, I'me sure that today TI and Microchip as well are making a good work and have interesting devices. On teh other hand,I don't agree with arbitrary misleading, as the one about the code to move data. Try to examine this one for MSP430, supposing two 32-bytes arrays starting at StrtAddr1 (source) and StrtAddr2 (dest):
bis.b #TestBit,TestPort ;pin setted at the end of this
move #16,r4 ;2T; 32 bytes are 16hword
move #StrtAddr1,r5 ;2T
loop: move @r5+,StrtAddr2-StrtAddr1-2(r5) ;5T
dec r4 ;1T
jnz loop ;2T
bic.b #TestBit,TestPort ;4T
Summing all states results in 8*16+8=136T (I apologize for mistakes); at 4MHz it means 32usec and not 80usec, please update your test results.
Surely, "C" against "assembly" is a misleading comparison, I can't make the same error I find in someone's reasonement; But (I used PIC in early age, about in 1992, I dont' remember its assembly) try to write "16-byte-move" routine in assembly and compare results. That is, when between a uP task and uP code there is a Compiler, its behaviour can change things at all.
In every case -and I conclude- I show I'm not blind: code compactness in MSP430 isn't good (eg: "byte" instruction are exactly long as "word" one; e.g: Hitachi H8s is better), and I remember PIC (I used old 16C71) was very very compact.On the other hand,Pic hasn't powerful instruction as "mov @r5+,OFFSET(r5) that atomically read WORD, write WORD and update pointer. Core comparison is often difficult, but You can't exaust this thema saying "PIC instruction are 1-cycle, TI are 1..6cycles, so we are SURELY better", without considering in detail the differences between the actions of one and other instruction.
Have a good day
Any analysis done on the equivalent controllers from Free scale and others? By the way all the comments added to this discussion generates very useful information for the designers. Thanks for all the thoughts and experience shared!
Several of the applications that I've worked on require long periods of sleep followed by a wake up and processing, then back to sleep. I've found the processing to take less time than the wake up. In this case stand-by (or shutdown current) and wake-up time dominate the power utilization function.
I find that every manufacturer touts that their processor is the lowest power. I've found the only way to truly decide is on an application by application basis. Because, each processor has it's niche that it exploits. If your application fits that niche then their processor is the lowest power.
Finding some type of objective measure would be useful, but you never know what the final numbers are until the application has been optimized for the selected processor.
I highly recommend you look at Cypress PSoC 3 family. The PSoC does a lot of work in digital and analog blocks while the MCU sleeps. Integrating the logic and analog from the board into the IC provides the lowest overall system power and cost. I've built products on PSoC in far less time than PIC and TI that were smaller and cheaper. PSoC has 1uA sleep and 200nA hibernate.
Check out their table http://www.cypress.com/?id=2232&rID=44224
I would also recommend that you take a look at the EFM32 from Energy Micro, especially the EFM32TG series.It has a 900nA sleep mode with RTC, and 20nA in power down, in addition to a 150uA/MHz current when running code on the 32 bit Cortex M3. This processor has a much higher performance per clock than the 8-bit and 16 bit processors you are currently comparing against.
aqua_man, Marius thank you for the suggestions. I haven't looked at Cyrpresses offerings, but will take a look.
As for processor selection, my group wanted to go with a single class of processor for various products and settled on ARM. That narrowed us to peripheral selection (LCD, USB, 2 I2C buses, 2 SPI busses and several timers and GPIO). After that we needed to be sure we could achieve our power budget (90 days of operation under 60mAh) We run at a sub 50Hz sample rate.
I selected and am currently targeting an EFM32LG (development is preceding on a EFM32GG). The wake up time, power/performance balance and peripheral availability in sleep modes pushed us toward it.
For purposes of this discussion I just wanted to point out that I found it very hard to select a processor purely from the data sheet. It wasn't until we had a rough design that we could select the features that could be exploited for power savings. The design has to be crafted to each processor to evaluate it objectively.
For instance, we had thought that we would be able to take advantage of the PRS (peripheral reflex system) but found that our application did not lend itself to its use. We abandoned that approach, since any savings would have been lost in the cost of configuring the system. In an application where data is collected at a higher rate, this would have made sense.
I've found that, as Cooltechguy points out, something like uA/DMIPS and DMIPS/MHz are much better indicators of final power usage when comparing 8, 16 and 32 bit architectures and even different offerings for a single vendor. Going from the PIC16Lf726 to PIC16Lf1938 for another project dropped our power usage by about 10%. That was simply a matter of changing a few names and compiling for a new target (cost delta = $0.13 per unit).
On Microcontroller Central we have been talking about the possibility of the industry creating a benchmark for measuring power in the wake-act-sleep kind of activity that wireless sensor networks and numerous other applications require. Check out the discussion at http://www.microcontrollercentral.com/author.asp?section_id=1741&doc_id=242506& and feel free to add your thoughts.
The challenge with power or energy optimization is that it depends on so many factors which are inter-related. As Taquino points out, it is hard to get the answers to all of these without doing design and prototyping on each target architecture.
I’m using the RL78/G13 in my graduate-level embedded class this semester at NC State University. (Disclosure: I wrote a textbook on the RL78 for Renesas). For the final project I let students choose their topic, and one option I pushed was benchmarking speed, power and energy for the RL78/G13 against the student’s favorite MCU. The RL78 has some very nice power and energy optimization features and numbers, and I wanted to get some datapoints about how effective they are in some sample applications. We had just had an energy optimization project (maximizing stopwatch run-time using a supercap for power) and a speed optimization project (bouncing graphics on an LCD).
I put in a caveat: They had to compare against the other processor using optimized implementations on each. Otherwise the resulting numbers are hard to believe. Sadly, none of the 91 students chose this option. So much for my crowdsourcing experiment! OTOH I believe that all 91 students now understand how hard it is to really compare the MCUs without building prototypes.
Which current dominates depends on the system design and MCU activity profile. The MCU power and energy use may be a small fraction of total system’s use. External constraints can make MCU current differences irrelevant.
Test conditions differ across manufacturers, so the reader must estimate to normalize all the performance numbers, introducing error.
How long will the MCU be idle? How many compute cycles are required? How long does the MCU take to wake up? Can the MCU avoid executing code? Is it possible to link peripherals together with hardware triggers?
Is the compiler producing good object code or not? There’s a surprising amount of variability. The list goes on…
I am seriously considering doing my own comparison test--an all out brawl--of MCUs that manufactures' are claiming to have "The industries lowest Power MCU". I plan to create three typical Low power applications and then optimizing to each processor and comparing their power performance. So far in my list of possible MCUs are:
Does anyone know if anyone else has done this? Does anyone else have a MCU they would suggest?
Hi, STMicroelectronics has announced a new 32-bit ultra-low-power microcontroller named STM32L0. The MCU is based on a Cortex-M0+ core and show only 400nA power consumption with full Ram retention in stop mode (with fastwakeup time 3.5us). On top of that the ecosystem of STM32 is now really cool with Discosvery kit, Nucleo kit, CUbeMX toolset, Mbed compatible ...
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.