$1 MCU review — looking for part suggestions!

[wraper]

Considering there are a lot of counterfeit nRF24L01 in the wild, I would be concerned about nRF51 too.

[ali_asadzadeh]

Add STM32F103RBT6 to the list too an M3 with huge benefits!

https://world.taobao.com/item/42883572952.htm?spm=a312a.7700714.0.0.6419a3bcVpjLuq#detail

[funkathustra]

I love Taobao as much as the next guy, but for this series, I'm focusing on general-purpose MCUs from reputable, North American-based distributors, or directly from the company. And I'm trying to find the "best" (obviously subjective!) representative from each family, which typically means the representative from the family that is as close to $1 (without going over).

The main reason I'm doing it this way instead of including Taobao/AliExpress/eBay/weird Newark closeout specials is to make sure I'm judging "value" instead of just functionality. If all the parts I'm reviewing cost about the same, it's easy to look across the numbers and the reviews and identify good and bad values. Since a lot of these parts I'm reviewing (like the Nuvoton N76) struggle to hit $1 as it is, if I'm using Taobao pricing, at that point, I'd be comparing a $1 STM32F103 with 15- or 20-cent 8-bit MCUs, which doesn't seem useful for readers.

The actual, absolute price isn't particular important, as long as it's consistent across all the families. I could have easily said $2 @ QTY=1, or $0.80 @ 1000 units. It's just that $1 @ 100 units seemed like a nice sweet-spot for general-purpose MCUs.

And I think there's still a lot of value when operating with this constraint. For example, I hope that if you read my review of the STM32F0 and end up really liking the peripheral libraries, development ecosystem, and functionality of the part, you'll notice that you can get F103s on Taobao for cheap, and feel confident in the performance, functionality, and ease-of-development you'll get out of the part. That's how the series remains relevant to bigger/fancier chips, as well as making purchases from much cheaper markets.

[tszaboo]

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.

https://world.taobao.com/item/541789410610.htm

Taobao no good for laowai. Buy digiii key.

[janekm]

I love Taobao as much as the next guy, but for this series, I'm focusing on general-purpose MCUs from reputable, North American-based distributors, or directly from the company. And I'm trying to find the "best" (obviously subjective!) representative from each family, which typically means the representative from the family that is as close to $1 (without going over).

The main reason I'm doing it this way instead of including Taobao/AliExpress/eBay/weird Newark closeout specials is to make sure I'm judging "value" instead of just functionality. If all the parts I'm reviewing cost about the same, it's easy to look across the numbers and the reviews and identify good and bad values. Since a lot of these parts I'm reviewing (like the Nuvoton N76) struggle to hit $1 as it is, if I'm using Taobao pricing, at that point, I'd be comparing a $1 STM32F103 with 15- or 20-cent 8-bit MCUs, which doesn't seem useful for readers.
(snip)

I think there is still value in mentioning which parts are popular in the Chinese supply chain (and I don't really mean taobao here, it's just useful as a barometer for market prices), since someone looking to choose a <$1 mcu is likely going to have to manufacture there anyway. Though, arguably, if they don't know the market well enough to know what the popular parts are already they probably need to do a bit more research first anyway before trying to build a low-cost product

[donotdespisethesnake]

Add STM32F103RBT6 to the list too an M3 with huge benefits!

https://world.taobao.com/item/42883572952.htm?spm=a312a.7700714.0.0.6419a3bcVpjLuq#detail

Are GD32F103 CPUs on Taobao? I guess they are.. and probably a lot cheaper than STM32, maybe even < $1.

[donotdespisethesnake]

Add STM32F103RBT6 to the list too an M3 with huge benefits!

https://world.taobao.com/item/42883572952.htm?spm=a312a.7700714.0.0.6419a3bcVpjLuq#detail

Are GD32F103 CPUs on Taobao? I guess they are.. and probably a lot cheaper than STM32, maybe even < $1.

62 cents.

Nice At that price, I don't why I would bother with Cortex M0, 8 or 16 bitters, unless I had special requirements. I'm not quite ready to dive in to Taobao, maybe I should! I haven't been able to find GD32 outside of a few special distributors, nor even ebay or Aliexpress.

[brucehoult]

• 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?

Worse than what? Other Thumb2 chips? AVR?

