There are people who care about power as well, right? E.g. the security system where I'm living now has remote wireless units with fairly big lithium batteries that last roughly 10 years....
Not as much as you would think.
Battery life in the embedded space is mostly defined by how much you can stay off and what your leakages are rather than what your active current is--since you can quite often just stay asleep a little longer.
Most of these microcontrollers are in the same range for leakage and are at the point where you have to start considering other leakage sources on the board (capacitors for example).
It's Amdahl's Law in action: the big contributors have all been smacked down pretty much as far as they can (sure, you might get 10% here or there ... but it's going to be real work now) so now getting overall performance isn't so easy.
If someone really wanted to get my attention with their microcontroller, they should produce a combined BLE/WiFi chip where the WiFi can be run off of a coin cell battery like BLE (that would mean something like 2mW transmit power rather than 200mW).
High-bandwidth signals require more power to travel a given distance, low-bandwidth signals go farther on less power but transmit less information. Intuitively this is why you can go worldwide with CW (Morse code) on just a few watts of power, while a SSB signal on the same frequency doesn't go far at all. But I think you can mathematically support this by playing with the bandwidth+power terms of the Shannon-Hartley theorem.
If we want to transmit a given amount of data per time unit, there are two natural extremes. We can either transmit it at the average data rate necessary, or we can race-to-sleep by blasting it out as fast as possible. I'm not sure which is more efficient given that SNR is inside the log2 of the S-H theorem, it depends on the relationship between SNR and bandwidth as you spread a given quantity of RF power thinner and thinner. Based on the log2 I would think this is an inverse-square kind of thing, making it an equivalent tradeoff.
Showerthoughts: because of the Inverse Square Law, it's probably more efficient to make a mesh of multiple small hops than a single long shot. As the spacing of the mesh decreases to zero, you end up with a wire.
Also, check out the ESP8266 chip, it doesn't have a BTLE onboard but it does handle the "SOC with low-power wifi" thing.
I know all about it. Still won't run on a coin cell.
Nobody will build a 2mW WiFi chip until Apple forces somebody to build it. Then EVERYBODY will rush to build it. Then EVERYBODY-1 will go bankrupt when Apple doesn't use their chip.
It's the Zen of Hardware.
As an embedded firmware developer for 18 years, I've seen every project has its own constraints, just like most engineering. Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on.
IME, Atmel had a great 8-bit series with good documentation and few bugs that scaled from 8-pins to 40 very well. With analog inputs and PWM output, they were well-equiped to do analog input->processing->output tasks. They really blew it when they moved to 32-bit as others have said. They weren't very fast, changed all the peripherals around and didn't improve on the clumsy fuse system. ARM M ("M"->embedded) Cores like stm32f4, Freescale Kinetix, etc. have all but obliterated Atmel.
Finally differentiation in the Cortex family includes ethernet (F27/F29), Front-side Memory Controller, FPU, low-power (STM32L0), extreme low power (MSP432), low-price (STM32F0) and so on.
No argument.
> Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on.
True. But most of the embedded work I have been dealing with over the last 5? years seems to be very different from prior. In the last 5 years, choice of microcontroller moved from contentious to almost an afterthought: 8-bit, 16-bit, 32-bit? Motorola/Atmel/Microchip/ST/Renesas? gcc vs proprietary? Sufficient frequency? GPIB/RS-232/USB? All gone.
I get asked about memory and footprint (BGA/CSP is starting to become popular ... bangs head on wall) and that's about it. Even cost just doesn't come up much anymore--I don't know if its that things are cheap enough or that everybody now actually knows what microcontrollers cost.
Pretty much things seem to be splitting into two bands: internal memory only (M0, M3/M4 class--generally an RTOS) and external memory (A-class+, runs Linux). And, given some of the higher end M-series, I suspect Linux is going to hit there shortly.
Lots of people want data about business processes and throwing some coin cell sized boards with BLE and sensors into a product as it goes from start to end customer can be enlightening ... sometimes too much so for some businesses :). The real trick is having the infrastructure and team to receive and analyze the data (which we do now that we've done it enough).
Industrial automation is in the mix. A lot of that has been moving from combinations of IEEE-488, RS-232, USB or other non-differential links to CAN and Ethernet. Customers are often amazed how many fewer problems they have when they use a connection that is actually electrically differential.
It's gotten to the point that when I hear "reliability issues" I look for USB and just wipe it out. Generally there will be a network of PC's connected via USB to "random industrial machine X" or, worse, PC->USB Adapter->RS-232/IEE-488/etc. (to be fair--the old systems with actual RS-232 ports or IEEE-488 cards generally worked fine as they had more than enough signal overhead and shielding to deal with industrial electrical spikes--it's the USB interface that disconnects and causes Windows to crap its pants).
A replace of a bunch of those with something with a CAN interface generally fixes industrial problems. I finally sat down and wrote my own CANOpen stack because I was using it so frequently.
Medical and bio is an occasional, but that hasn't been such a big mover for me lately. The people who cut checks and the people who actually know what their problems are are too far apart in the hierarchy right now. My big problem in bio is that I could do quite a bit using full-custom VLSI to go to ultra low power functionality, but nobody wants to pay for that. So, I'll continue to use off-the-shelf microcontrollers and FPGA's and use way too much power.
Most of my grief these days isn't electrical. It's mechanical. I used 3D printers and silcone molds a lot. Very messy and annoying to work with, but it saves us having to cut molds for injection molding.
I can 3D print a lot of parts for the cost of even a single injection mold. And my margins aren't so tight that I need the cost savings. And I can change the part if something is wrong. And I don't have to scream at the mold maker when (not if) he screws my mold up.
To be fair, this isn't really an issue unless your device grounds are likely to have more than a couple of volts difference due to spikes. And that happens very rarely in the home or office.
In industrial settings, however, that's not true.
However, for most projects I see, people don't care much. A better efficiency in a car is good, but a few microwatts can't compete with double the RAM in this context.
Lots of electronics projects are not battery dependent, and engineers care more about reliability, development ease and speed and flexibility. I surely like the idea of not reimplementing a firmware ten years from now by just upgrading the micro controller, instead of dealing with a whole new set peripheral drivers.