Yet another 'what micro to use', be gentle..

[Buriedcode]

Hi there,

Well I have a project that involves basic GPS and a smallish (128x128) tft display. Portable with very low power consumption and size are the main constraints.  I'm fairly experienced in 8-bit and 16-bit devices, PIC16/18F, AVR etc.. but given the display requires a basic menu system, and the flash to store the pages (and  >6kb SRAM for logs, because its lower power than external flash) it looks like it's a job for a 32-bit device, to me it says 'm0'.  With so many vendors, devices, as you can tell by the large number of 'which is better?' posts, I too have become overwhelmed by choice.

It is fairly straight forward to narrow down results based on power consumption and peripheral set, but even then, I've ended up with a long list where all devices meet requirements and are fairly low cost to boot.  These include:

-Atmel SAML, SAMD series: Good experience with Atmel, only requires a dev board (with on board programmer/debugger) and Atmel studio.  I'm familiar with the docs and doesn't seem a great leap from AVR's. Haven't' seen many hobby projects based on these. Seems much more vendor specific than the following.
-LPC11xx:  never used NXP devices, but there's a lot of example projects on the web, a big following. 
-STM32L, or F0:  Again, big following, cheap dev boards (with built in debugger).  Plenty of resources, but seems like it requires a lot of set up for the dev enviroment.
-EFM32: Wild card, seems to have the lowest power consumption, plenty of peripherals and fairly cheap, but I have no idea where to start with a toolchain.
-PIC32: seems to be the easiest to get started, but doesn't appear to have the best power consumption, and isn't ARM based so might provide and excuse to 'put off' getting used to using ARM devices.

I'm sure all the above are more than capable, but as always, I get stuck on making decisions because it would be nice to not be completely locked into one vendor (specs change!) which means I'm leaning towards LPC11 or STM32, but the very basic (and common question) is .. where do I start?!  I have read plenty of threads that list wildly different setups from 'just buy the IDE' to open source toolchains requiring multiple systems configured.  Of course a single all-in-one IDE would be ideal, but there are even quite a few of those it seems.  I listed the SAML (or SAMD) first because, well, Atmel is tried and trusted.

So I know I'm probably going to get flamed for this, and there will be those furiously defending their 'choice', and I am acutely aware there is no 'best' vendor.  But at the same time, the idea of buying a few dev boards, installing multiple IDE's and trying them one at a time doesn't thrill me.  The restrictions are no longer 'cost and availability' but 'time taken to get a reasonably comfortable working environment/flow for 'blink' projects, and regular code modifications.

I may even start developing the main menu and sensor algorithms on an... Arduino... purely because there are many libraries for taking the donkey work out of drivers, and they are just very easy for testing software snippets, basic algorithms and getting used to communicating with external devices.  But it is far from ideal for the application (2-3V, low power, and low duty), so I'm using this as an excuse to get a wriggle on, and asking the forum what they would consider the most straight forward (no manually creating makefiles, 'good enough' built in libraries and simple workflow) vendor to go with.

Apologies again, I'll try to ask this again... but I simply don't have time to try them all.

[rstofer]

Once again, I am going to trumpet mbed and its web based IDE.  You install exactly nothing.  Of course it is limited to boards that are mbed compatible but that now includes a LOT of boards.  One of the LPC11xx boards is included:

https://developer.mbed.org/handbook/mbed-NXP-LPC11U24

Many of the STM boards are applicable as is the original LPC1768.

There is a lot of library code already written but you can choose to ignore all of it and deal directly with the iron if you wish.  It's worth a look!

[wraper]

Simplicity Studio from Silicon Labs is easy to start with IMO. Just install and use, have HW configurator and various software examples built in. Dev boards are cheap and have built in segger j-link. Can be used as programmer/debugger for external devices.

[JPortici]

i had to make a simillar decision: small project, needed low power and "lots" of ram for a data logger
i made the exact same list and decided to use an LPC11U68 (i needed USB)
i decided not to use STM because -to me- it is a nightmare to program them and to understand their documentation. i find NXP to be a lot easier