Over the years, with programming many different architectures, I've come to the conclusion that 16 bit *instructions* are very much in a sweet spot, either fixed size, or with a way to escape to the occasional 32 bit instruction. That's regardless of whether the registers and data are 8 bit (AVR), 16 bit (PDP11 [1]), 32 bit (Thumb/Thumb2, RISC-V32C), or 64 bit (RISC-V64C).

32 bit instructions just have too much generality and wasted space. Sometimes you can use all the power (and aarch64 does a pretty good job), but sometimes you only want to negate a register and 32 bits is a waste for that.

Instructions based on 8 bit units seem like they should be better, especially as they can be better Huffman coded than instructions with larger granularity, but it just doesn't work out that way in practice, at least for x86, VAX, z80, 6502 etc. Thumb fits a 3-address add or subtract (destination register, and two source registers) into a two byte instruction. Both VAX and x86 need four bytes to do that. If the destination is the same as one operand then x86 can also do it in two bytes, but VAX needs three. 6502 needs 6 bytes (assuming 8 bit data and sources and destination in Zero Page). 8080/z80 need three bytes, assuming both operands and the destination are registers other than A (mov a,src1; add src2; mv dst,a).

[1] the actual instructions are all 16 bit, but some addressing modes have a side effect of loading an immediate or offset and advancing the PC

[Bruce Abbott]

Thumb fits a 3-address add or subtract (destination register, and two source registers) into a two byte instruction. Both VAX and x86 need four bytes to do that. If the destination is the same as one operand then x86 can also do it in two bytes, but VAX needs three. 6502 needs 6 bytes (assuming 8 bit data and sources and destination in Zero Page). 8080/z80 need three bytes

This has less to do with instruction size than it does about which instructions are prioritized. The 8080 and Z80 waste most of their base opcodes doing 8 bit register to register transfers, then on the Z80 they had to add prefixes to expand the opcode range. 

The Z80 is is quite frustrating because many of the enhanced instructions have a cost far exceeding expectations. For example, here are 4 different ways to store the contents of the BC register in memory address $1234:-

Code: [Select]

1. copy B to A and C to A, store direct
79      ld  a,c
32 34 12 ld  (addr),a
78      ld  a,b
32 35 12 ld  (addr+1),a

2. store BC direct
ED 43 34 12 ld  (addr),bc

3. using HL as a pointer
21 34 12 ld   hl,addr
71      ld  (hl),c
23      inc  hl
70      ld  (hl),b

4. using IX as a pointer with offset (IX preloaded with base address)
DD 71 00  ld   (ix+0),c
DD 70 01  ld   (ix+1),b

2. is the shortest and most efficient, but could be even shorter if it didn't need the 'ED' prefix.

4. is the most versatile and convenient, but again wastes bytes on prefixes. And since indexed instructions work on 8 bit quantities only (no "ld (ix+0), bc") the code is 3 times the size it could be.
 

[westfw]

I've come to the conclusion that 16 bit *instructions* are very much in a sweet spot, either fixed size, or with a way to escape to the occasional 32 bit instruction.

Somewhat agree...

32 bit instructions just have too much generality and wasted space.

