$1 MCU review — looking for part suggestions!

[funkathustra]

Breaks can get interesting when you have a FIFO'd UART, and a UART error interrupt. I don't recall the CPU but I've seen a situation where the error int happens when the UART is still in the FIFO behind some data.
This caused an issue only with DMX coming from I think a Pharos unit, which sent the break immediately after the last byte of the previous frame.

Haha, it's really serendipitous that you should mention that. The Nuvoton M051 part I just finished testing on last night had this issue. I created a bit of a weird state-machine that sets the FIFO to 1 byte until a framing error happens, and then increases the FIFO to 14 bytes, until it gets halfway through, and then resets it to 1 again. This way I can start receiving at an arbitrary period of time and still use the FIFO.

...of course, once I did all that, I lowered the clock rate to the minimum (which is still pretty high -- it's only a divide-by-16 system divider from a 22 MHz internal oscillator), and the system could easily handle the single-byte reception, thus making the whole thing pointless in this particular application :-)

The wait states in the main busy loop helped a ton with overall power consumption, but didn't change anything at all with or without the FIFO enabled.

I want to go back and use the Renesas RL-78's DMA (yes, a 60-cent 8-bit MCU with DMA!) to see if it changes the power consumption, but at 500 µA, it's currently leading the pack (lots more to review, though, and I've basically only been doing industrial-targetted MCUs that don't have good power figures).

I can't wait to finish testing all the Cortex-M0 MCUs, since the two that I've tested so far — the Freescale/NXP KL03 and the Nuvoton M051 — have vastly different interrupt routine timings with respect to the UART. The KL03 didn't raise an interrupt until halfway through the next byte, and it took about 70% of the byte period to get through the ISR. The Nuvoton part, running at the same frequency, took no time at all — maybe 1/15th of the period. Same core, same interrupt system. Must have vastly different UARTs with different latencies. Totally different power consumption figures, too.

[westfw]

Silicon Labs gives away full versions of Keil's C51 compiler when you install their free Eclipse-based IDE, Simplicity Studio. And, it's completely cross-platform

Does the SI license say you can use the compiler they provide on other vendors' chips, or are you just engaging in a subtle form of piracy?

The whole comparison thing might be more interesting if done at more price levels (perhaps with fewer chips at each price level.)  In general, I feel like I have a much better idea about what a "typical" $1 microcontroller will do than "do you get 5x or 10x the capabilities with a $5 or $10 microcontroller?"  (and a comparison at the $15 level (near the top-of-the-line for AVRs) is a lot more dramatic in some ways.  The 8bit chips are about 256k flash and 8k of RAM, while the 32bit chips are up at 1MB flash and 256k of RAM!)

[gamalot]

A few days ago I bought some STM32L011D4P6TR for about $0.97/pc on Taobao.

[Yansi]

Of course, Cortex-M0 parts that cost the same have come in and wrecked both of these in terms of raw processing performance and nJ-per-sample power consumption figures (but not power consumption in wait/sleep modes!)

Also cortex M at such price don't have such interesting peripherals. For example, with EFM8UB1 I can get MCU with crystal-less USB, 5V tolerant GPIO, internal 3.3V voltage regulator which can supply up to 100 mA to external devices and 12 bit ADC for around $0.60 @100pcs. That is pretty amazing.

Look at STM32F042. 

[funkathustra]

Does the SI license say you can use the compiler they provide on other vendors' chips, or are you just engaging in a subtle form of piracy?

Of course it's restricted to SI chips. While I recently wrote a blog post about using Simplicity Studio (thus, Keil C51) to program a 35-year-old MCU, it was done more as a fun exercise — it would be dishonest to program other 8051s in Simplicity Studio with the unlimited Keil license; especially for commercial purposes.

There's also not much reason to; most other 8051s are inferior to SiLabs' parts, and aren't much cheaper (if at all) — especially for people developing outside of China.

[wraper]

Of course, Cortex-M0 parts that cost the same have come in and wrecked both of these in terms of raw processing performance and nJ-per-sample power consumption figures (but not power consumption in wait/sleep modes!)

Also cortex M at such price don't have such interesting peripherals. For example, with EFM8UB1 I can get MCU with crystal-less USB, 5V tolerant GPIO, internal 3.3V voltage regulator which can supply up to 100 mA to external devices and 12 bit ADC for around $0.60 @100pcs. That is pretty amazing.

Look at STM32F042. 

Well, I looked on it briefly  . Costs more than twice as much. No internal 5V -> 3.3V regulator, ADC capable inputs are not 5V tolerant. To use it with USB, instead of just a few decoupling caps I would need to use external VREG. ADC is much less versatile, no analog gain adjustment (0.5/1). Only single 1.25V reference voltage (1.65V and 2.4V for UB1). No analog comparator, UB1 has 2 of them, no internal DAC (used with comparators, both inverting and non-inverting inputs). UB1 comparator also has programmable hysteresis.

[funkathustra]

In general, I feel like I have a much better idea about what a "typical" $1 microcontroller will do...

You have good intuition about that? I don't — and I think a lot of people don't, either. There's a lot of opinions floating around, but not a lot of facts.

• Is a 24 MHz Cortex-M0 is faster or more efficient than a same-price 72 MHz 8051?
• Does PIC's super-high clock rate + low-power make it comparable to the more-efficient-clock-cycle AVR? Better? Worse?
• I know code density is worse on Cortex-M0 chips, but how much worse? What happens when you factor in all the manufacturer-supplied peripheral libraries?
• Are 16-bit MCUs a "sweet spot" between the 8-bit and 32-bit guys, or just a waste of time? What about weird 16/8-bit hybrids, like the Renesas RL78 that has 8-bit data paths, but a 16-bit ALU?
• Honestly, is there even a reason to mess with 8- and 16-bit MCUs? Should everyone just use Cortex-M0s for low-end stuff?
• Which manufacturers have the best IDEs? Code-gen tools? Peripheral libraries?

"do you get 5x or 10x the capabilities with a $5 or $10 microcontroller?"  (and a comparison at the $15 level (near the top-of-the-line for AVRs) is a lot more dramatic in some ways.  The 8bit chips are about 256k flash and 8k of RAM, while the 32bit chips are up at 1MB flash and 256k of RAM!)

Excluding the Propeller and XMOS and a few other weird architectures, most every family has a $1 entry on my list, so once you compare the base members, you're good. If you want to compare flash densities or other basic parametrics, just hop on DigiKey or something.

Those things don't interest me as much as development environment, code-gen tools, peripheral libraries, development hardware, performance, peripherals, and power consumption — but hey, the Internet is big enough for both of us! Maybe start a parametrics comparison project?

[funkathustra]

Look at STM32F042. 

Well, I looked on it briefly  . Costs more than twice as much. No internal 5V -> 3.3V regulator, ADC capable inputs are not 5V tolerant. To use it with USB, instead of just a few decoupling caps I would need to use external VREG. ADC is much less versatile, no analog gain adjustment (0.5/1). Only single 1.25V reference voltage (1.65V and 2.4V for UB1). No analog comparator, UB1 has 2 of them, no internal DAC (used with comparators, both inverting and non-inverting inputs). UB1 comparator also has programmable hysteresis.

On the bang-for-your-buck metric, you ain't gonna beat an EFM8UB1. For typical USB full-speed devices, it's nearly perfect.

[Yansi]

Look at STM32F042. 

Well, I looked on it briefly  . Costs more than twice as much. No internal 5V -> 3.3V regulator, ADC capable inputs are not 5V tolerant. To use it with USB, instead of just a few decoupling caps I would need to use external VREG. ADC is much less versatile, no analog gain adjustment (0.5/1). Only single 1.25V reference voltage (1.65V and 2.4V for UB1). No analog comparator, UB1 has 2 of them, no internal DAC (used with comparators, both inverting and non-inverting inputs). UB1 comparator also has programmable hysteresis.

On the bang-for-your-buck metric, you ain't gonna beat an EFM8UB1. For typical USB full-speed devices, it's nearly perfect.

Maybe from the buck point, otherwise no, nope.  But it is interesting MCU.
What I do not understand is the price point the 32F042 is usually sold at 1-off quantities at the usual distributors. As I do know for what price it is usually sold at quantities (not that large), it is kind of mind boggling. (but not only with this one)

[coppice]

You have good intuition about that? I don't — and I think a lot of people don't, either. There's a lot of opinions floating around, but not a lot of facts.

• Is a 24 MHz Cortex-M0 is faster or more efficient than a same-price 72 MHz 8051?
• Does PIC's super-high clock rate + low-power make it comparable to the more-efficient-clock-cycle AVR? Better? Worse?
• I know code density is worse on Cortex-M0 chips, but how much worse? What happens when you factor in all the manufacturer-supplied peripheral libraries?
• Are 16-bit MCUs a "sweet spot" between the 8-bit and 32-bit guys, or just a waste of time? What about weird 16/8-bit hybrids, like the Renesas RL78 that has 8-bit data paths, but a 16-bit ALU?
• Honestly, is there even a reason to mess with 8- and 16-bit MCUs? Should everyone just use Cortex-M0s for low-end stuff?
• Which manufacturers have the best IDEs? Code-gen tools? Peripheral libraries?

• A real 12-cycle 8051 core is always pretty slow. With a modern single cycle 8051 core code that's heavy in bit banging can be really fast and dense. However, the code looks slower and more bloated as the complexity of the code increases. Try running some C code that uses the full power of the language - lots of structure manipulation, and so on - and 8051 code from the best compilers looks pretty bad. So, speed depends a lot on the kind of code you are running.
• The PIC is largely in the same category as the 8051, with regard to what it does well and does poorly. The AVR runs most complex C code pretty well.
• If you think M0 code is less dense, that might reflect the kind of code you have been looking at. Try some serious maths, and the M0 code should look far denser than any PIC or 8051 code. Pretty much anything using the real power of the 32 ALU should result in denser code.
• One 16 bit core which does hit a sweet spot is the MSP430. It does pretty well on bit banging. It does pretty well on compute. C compiles very well for it. I have seen people get pretty good results with some RL78 devices running full featured C code, but I don't have personal experience.
• Right now there are quite a few Cortex-M0 devices around, but it will take time for the rich selection of application specific devices available with other cores to be fully replicated by M0 parts. So, during that window 8 bit devices will remain relevant. In the longer term, who knows? Will the M0s hit the same energy efficiency targets as the MSP430 and RL78 families in real world usage (rather than benchmarks)? Will there be a good selection of sub 20 cents M0s?
• Most hardware manufacturers struggle to take software seriously, even if they know they should. The hardware people tend to look down on software, so there are cultural issues in most companies. Doesn't expect that to change any time soon. You will usually have to use the maker's peripheral library for complex peripherals, like USB or ethernet ports. For simple peripherals the bugs and limitations in most vendor libraries can make them more of a frustration than a benefit. Beyond that, tools can be a rather personal thing. They all have limitations, but which limitations you hit most often can depend on your application and your personal working style.

[legacy]

Try running some C code that uses the full power of the language - lots of structure manipulation, and so on - and 8051 code from the best compilers looks pretty bad. So, speed depends a lot on the kind of code you are running

It's the same on 68hc11

[funkathustra]

A real 12-cycle 8051 core is always pretty slow. With a modern single cycle 8051 core code that's heavy in bit banging can be really fast and dense. However, the code looks slower and more bloated as the complexity of the code increases. Try running some C code that uses the full power of the language - lots of structure manipulation, and so on - and 8051 code from the best compilers looks pretty bad. So, speed depends a lot on the kind of code you are running.

The PIC is largely in the same category as the 8051, with regard to what it does well and does poorly. The AVR runs most complex C code pretty well.

I was obviously referring to the modern, 1T 8051 cores on my list, like the three-stage pipelined EFM8 ones Silicon Labs makes. The Nuvoton N76 in my lineup is also a 1T 8051, but its instruction timing is quite a bit slower on critical instructions than the EFM8 stuff.

Do you have suggestions/recommendations for what, specifically, to run to illustrate this "complex C code"? As far as I understand, struct manipulation is the same thing to a compiler as array manipulation with immediate (const) offsets. Neither the 8051 or AVR has load/store instructions that take an immediate-offset parameter (IIRC? Correct me if I'm wrong!), which means they will perform similarly in this regard (8051 will be a cycle faster than AVR if the data is in RAM, and a cycle slower than the AVR if the data is in XRAM).

If you think M0 code is less dense, that might reflect the kind of code you have been looking at. Try some serious maths, and the M0 code should look far denser than any PIC or 8051 code. Pretty much anything using the real power of the 32 ALU should result in denser code.

Sure, obviously, but we're talking about microcontrollers, not GPUs. I'd say that most MCUs I program don't sit around in for() loops running filters all the time.

One 16 bit core which does hit a sweet spot is the MSP430. It does pretty well on bit banging. It does pretty well on compute. C compiles very well for it. I have seen people get pretty good results with some RL78 devices running full featured C code, but I don't have personal experience.

Totally agree; I had my first experience with the RL78 a few weeks ago, and I really, really enjoy working on it. And unlike the MSP430, it's priced to compete with 8-bit MCUs.

[wraper]

On the bang-for-your-buck metric, you ain't gonna beat an EFM8UB1. For typical USB full-speed devices, it's nearly perfect.

Maybe from the buck point, otherwise no, nope.  But it is interesting MCU.
What I do not understand is the price point the 32F042 is usually sold at 1-off quantities at the usual distributors. As I do know for what price it is usually sold at quantities (not that large), it is kind of mind boggling. (but not only with this one)

Of course if you want to process a lot of data it might be not a best option. But it's perfect to build cost efficient HID devices. Like game controllers, joysticks and similar stuff. For example I can have a lot of analog channels sampled pretty fast. And the sweet part is due to built in VREG and versatility of ADC and analog comparators, I can keep the minimal number of additional components required compared to other much more expensive MCUs.

[coppice]

I was obviously referring to the modern, 1T 8051 cores on my list, like the three-stage pipelined EFM8 ones Silicon Labs makes. The Nuvoton N76 in my lineup is also a 1T 8051, but its instruction timing is quite a bit slower on critical instructions than the EFM8 stuff.

Not all 1T 8051 cores are created equal, but the big deal is usually the memory controller. You can be sure the flash isn't keeping up with a 72MHz core. There is no cache to mask that slowness, so the cleverness of the flash controller can be a big deal in extracting good performance.

Do you have suggestions/recommendations for what, specifically, to run to illustrate this "complex C code"? As far as I understand, struct manipulation is the same thing to a compiler as array manipulation with immediate (const) offsets. Neither the 8051 or AVR has load/store instructions that take an immediate-offset parameter (IIRC? Correct me if I'm wrong!), which means they will perform similarly in this regard (8051 will be a cycle faster than AVR if the data is in RAM, and a cycle slower than the AVR if the data is in XRAM).

You could try compiling something like an open source protocol package. They typically make the 8051 look a bit sick.

Sure, obviously, but we're talking about microcontrollers, not GPUs. I'd say that most MCUs I program don't sit around in for() loops running filters all the time.

A large number of high volume MCU applications involve quite a bit of maths on 16, 32 or 64 bit numbers, although they seldom involve calculating it at high speed. A large number of apps actually drag in several k of floating point software library code, typically to expand the dynamic range of a few divisions. Most MCUs are actually run at way below their rated MHz. It one of the surprises you find when you get visibility of a large number of customer applications.

Totally agree; I had my first experience with the RL78 a few weeks ago, and I really, really enjoy working on it. And unlike the MSP430, it's priced to compete with 8-bit MCUs.

The MSP430 competes head on with the RL78 on price, if you buy enough of them. They don't price them very well for small volume applications.

[wraper]

Not all 1T 8051 cores are created equal, but the big deal is usually the memory controller. You can be sure the flash isn't keeping up with a 72MHz core. There is no cache to mask that slowness, so the cleverness of the flash controller can be a big deal in extracting good performance.

EFM8 can run directly from flash with up to 25MHz core clock. Anything higher must have prefetch enabled.

[funkathustra]

I feel like I came across a lower-cost MCU with 50 MHz flash access recently, but I can't seem to remember which one. Does anyone have any leads?

I was thinking it was the Cypress PSoC 4000S, but it looks like it has pretty typical flash memory that requires two wait-states at 48 MHz.

[Bruce Abbott]

The only rule is that the part has to be $1 or less @ 100 units from reputable sources

    Look at STM32F042. 

Well, I looked on it briefly  ... No internal 5V -> 3.3V regulator, ADC capable inputs are not 5V tolerant. To use it with USB, instead of just a few decoupling caps I would need to use external VREG. ADC is much less versatile, no analog gain adjustment (0.5/1). Only single 1.25V reference voltage (1.65V and 2.4V for UB1). No analog comparator, UB1 has 2 of them, no internal DAC (used with comparators, both inverting and non-inverting inputs).

Changing the rules?

That particular chip might be out of your (arbitrary) price range, but now you are adding even more limitations. The industry is moving away from 5V, and many 3.3V MCUs are not 5V tolerant on analog inputs - for obvious reasons. Peripherals you don't need are just a waste of silicon and raise the price for no good reason.

The review will include quantitative comparisons between feature sets, benchmarking (via a 16-bit biquad filter test measuring kSPS and nJ/sample), power analysis, plus more qualitative stuff (development environment, SDKs, compiler choices, development/debugging experience, etc)...

This is silly. A fair comparison would take months if not years, by which time your 'review' will be way out of date.

It sounds like you have some specific applications in mind. If so then you should make a short list of chips that have the features you need, choose one, and see if it will do the job. Then (if you want to) tell us about it. Bonus points for choosing an obscure MCU that most people wouldn't consider.

But if you are just trying to organize a 'shootout' to see which MCU is 'best' then don't bother - unless you have a lot of time to waste. 

[wraper]

The only rule is that the part has to be $1 or less @ 100 units from reputable sources

    Look at STM32F042. 

Well, I looked on it briefly  ... No internal 5V -> 3.3V regulator, ADC capable inputs are not 5V tolerant. To use it with USB, instead of just a few decoupling caps I would need to use external VREG. ADC is much less versatile, no analog gain adjustment (0.5/1). Only single 1.25V reference voltage (1.65V and 2.4V for UB1). No analog comparator, UB1 has 2 of them, no internal DAC (used with comparators, both inverting and non-inverting inputs).

Changing the rules?

That particular chip might be out of your (arbitrary) price range, but now you are adding even more limitations.

Which rules? I briefly mentioned what is good in this MCU. You made a post to look for STM32F042. Then I compared them and noticed that STM32F042 is very limited in analog part. Even without analog part, and limited 5V tolerance, lack of 5V-3.3V vreg and much higher price is a showstopper.

The industry is moving away from 5V, and many 3.3V MCUs are not 5V tolerant on analog inputs - for obvious reasons.

USB provides 5V, just for this reason I want it to be 5V tolerant.

Peripherals you don't need are just a waste of silicon and raise the price for no good reason.

Rise of price? Did not notice that for UB1. What is a waste, is need to use numbers of external components which could be avoided. I can connect UB1 to usb directly, connect analog inputs to just anything without circuity to adjust voltage levels and call it a day. Not the case of F042.

[funkathustra]

Changing the rules?

That particular chip might be out of your (arbitrary) price range, but now you are adding even more limitations. The industry is moving away from 5V, and many 3.3V MCUs are not 5V tolerant on analog inputs - for obvious reasons. Peripherals you don't need are just a waste of silicon and raise the price for no good reason.

I am not @wraper. I don't care about 5V tolerant inputs. I'm testing everything at 3.3V. Most of these parts are 5V-tolerant digitally, but obviously use clamp diodes which prevents analog signals from getting too hot. Not really testing this, though it's a good idea to mention it — I'll make sure to.

The price range is arbitrary, but not unwarranted. If you start going above $1, you start heading off into application-specific land: this part has an LCD controller, that part has better DMA, this part has CAN, that part has QSPI, blah blah blah... I don't want to open that can of worms because:

A fair comparison would take months if not years, by which time your 'review' will be way out of date.

Unless you limit it to general-purpose MCUs with similar-ish peripherals, and limited test code. Hence, more reasons for $1 price limit.

It sounds like you have some specific applications in mind. If so then you should make a short list of chips that have the features you need, choose one, and see if it will do the job.

This is what I've done every time I've started a new project, but I'm tired of not having data that I can use to make these decisions. Also, I don't have a "specific application" in mind — other than "general purpose, entry-level." Look, I've built surgical robotics motor controllers, data logging platforms, localization systems, embedded Linux systems, deep-low-power underground sensors, and basically everything in between. Please get off your high horse and agree with me that there is a *large* class of embedded designs that my list of $1 general-purpose entry-level MCUs is great for. If you can't agree with that, then I don't know why you're even posting on this thread.

But if you are just trying to organize a 'shootout' to see which MCU is 'best' then don't bother - unless you have a lot of time to waste.

Go away. You're being mean and unhelpful.

[westfw]

and a comparison at the $15 level is a lot more dramatic in some ways.

... once you compare the base members, you're good.

I think I strongly disagree.   One of the important factors, even when considered a $1 chip, is the potential for transitioning to a more powerful chip without having to start over.  This leads to some depressing facts where you're NOT good if you understand the low end.
Consider RAM.  None of the 8-bit PIC architecture chips can address more than 4k of RAM.   Few 8bit microcontrollers have as much as 16k of on-chip RAM, and even if they're "capable", you start running into restrictions - For example, "such-and-such banking scheme isn't support transparently by anything except xyz compiler", or isn't supported at all...  (This applies to program memory as well.  I like both the AVR and MSP430s, but neither is something I'd use if I thought I might someday need more than 64k...)
Also, between chip complexity and vendor libraries, a lot of the 32bit chips being offered as 8bit replacements (ie the ones that fall in your price range) are a bit disappointing as well.  I don't think I believe that a 16k SAMD10 is going to be an adequate replacement for a 16k AVR, for example.  The usual answer for ARM chips is "just use a chip with more memory; they're still cheap."  That's moderately true, but ... there are no samd10-pinout chips with more than 16k.

[NorthGuy]

None of the 8-bit PIC architecture chips can address more than 4k of RAM.

This is a lot of RAM. You can do a lot with it. There are many projects where you need much less RAM. Of course, it is not enough for graphic LCD controller, but you wouldn't think of building LCD controllers with 8-bit MCUs.

[funkathustra]

One of the important factors, even when considered a $1 chip, is the potential for transitioning to a more powerful chip without having to start over. 

What you're saying is true, and I'm definitely going to mention how much headroom these parts have — but honestly, once you have the base members down, it's just parametrics after that. A 128 KB AVR is going to perform the same way in my testing as an 8 KB AVR. Are you worried about falling in love with a $1 microcontroller that doesn't have much headroom? Total possibility, since some of these families are really niche to this price range.

But my whole thing with this series is that it's 2017 — code-gen tools are better and easier-to-use than ever, and peripheral libraries are really great, too. Most of the IDEs aren't proprietary anymore, compilers are free, and debuggers and dev boards are <$50. It's obviously not trivial to swap MCUs in the middle of a complex product, but I hope this project encourages people to think of MCUs as commodity items that can be freely selected, without having to pay a huge penalty for working with a new chip.

This project isn't about finding the ONE microcontroller to rule them all — I'm not even going to declare a "winner" in this series — instead, it's about getting people comfortable with everything that's out there. And honestly, everything I've done so far is proving that point. I've been banging through a different MCU each night I've been working on it, and only one chip has given me trouble (and, ironically, it's one of my favorite go-to that I've been using for the last two years now for projects in this price range). Everything else has been super straightforward to get up and running. I've been pleasantly surprised by chips I've written off, and getting annoyed by chips I'm super familiar with ("Why isn't that as easy as it was on that new chip I was working with last night...?"). It's been a huge learning experience for myself, and I hope a lot of other people gain a lot of intuition from it.

Keep the comments coming!

[janekm]

For <1$ you've absolutely got to add the Nordic Semi NRF51 to the list... A great little Cortex-M0 which comes with Bluetooth LE (and generic 2.4GHz) radio, the stack for that, pretty great SDK, and great open source (toolchain and library / RTOS) support these days. It's pushing the $1 limit but if you know the right distributor in China it can definitely be done for 100 units
And of course there's the NRF52 range for "headroom".

Below that what's fascinating is the STM8S003F3P6 which is the cheapest microcontroller I've been able to find and pretty nice for that (already discussed in this thread). It's <0.2$ which opens up a whole other range of opportunities.

[funkathustra]

For <1$ you've absolutely got to add the Nordic Semi NRF51 to the list

Great chip, but totally, definitely, not even close to being <=$1.

Below that what's fascinating is the STM8S003F3P6 which is the cheapest microcontroller I've been able to find and pretty nice for that (already discussed in this thread). It's <0.2$ which opens up a whole other range of opportunities.

I'm actually working through the STM8 review as we speak! Great architecture — much more clock-cycle-efficient than any other 8-bitter that I've tested thus far (unless you count the RL78 an 8-bit MCU, even with its 16-bit ALU).

[janekm]

For <1$ you've absolutely got to add the Nordic Semi NRF51 to the list

Great chip, but totally, definitely, not even close to being <=$1.

(snip)

The last quote I got from my distributor was 7.8RMB in December of last year (all my recent projects have been using NRF52...), as far as I know the price has come down a bit since then so I do believe <1$ is possible. I saw a quote of 6.5RMB recently so that would put it over the threshold. Not delivered to outside China, of course, but for Kickstarter pricing etc...
You could always give it an "honorable mention" if you think that's too fuzzy, I guess

But while I'm on the topic, we can't forget the ESP8266 either! A little bit of an odd one since you also have to add the EEPROM to the cost but I think it can just squeeze in at <1$: https://item.taobao.com/item.htm?spm=a230r.1.14.18.ebb2eb22ZgRGe&id=532682188102&ns=1&abbucket=2#detail
+ https://item.taobao.com/item.htm?spm=a230r.1.14.34.ebb2eb2LqPrU2&id=37750426961&ns=1&abbucket=2#detail