you might want to take a look at pic32mm but you clearly say you want to try something 'really' new, like an ARM chip

[zapta]

i had to make a simillar decision: small project, needed low power and "lots" of ram for a data logger
i made the exact same list and decided to use an LPC11U68 (i needed USB)
i decided not to use STM because -to me- it is a nightmare to program them and to understand their documentation. i find NXP to be a lot easier

you might want to take a look at pic32mm but you clearly say you want to try something 'really' new, like an ARM chip

NXP's free IDE and toolchains are easy to install. A single package install (lpcxpresso) and works on all platforms. If you use mbed, you can also export your entire project to lpcxpresso and work 100% offline.

If you are looking for a simple open source NXP M0 circuit search for 'arm pro mini'. It's a minimal design that you can modify for your own customized boards. The documentation includes everything you need. You can use it with or without mbed libraries. The design also has a USB port that allows to upload new firmware without any special software or hardware, just a standard USB cable (you don't even need to program the bootloader, NXP does it for you), very handy for sending firmware updates to users.

BTW, one vendor that you didn't mention is TI. Never used their MCUs but from what I heard they also have a good IDE and low power MCUs.

[dannyf]

wildly different setups from 'just buy the IDE' to open source toolchains requiring multiple systems configured. 

That's because people's have diverse needs.

If you intend to make a living off of this, try the commercial tools: iar or keil.

if you just wanted to learn about those chips, pick a free toolchain. My favorite is CoIDE 1.x, emblocks, and then vendor specific tools (like lpcxpresso or ccs).

As the core is mostly transparent to a C programmer, focus on the peripherals and support. I like TI/Luminary parts for (my) legacy code and their feature richness, but they are buggy, and TI's support for the msp432 is terrible.

I use a lot of STM32F030 in tssop20 package, as replacement for 8-bit parts. STM32F103C8 boards are widely available and quite inexpensive.

LPC11xx is probably the most popular CMx chip from NXP.

I may even start developing the main menu and sensor algorithms on an... Arduino...

90% of my code for mcus are written on Turbo C (from 1980s) and Keil C51. So you are 30 years more advanced than I am,

[hans]

I can confirm that Silicon Labs EFM32 is very easy to get started with. Boards are like 25$ since a few months. Simplicity Studio is one (admittedly large) download that installs an Eclipse IDE with everything built in, ready to go. You also a get a debugger on board. Some eval boards also have a power analyzer tool that can give a indication about the current consumption of your board (i.e. firmware + hardware power state). It measures it in Watt momentous power and Joules of consumed energy. It samples at a fairly high rate, so it's also fairly accurate to use. And it's not cloud based like mbed, so you can work outside of home(/without internet) if that interests you.

The EFM32 chips are nice for low power stuff. Their datasheets are really geared towards that because they supply information about the different power states of the chip at each peripheral, which is very nice. In general I really like their stuff, it seems quite polished.
1 shame is that they don't have "application CPU's"  (like the STM32F series that are so popular). By that I mean CPU's in large packages with 80MHz+ CPU's, half a dozen SPI and UARTs, 100Mbit ethernet MAC, etc. Their micro's are really geared towards battery operation applications and internet of things.

[MT]

-STM32L, or F0:  Again, big following, cheap dev boards (with built in debugger).  Plenty of resources, but seems like it requires a lot of set up for the dev enviroment.

One more time a drum roll for: EMBLOCKS does not need to be setup, a install, thats it, Gerard have a minimalist approach to it all but dont get fooled by that it's indeed used by many for commercial volume products. Not every single device is supported but plenty enough to cover majority of apps and if you ask nicely he more then often fix support for new or odd devices.

http://www.emblocks.org/web/

[zapta]

http://www.emblocks.org/web/

Windows only, yuck.

Less valuel for open source projects.

[bobaruni]