Whether "wasted space" is a problem is a technology issue.  My favorite instruction set of all time used a 36bit instruction word.  A memory/register architecture, each instruction had 9bits of opcode, 4 bits of register address, 4 bits of index register, and 18bits of "offset" (or constant.)  It had MANY no-op instructions, 64 system call instructions (half for user-implemented instructions...

Thumb fits a 3-address add or subtract (destination register, and two source registers) into a two byte instruction.

Well, mostly it doesn't.  Thumb has about 2 instructions (add and sub) that fit all three operands into 16bits.  And even then, it's done by reducing the number of registers that can be access to only 8.  (if 16bits is a sweet spot for instruction size, I think 16 is the sweet spot for usable registers (perhaps including PC, SP, and PSW.)   The whole "compress a 32bit instruction into 16bits" thing is clever, but I wish it had been a less "lossy" compression.   The CM0 (with only 16bit thumb instructions) is pretty ugly - if users hadn't been lulled into a sense of comfort by the full 32bit arm instructions and the less lossy Thumb-2 instructions, they wouldn't have been impressed :-(   (It's hidden by compilers and obscured by documentation, but if you try to program a CM0 in assembly language, or start actually look at the code your compiler produces, you quickly run into "this instruction form isn't supported" or "this offset/immediate value has a very limited range" and such.  grr.)

The Z80 is is quite frustrating because many of the enhanced instructions have a cost far exceeding expectations.

(ah - quite similar to the Thumb problem...)
Yeah; that was one of the two big nails in the coffin for classic CISC architectures.  (the other one was that compiler writers couldn't figure out how to make generic compilers USE all the fancy instructions.   The previously-mentioned 36bit CPU added enhanced string and bcd instructions at one point, but they required that you set up 4 to 6 register beforehand, and didn't really execute any faster than a tight loop of simpler instructions...

[brucehoult]

Thumb fits a 3-address add or subtract (destination register, and two source registers) into a two byte instruction. Both VAX and x86 need four bytes to do that. If the destination is the same as one operand then x86 can also do it in two bytes, but VAX needs three. 6502 needs 6 bytes (assuming 8 bit data and sources and destination in Zero Page). 8080/z80 need three bytes

This has less to do with instruction size than it does about which instructions are prioritized. The 8080 and Z80 waste most of their base opcodes doing 8 bit register to register transfers, then on the Z80 they had to add prefixes to expand the opcode range. 

Yes.

Instructions that are  byte-encoded *would* allow you to Huffman code the instructions (i.e. giving the most frequently used instructions the shortest opcodes, and give seldom-used things longer opcodes). But in fact they all failed to do that. Instead, they gave the instructions that need the fewest arguments or have the fewest options the shortest encodings -- because they don't seem to "need" more -- regardless of how infrequently they are used.

The absolutely classic example is the 8086's AAA instruction: Ascii Adjust AL After Addition, opcode 0x37. This is an instruction so frequently used that gcc doesn't even know how to emit it (without inline assembly language, at least). And yet it and its friends AAS (0x3F), DAA (0x27), DAS (0x2F) together take up 1/64 or 1.56% of the single byte instructions.

I guarantee they don't make up 1.56% of instructions in most programs.

Similarly, does HLT (0xF4) really need a 1 byte opcode? Or the instructions to set or clear carry/interrupt/direction (0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD). Or Complement Carry Flag (0xF5)?

That's 12 instructions now ... 4.7% of the opcode space. Every one of which could have happily had a two or three byte opcode without causing any real program a size problem.

There are plenty of examples left!

[brucehoult]

I've come to the conclusion that 16 bit *instructions* are very much in a sweet spot, either fixed size, or with a way to escape to the occasional 32 bit instruction.

Somewhat agree...

32 bit instructions just have too much generality and wasted space.

Whether "wasted space" is a problem is a technology issue.  My favorite instruction set of all time used a 36bit instruction word.  A memory/register architecture, each instruction had 9bits of opcode, 4 bits of register address, 4 bits of index register, and 18bits of "offset" (or constant.)  It had MANY no-op instructions, 64 system call instructions (half for user-implemented instructions...

Thumb fits a 3-address add or subtract (destination register, and two source registers) into a two byte instruction.

Well, mostly it doesn't.  Thumb has about 2 instructions (add and sub) that fit all three operands into 16bits.  And even then, it's done by reducing the number of registers that can be access to only 8.  (if 16bits is a sweet spot for instruction size, I think 16 is the sweet spot for usable registers (perhaps including PC, SP, and PSW.)

16 or 32 registers total is good, but it's usually not too hard for a compiler to get all the important variables in a loop of even many functions into 8 registers.

Add and subtract are by far the most arithmetic operations in programs, especially when including add and subtract of small constant values, which Thumb also gets all three operands (a = b +/- const) into 16 bits, provided const is less than 8. Other arithmetic such as boolean operations AND, OR, EOR shifts LSL, LSR, ASR, ROR and add and subtract with carry can only do a = a op b which means you will sometimes need to do a MOV a = c first, but they are not so common.

These restrictions are a bit annoying if you are programming in assembly language, where you like a very orthogonal instruction set, but compilers can easily deal with them.

The whole "compress a 32bit instruction into 16bits" thing is clever, but I wish it had been a less "lossy" compression.   The CM0 (with only 16bit thumb instructions) is pretty ugly

Ugh .. yes. Original Thumb was never intended to be the only instruction set available. There are so many system management things that aren't included at all, and even things such as 32x32->64 multiply.

Thumb2 is much nicer in that way, but because it was hacked in later it has an absolutely awful instruction encoding. I can understand 6502 programs quite well directly from a hex dump. Don't try to do that with Thumb2!

[janekm]

Add STM32F103RBT6 to the list too an M3 with huge benefits!

https://world.taobao.com/item/42883572952.htm?spm=a312a.7700714.0.0.6419a3bcVpjLuq#detail

Are GD32F103 CPUs on Taobao? I guess they are.. and probably a lot cheaper than STM32, maybe even < $1.

62 cents.

Though funny enough you can find STM32F103 for less... I think ST are effectively price dumping to keep that competition in check.

[funkathustra]

In case anyone was wondering if I ever got around to finishing this write-up, the answer is "Yes! Finally!"
 
Check out The Amazing $1 Microcontroller on my blog.
 
It took several months of on- and off-again work, but I got through all 21 parts I selected.
 
I'd like to thank everyone on this thread for their help --- I got some excellent part recommendations --- but even better, I got feedback on some areas to focus on, too.
 
If there are things you think need to be mentioned that I'm forgetting, please drop a line on this thread (or, shamelessly plugging my blog, as a comment on this post  )
 
Thanks again for the wonderful discussions!

[mikeselectricstuff]

In case anyone was wondering if I ever got around to finishing this write-up, the answer is "Yes! Finally!"
 
Check out The Amazing $1 Microcontroller on my blog.
 
It took several months of on- and off-again work, but I got through all 21 parts I selected.
 
I'd like to thank everyone on this thread for their help --- I got some excellent part recommendations --- but even better, I got feedback on some areas to focus on, too.
 
If there are things you think need to be mentioned that I'm forgetting, please drop a line on this thread (or, shamelessly plugging my blog, as a comment on this post  )
 
Thanks again for the wonderful discussions!

Holy crap that must have been a huge amount of work!
One thing I noticed - in the ISR latency figures, the PIC32MM came in quite high - was this using the shadow register bank ? (They annoyingly left this off the 32MX1xx devices, but makes a big difference where you have a high interrupt rate). 
This is not especially well documented, and ISTR there's a non-obvious register setting (PRISS) that needs setting as well as the IPLxSRS attribute in the ISR declaration.

One other point under "Usual Microchip advantages", though not a property of the chip per se, can be very relevant when looking at overall cost and conveneience  - low-cost preprogramming service via MicrochipDirect - I think some of the Atmel parts are also available on the service now.  For the smaller chips it's just a few cents to program, mark and re-reel.

[funkathustra]

One thing I noticed - in the ISR latency figures, the PIC32MM came in quite high - was this using the shadow register bank ? (They annoyingly left this off the 32MX1xx devices, but makes a big difference where you have a high interrupt rate). 
This is not especially well documented, and ISTR there's a non-obvious register setting (PRISS) that needs setting as well as the IPLxSRS attribute in the ISR declaration.

Wow — I had no idea this was a thing. I'll look into this at some point in the future and get back to you — otherwise, feel free to submit a pull-request (all the code is over on GitHub) if this is an easy change.

One other point under "Usual Microchip advantages", though not a property of the chip per se, can be very relevant when looking at overall cost and conveneience  - low-cost preprogramming service via MicrochipDirect - I think some of the Atmel parts are also available on the service now.  For the smaller chips it's just a few cents to program, mark and re-reel.

This is a good point! Though, from my experience, basically everyone does this these days — at least the vendors I've used on recent volume products.

I think Microchip was one of the first, though — I'm almost positive I mention that somewhere buried deep in the PIC16 review, I think.

Thanks for the feedback!

[coppice]

Check out The Amazing $1 Microcontroller on my blog.

A lot of good work has gone into producing that page. A key issue I see is how you determined relative pricing. 100 is such a low number that it really skews your impression of relative pricing. At the 100 level prices are almost random. You might have seen a saner set of relative prices if you had used, say, widely published 10k prices. Those are still not always representative of what a little negotiation or a higher volume might get you, but at least it gets you away from the silly prices you get at the 100 level.

If a part looks rather expensive compared to its competition you are either missing is special qualities, or seeing the wrong price. Seriously overly expensive parts seldom reach the market.

[mikeselectricstuff]

One thing I noticed - in the ISR latency figures, the PIC32MM came in quite high - was this using the shadow register bank ? (They annoyingly left this off the 32MX1xx devices, but makes a big difference where you have a high interrupt rate). 
This is not especially well documented, and ISTR there's a non-obvious register setting (PRISS) that needs setting as well as the IPLxSRS attribute in the ISR declaration.

Wow — I had no idea this was a thing. I'll look into this at some point in the future and get back to you — otherwise, feel free to submit a pull-request (all the code is over on GitHub) if this is an easy change.

This is declared in the ISR handler as :

void __ISR(_UART2_RX_VECTOR,IPL7SRS)  uartint(void)

And you also need to tell it which int priority uses the SRS :
PRISS=0x10000000; //ipl7 use SRS1

I don't know if Microchip's code-gen stuff supports this as I have a pathological hatred of all manufacturer-supplied libraries, code generators etc. due to having spent way too much time tracking down bugs in them, or spending more time figuring out how to use them than it would have taken to just RTFDS and do it manually!

[mikeselectricstuff]

One other point under "Usual Microchip advantages", though not a property of the chip per se, can be very relevant when looking at overall cost and conveneience  - low-cost preprogramming service via MicrochipDirect - I think some of the Atmel parts are also available on the service now.  For the smaller chips it's just a few cents to program, mark and re-reel.

This is a good point! Though, from my experience, basically everyone does this these days — at least the vendors I've used on recent volume products.
I think Microchip was one of the first, though — I'm almost positive I mention that somewhere buried deep in the PIC16 review, I think.

Microchip are unusual in that they are one of the few ( only?) MCU makers who supply direct in smaller quantities, so programming is a simple add-on to that.
 Some distributors offer programming, but there can be issues like prohibitive cost ( especially for smaller parts where it can cost more than the part), limited part/package coverage, and stupid export control issues ( Digikey won't ship programmed parts outside the US as they don't know if the code implements export-controlled encryption etc.) 
I don't know of any other supplier where you can set up programming jobs and order parts online with a fairly low MOQ ( ISTR it's either 150 parts or $150  value), and get them in a few days.   

[coppice]

Microchip are unusual in that they are one of the few ( only?) MCU makers who supply direct in smaller quantities, so programming is a simple add-on to that.

If you want pre-programmed devices done well, you want them programmed during assembly and test. If they are programmed later, SO, QFP and other packages with flimsy legs show a substantially increased rate of defects due to bent legs. It appears Microchip have set themselves up to do this for modest volumes. Most people only do it for serious volumes. I think pretty much any supplier of flash MCU will program them at the factory when you buy millions.

Some distributors offer programming, but there can be issues like prohibitive cost ( especially for smaller parts where it can cost more than the part), limited part/package coverage, and stupid export control issues ( Digikey won't ship programmed parts outside the US as they don't know if the code implements export-controlled encryption etc.) 

Don't forget that increased defect rate. It hits some people quite hard. If you can't get things programmed at the factory its best to program them after board assembly, to minimise the handling steps.

[NorthGuy]

Interesting review.

IMHO, instead of comparing CPU frequencies, then comparing toggle rates in cycles, it would be more useful to compare toggle rates in real-time terms (in us).

[EEVblog]

EPIC amount of work!   

https://jaycarlson.net/microcontrollers/

[jaromir]

Now that's massive amount of work put into this preview. Looks like it's popular, your server is unavailable at times in last few hours.

[mikeselectricstuff]

UARTs with FIFOs in this test had significantly higher interrupt latencies than UARTs without FIFOs.

..er isn't that kinda the point of a FIFO'd UART?
 or do you mean they have worse latency when the FIFO is disabled/set to minimum?

[funkathustra]

or do you mean they have worse latency when the FIFO is disabled/set to minimum?

I meant that first-byte ISRs with the FIFO enabled seem to have slightly worse latency (a few cycles) than ISRs from regular, FIFOless UARTs.

ISR latency is caused by prologue code (especially heavy on stack-based parts like AVR and Arm), core design, but also peripherals. From my testing, it looks like a lot of parts with FIFOs had additional ISR latency when compared to parts without FIFOs (of course, I'm assuming the ISR is set to trigger on the first byte received). I mostly used the FIFO functionality to slow down the core — sitting in a while() loop, processing FIFO bytes is a lot faster than exiting and re-entering the ISR.

Keep in mind that I didn't do what you usually do with FIFOs — set up an ISR to trigger after they're already full. This was mainly because many FIFOs had strange policies when it came to bytes received with framing errors (which is what I use to detect the start of frame for DMX-512).

I suspect the FIFO-enabled UARTs have a bit more register transfer stuff they have to do, which ends up adding in a few extra cycles before they can assert the interrupt signal — but that's just a guess.

I'm comparing among the Arm parts, which all have the same core and should have relatively similar prologue code before hitting the register (this second assumption might not be entirely true, though, now that I think about it).

There's better ways to isolate and test for this (with "naked" declarations for the ISRs), and admittedly I didn't have time to do this.