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

[Brutte]

Well Brutte (..) Should this go into production, there are plenty of m0's going for ~$1

But it is you who have to decide if that is for low volume (rip off some Nokia surplus and you already have the TFT, battery, charger and the case) or the mass production (BGA, 8-layer board, 4 generations of prototypes, at least). If that is a $5 BOM product then indeed 1$ or 2$ makes a difference when the plans are for hundreds of thousands to be manufactured. If you want to make 100 then it does not make sense to save $100 and dick around with $1 M0.
What is your BOM expectation? I suppose this is the very first thing you start from when your plans are to sell the thingy! What about googling "teardown" of similar products? Dave does that regularly and BOM is not a rocket science, just visit DigiKey, make a BOM list.

IIRC there was a pebble watch ripped apart some time ago, similar spec than yours. TFT, small, portable, battery powered low power, nothing fancy really. No GPS though.

What is the quantity needed?

If you insist on keeping key factors secret then I am afraid the topic won't go anywhere.

[asgard20032]

But M0 can still be good, it just depend on what they do. People just have to realize that its not because an mcu has 32 bit and target 8/16 bit application that they are suppose to printf and use a display. Those mcu could find more use in a headless environment (no terminal or display), where no big library function get compiled.

Where can such device be useful? Simple application (like microwave oven), small PID loop that dosen't require fast update rate (like a temperature PID, temperature change slowly), datalogging not involving string character, measure instrument like multimeter...

[dannyf]

'm0 has horrible code density. With some drivers and printf() it easily gets 30k+ (tested on PSoC4'

My experience across multiple families of chips and toolchains has been that the bare minimum is about 1.5 to 2kb for the overhead and then about 2k for printf integer and 3k for printf floating point.

32k for a printf minimum seems to be wildly wrong.

[jesuscf]

m0 has horrible code density. With some drivers and printf() it easily gets 30k+ (tested on PSoC4), so it leaves you only <2k user code.
While for XMEGA, the code density is rather high, so the same 32KB flash can hold more goodies.

That is if you use newlib nano!  If you don't use newlib nano it gets much worst.

[krho]

'- the Xmega series'

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

Feel bad for those invested in it.

Why?

I like it. I can go up/down in the family. And the code stays the same.

[andersm]

That is if you use newlib nano!  If you don't use newlib nano it gets much worst.

Even with normal newlib you can avoid the code growth by using the integer-only versions of the stdio functions (iprintf etc.) Even if you're not actually printing floating-point numbers, the formatting code causes the floating-point emulation code to be pulled in.

[asgard20032]

That is if you use newlib nano!  If you don't use newlib nano it gets much worst.

Even with normal newlib you can avoid the code growth by using the integer-only versions of the stdio functions (iprintf etc.) Even if you're not actually printing floating-point numbers, the formatting code causes the floating-point emulation code to be pulled in.

Really interesting, nevour tought about that. I am sure it apply to most library out there right? Can some people confirm if it apply to msp430 gcc, msp430 ti proprietary compiler, xc8, xc16, xc32, arm gcc...

[dannyf]

Most libs are like that. As a matter of fact, I have yet to see one where the floating support is built in by default.