As others have said, Em:Blocks /Embitz is free and no limitations, it uses open source GCC and is a fast and clean environment without bloat.
With STM32, you're up and running in 5 minutes (I have not used it for other vendors but it works for NXP /PIC/ AVR etc but can't comment on how good it is for these).
Just install it, and configure your ST-Link and you're up and running, if you don't like it, uninstall it.

[dannyf]

I have not used it for other vendors but it works for NXP /PIC/ AVR etc but can't comment on how good it is for these

It works with PIC24 superbly - it is my go-to environment for pic24. I am a big fan of it and have been using it since its beta days - as a matter of fact, I am still running the beta now.

[andersm]

If you've used 8-bit PICs you're already familiar with Microchip's development environment, and you may already have a suitable debug probe. That said, it's definitely worth familiarizing yourself with the ARM world at some point.

[sporadic]

Atmel provides a pretty nice turn-key solution with Atmel Studio (free) and the SAM D series.  You'll need to spring for an Atmel-ICE Basic (~$50 iirc) and their chips tend to be a little pricier than others.  A fully integrated system with debugging that just works and good datasheets / appnotes could make it worth it.  The ASF stuff can be a little cumbersome at first, but I think that could be said for any vendor specific library set.  They have plenty of appnotes to help you along.

[Sal Ammoniac]

How about Eclipse/CDT/GCC? All of the pieces are open source and it takes about 30 minutes to get everything set up.

[MT]

http://www.emblocks.org/web/

Windows only, yuck.
Less valuel for open source projects.

Its on the move to Linux, be patient.

[dannyf]

The arm situation is quite similar to the 8051 situation: the same core got coupled with vastly different peripherals and performance tweaks for different markets.

You rarely hear people asking which 8051 to use, because there is a high degree of transparency.

Instead, the focus is on peripheral, support, code base, tool chains, etc.

The same for the arm chips: the core doesn't matter.

[Buriedcode]

Wow thanks for the replies!

I was half expecting a couple of 'just try one' comments, or perhaps veering of into some specific quirk of different devices, but also had faith that many here are experienced and so provide pros/cons. You didn't disappoint!

I looks like LPC11XX and LPCxpresso is definitely worth a try. Even if it doesn't really work out, a single IDE, and devboard... wouldn't have to invest much time or money.

I have seen EmBlocks mentioned many times in other threads, like above, a single download and support for *some* devices I'll likely use - it would be silly not to install that too.  You guys mentioned it covers PIC24, STM32 (maybe not many devices, but diverse) so if it works out, that could certainly get used a *lot* as I have probably 12 regular projects, all with different devices.

I was leaning to the STM32 not out of necessity but just the feeling I was 'missing out' on something.  So it was more obligation - using this project as an excuse - than 'need'.  Every time I go to buy a cheap dev board (includes J-link debugger?) I look over at the 15-20 other dev boards for various bits that I haven't touched and wonder if it will join them.  I'll put that on the back burner, with EmBlocks in mind instead of a convoluted toolchain.

DannyF:  Yes, choosing the core wasn't really the problem; m0+ has everything I would need with low power and no need to go over ~32MHz, and I can pick out devices by peripherals.  The trouble was/is indeed the code base and tool chains.  Whilst its nice to think 'well, worked with one ARM, you can work on any' I know this is not the case - different vendors, different implementations of peripherals, but getting my foot int he door hopefully will stop me discounting project idea's based on CPU limitations.

And I'm glad someone else mentioned Atmel.  With Arduinos and AVR's everywhere, I see little mention of the SAMD series, or the SAM4S.  I suspect this is just because they are seen more by their cores (m0, m4) than an Atmel device.  The debugging/configuring tools seem pricey, although I have a couple of 'Xplained' boards that were quite cheap and can be used as standalone debugging hardware.  Something to do in spare time, but for now, this is a project I'm paid for so I can't really charge for tinkering.

Sorry for the disjointed reply... trying to catch all responses. I was wondering if I would end up just looking at one device, but I'm actually curious enough now to try three...

[Buriedcode]

Wise words Diligent.

Using 8-bit machines, I think I've been kind of spoiled with regards to low power usage - generally with such simple systems one just has to change the oscillator speed on the fly, sleep, the interrupts are fast and a handful of modules that can be powered down.  Once you start to bring in higher bandwidth usage I was worried I'd have a 32-bit device 'burning' 10's of milliamps just moving data about as quick as it could (rather than needing to do anything more complicated like minor dsp).  But all the m0+'s I've seen have things like DMA, which helps pull double duty with things like display refreshing, fast interrupt handling, and various power down modes.  Then there's fast wake up, automatic sleep after certain functions etc.. all of which helps to minimize time running at full speed.  Sure the M3 and 4 have similar capabilities, but at a higher power consumption.  Those are of course designed without low power as the prime concern (still a concern though!).

I noticed that the EFM32 'gekko' (perhaps their other devices too..) even have the facility to connect two peripherals together, that can leave the CPU stopped in power down, for again, rather mundane tasks like just moving data.  Perhaps not something one would use regularly, but a neat capability for the typical 'basic micro' tasks they are designed for.

[dannyf]

Once you start to bring in higher bandwidth usage I was worried I'd have a 32-bit device 'burning' 10's of milliamps just moving data about as quick as it could

For such projects where low power consumption is required, the number step is to get a perspective of the power profile. Sometimes, a fast 32-bit processor is better: like in math intensive tasks; other times, it pays to detune the processor and keeps it running constantly.

Getting the profile of your application will help you a long way in figuring out where to start.

TI has an excellent paper on this, in comparing their MSP430 vs. PIC24F. Well worth reading.

[danadak]

Cypress PSOC. Low end PSOC 4 (M0), PSOC 5LP (M3), routable,
onchip Vref, DelSig to 20 bits or SAR to 12 bits, tons of "compo-
nents" (their word for HW features) all with lots of code APIs to control.
Linear, OpAmps, Comparators, IDE free, many boards $ 10, some
at $ 25.

Parts with DMA, Digital Filter, LCD, HW that can be created by GUI drag and drop
or use Verilog (it has FPGA like HW fabric on top of the standard HW blocks).

http://www.cypress.com/documentation/product-selector-guide-psg/product-selector-guide-psg-psoc-programmable-system-chip

Attached, depending on part, its catalog of component HW.

Roadmap      http://www.cypress.com/file/151476/download

Focus on PSOC 4, 5LP families.

Regards, Dana.

[hans]

In my experience, low power has 3 crucial aspects:

1) Sleep (and quiescent) current of all hardware devices on board.
2) Wake current, length and period of devices on board.
3) "Amount of work to perform" on the microcontroller, and of course the efficiency of the CPU.

With these 3 points I would say low-power is in unweighted form half hardware and half software. However, it depends on the application which side is emphasized. For example:

If you use a RF radio (IoT sensor node or something), you may find that the radio consumes 90%+ of the battery charge. Sure you can optimize the crap out of your firmware and MCU choice, but it may only increase battery life by 5% at best. On a 2 year battery life, that's like 1 month. In this case it could be much more efficient to focus on radio power management.
Other applications may completely rely on the CPU efficiency, e.g. battery powered watch or calculator. In that case sure optimize the crap out of your code, and do some proper research which platform runs said code most efficiently.

As for 1) I tie every device that is not used constantly to a power switch or I/O pin so it can be turned down completely. Some chips, like sensors or radio's, have like 1 or 2uA sleep current.
Choose low quiescent current LDO's; or preferably none at all (power directly from coin cell battery with all components chosen to work over a wide voltage range).
Choose a microcontroller with low sleep + RTC/WDT currents.

For 2) it depends on the application and how you can use the microcontrollers peripherals. Some chips have very short wake times (i.e. deep sleep with on oscillator, to a running code mode), so you can utilize interrupts much more efficiently. Some have DMA, that can be triggered and left running in an idle or sleep mode. I believe SiLabs micro's have 2us wake times, PIC24 about 5us,  and some MSP430 in 1us.

Additionally I found that you should consider running the microcontroller at highest frequency if it's doing computationally bound stuff. Although uA/MHz sounds fairly linear, in most cases it increases at lower frequencies because of fairly constant bias currents for things like crystal oscillators etc. E.g. a crystal oscillator may consume 100uA at 4MHz clock (25uA/MHz) and 200uA at 24MHz clock (<10uA/MHz), it becomes obvious which one has the edge.

For 3) is a hard guess. For a given project you have X amount of work to do, and each CPU architecture (PIC24, MSP430, cortex m0+, m3, m4 etc.) will compile to different binaries of different size, throughput etc, highly dependent on the compiler quality, code quality, operations performed, etc. And another question comes to my mind: if I run my code on a m3 chip instead of m0+; does it mean the short execution time outweigh the higher uA/MHz?

Obviously you can make a wild guess to what is best. If you deal a lot with 32-bit integers, pick a 32-bit CPU instead of a 16-bit PIC24 or MSP430.
If you deal with lots of floating point, use a STM32L4 with FPU
If the code is just some if-then-else code, well probably m0+ is fine and a m4 is a waste.
In other cases, for example AES security in IoT, you may find that hardware accelerated AES makes a huge difference.

IMO it's impossible judge those figures from any manufacturer supplied document. Of course Microchip will say their chip is the best and most versatile low power 16-bit MCU, while TI will say Microchip is wrong and theirs is the best. No shit sherlock. It may point out some valid points and traps, tested accordingly, but I would rather see something like that from an independent source like CoreMarks, ULPBench from EEMBC, or preferably own testing results.

[bobaruni]

Well I have a project that involves basic GPS and a smallish (128x128) tft display. Portable with very low power consumption and size are the main constraints.

Just use whatever MCU you are comfortable with and just program it well (make it sleep more often than not and use interrupts where possible).
If Your TFT is always on, it's is going to draw most of the power and dwarf anything that the MCU sips on.
You could use an e-ink display as it doesn't need a back light and can be configured to be powered up only when screen updates are required, the rest of the time the e-ink module can even be disconnected from power and will still retain the last displayed image.

[Brutte]

UART, SPI, small package, >6kB ram, low power, 4 IOs for menu buttons...

Sounds like that spans from ATMega up to low end ARM Cortex-A.
Would you mind narrowing that down a little bit?
What is the quantity needed?

[Buriedcode]

Well Brutte, I didn't specify exactly what the system was, just the basics (not my place to share potential customer IP).  But whilst I'm demoing some of the functions with an Arduino (atmega328), drivng a full colour TFT quickly (to save power) and having large flash for storing different pages led me to discount 8-bitters altogether. Sure, they can easily be put to sleep, throttle clock, and generally have the peripherals, its pushing it - especially as I will most likely have to add more sensors to this later.  Having two UARTs, SPI, I2C's, and a DMA to help with screen refresh, would, I think, make my life easier, and save power (in terms of run time). 

There's another group of devices I've used a few times, but don't' seem to have much of a following - the Xmega series.  8-bit, has DMA, plenty of peripherals (perhaps too many... at last two of everything, often 4) 12-bit ADC< and  DAC. I have been stung before by their flaky ADC's (perhaps it was early silicon revisions) and they are not known for their low power.  The mains reason though, is, cost. Should this go into production, there are plenty of m0's going for ~$1 that have everything I need and more, where-as Xmegas start at about $3, perhaps even $4 for the minimum requirements.

And whilst different manufacturers have different peripherals, it still should be easier to switch between m0's, than from 8 to 32-bit later on for cost reasons.

[dannyf]

 '- the Xmega series'

Pure vaporware. Never had a reason to exist and died before it was introduced.

Feel bad for those invested in it.