
How to pick a microcontroller - adastra
http://www.sureshjoshi.com/embedded/how-to-pick-a-microcontroller/
======
pjc50
Related on EE.stackexchange:
[https://electronics.stackexchange.com/questions/264794/how-d...](https://electronics.stackexchange.com/questions/264794/how-
do-i-come-up-with-a-list-of-requirements-for-a-microcontroller-for-my-
projec/264813#264813)

I agree with OP's "grief factor" \- difficult to estimate but really critical
to your project timeline.

I'm also going to advocate my "pick _something_ " suggestion; the first one of
anything you buy in an unfamiliar product area will always be wrong. This
applies to computers, cars, cameras, houses, everything; when you're entering
the market you won't understand your own requirements and anti-requirements.
So buy something cheap and standard then use it to understand how it's
inadequate for you specifically. You'll also appreciate the expensive options.

If you've never bought a microcontroller, buy an Arduino. It may not be right
but you'll have a lot of company.

~~~
fragmede
If we're recommending pet favorites, the Raspberry Pi Zero Wireless, despite
being the newest, is now my recommended "microcontroller". There are a few
tweaks needed on top of the base Rasbian distro to make it appropriate for use
as a microcontroller, but with a base price of $10, it's cheaper, more
powerful, and has accessories (ie - anything USB with open source Linux
drivers), than some Arduinos.

Built in wifi, Linux, plus USB and GPIO, means it's perfect for the device end
of an hobbiest-level IoT project.

~~~
dragontamer
I still consider that a 'computer' and not a microcontroller.

You will inevitably need adc functionality, possibly real time clock and
battery usage.

Most servos don't need wifi or Ethernet. Instead, you will usually want to be
able to read a voltage and then time how long it takes for that to change.

15 cent quartz crystal and built in adcs. Bitbanging pwm from raspberry pi is
also horribly inaccurate... You need a ton of shields to just run a motor with
an encoder on it... While arduino can do all that around 10mA

~~~
joezydeco
It's also not something you can build a production device out of...unless your
margins are so insanely large that you can afford it and nobody cares.

~~~
dragontamer
Ehhhh... depends really.

You can easily spend around $10 on a single filter (ex: 8-pole Filter... such
as [https://www.digikey.com/product-detail/en/linear-
technology/...](https://www.digikey.com/product-detail/en/linear-
technology/LTC1069-1CS8-PBF/LTC1069-1CS8-PBF-ND/961297)). If you need an
8-pole elliptical filter, you just go out and buy one, amirite?

The "production" competitor to the Raspberry Pi Zero is honestly something
like... the Octavo Systems OSD3358. At $50, you may wonder why this device is
superior... but it has integrated RAM, Open Documentation, the features that
are necessary for microcontroller work (ADC, DAC, PRU/Programmable Realtime
Units, RTC, on-board LDO Regulator, on-board Lithium-Ion cell balancer and
Lithium-Ion manager, support for TWO Crystal Oscillators, 114 GPIO, 6 UARTs).

[http://www.digikey.com/product-detail/en/octavo-systems-
llc/...](http://www.digikey.com/product-detail/en/octavo-systems-
llc/OSD3358-512M-BAS/1676-1000-ND/6012564)

Its all about your REQUIREMENTs. The Raspberry Pi Zero barely does anything
aside from computer things (Ex: WiFi, USB).

Don't get me wrong, the Raspberry Pi Zero is a wonderful computer. But
microcontrollers are things that can work with Thermocouples, control Active
Filters, and control motors. In contrast, the Raspberry Pi burns itself out if
you put an LED on its weak GPIO pins... and even "Realtime" Linux can't save
you from the micro-second delay associated with the GPIO pin hardware.

~~~
joezydeco
My point is that if I needed to build and sell 200,000 of something over 10
years, I can't order that many from the Raspberry Pi foundation and trust the
piece will still be around the entire time. And if I wanted 200,000 of the
Broadcom parts, they wouldn't sell it to me in that small of a quantity.

The OSD3358 is definitely the right approach, since putting high-speed
impedance/timing matched DDR lines on a board to make it work right with a
modern 1GHz+ CPU is a much higher level of difficulty. Plus you will also need
to make your PCB 8 or 10 layers to shield the interference which increases the
cost.

I thought package-on-package (like the AM335x's predecessor, the OMAP) was the
way to go, but I'm starting to like the monolithic package better.

------
zw123456
This was a pretty good overview. I get asked this same question a lot because
I have been working with microprocessors for decades and I have used many
different ones from the old 8051 to Microchip, Arm and even FPGA embedded. The
way I usually start is I ask this "will you need an OS like Linux ?" (there
are a bunch of follow on questions on that issue to decide that.

If the answer is yes then that steers you to a much bigger and more expensive
chip, usually and increases the complexity significantly. For beginners who
need an OS for their project, I steer them to the RPI simply because there is
just a ton of resources on the web to help them along. There are other really
good boards but I steer them to an off the shelf solution like that and the
RPI seems to be really well supported.

If you don't need Linux or RTOS or similar then that narrows it to a lower end
simpler solution. For beginners I almost always steer them to the Arduino even
though I rarely use it myself but for the same reason, tons of support on the
web and you can, over time move to C or C++ on it as you advance your skills.

I am not a big super fan of those platforms I personally have my own dev
system using my own boards and system that I have evolved over the years to be
able to get designs done very fast. But I just think those are good starting
points for a beginner.

------
jwr
One more thing to consider: if your time is limited and you have to
design/build lots of different devices, stick to more extensive product lines.
As an example the NXP Kinetis, while having its share of warts and issues, is
a huge product line with hundreds of chips, sharing a similar architecture.

This means that you can use a chip that fits requirements well, ranging from
tiny simple M0+ devices all the way to monster M4 chips with 1M flash and
every peripheral one can imagine. They not only share some peripherals, but
you use the same SDK, documentation formats are the same, etc.

This is a huge time saver and lets you use the right chip for each project,
instead of sticking the same expensive microcontroller everywhere, or using
ones from different manufacturers.

~~~
jpm_sd
I switched from STM32 to the Kinetis family two years ago and I've been super
happy with the change. The free IDE is actually pretty solid and support has
been adequate. Now that Freescale has been doubly gobbled up (first by NXP and
then NXP by Qualcomm) this may go downhill a bit, but the user forums are
decent.

Edit: I'm also using an M4 with dual bank flash almost everywhere. The
projects I'm doing these days aren't particularly BOM cost sensitive and the
headroom + foolproof firmware updating are fantastic (as the article says).

~~~
jwr
Interesting -- could you write about your impressions? How do peripherals
compare? I think you get 32-bit timers on the STM32? And I heard that most
other peripherals are newer/better than the 8-bit peripherals that
NXP/Freescale adapts to the Kinetis chips -- what do you think?

~~~
jpm_sd
I guess I just haven't needed those bells and whistles. 32 bit timers are
kinda huge. And some of the peripherals on the STM are suffering from "newer
ain't always better" \- the CAN and I2C controllers are more complicated than
they need to be, IMHO.

Edit: I can't make any useful comparison on analog peripherals since I use
external ADCs, DACs, etc. more or less 100% of the time

~~~
jwr
Thanks, this reply is much appreciated.

------
ChuckMcM
Generally solid advice (although its more like "how to pick a micro-controller
for your design you're trying to keep as cheap as possible.") and one of the
areas where I quibble is the use of "generator" tools to generate I/O code.
The STCube application is easy to use for beginners but easily uses twice as
much flash as actual user written code. That isn't a problem if your app is
small and the flash is large but puts you at a disadvantage if you are
competing with people who know how to write that code.

My philosophy has been to develop an understanding of the peripheral fairly
deeply, write a 'driver' for it and a bunch of documentation that will remind
me of the quirks when I come back to it, and then put that in a library. The
benefit is 'easy code' (just use the library) that is more efficient and
smaller than generated code, and a quick spin up document if I need to dive in
and do more complex work with the peripheral.

~~~
sureshjoshi
That is a great point about the downsides of generated code that I didn't
mention (but should have).

I don't think it uses twice as much flash per se, but it definitely does use
'more' than hand-rolling your own code.

But ST-Cube has also gotten MUCH better over the last few years and no longer
generates a lot of unnecessary, yet compiled, code. The version I first used
in 2012ish was pretty weak.

I try to approach this from the direction of what gets me up and running
fastest (and what has the lowest barrier to entry for my team - including
communication), and then I re-factor out the guts afterwards if needed.

Practically speaking, my workflow is that I have a set of heavily unit tested
and mocked out middleware and device drivers, that are portable to any ARM...
So, all I need are the low-level drivers which interact with the peripherals.

I can generate them with ST-Cube, hook them into my middleware/drivers through
interfaces (C++) or linking (C).

From here, I run my automated integration tests to make sure everything works
on my hardware - and once that's done, I evaluate my flash usage.

If needed, I gut the generated code in favour of something hand-rolled, while
being able to make sure everything is still 'correct'.

Also, contextually, I almost never use anything less than 32kB flash - so I
don't often need to hyper-optimize.

------
falcolas
Now that you've picked a microcontroller, here's some tips on the next steps:
"How to be: A smart hardware programmer"

[https://youtu.be/g8QDCMuy6oM](https://youtu.be/g8QDCMuy6oM)

I link to this only partially in jest - you really will need way more
components than the plan says you'll need. Even microcontrollers; misaligning
a header by one pin can result in things like putting the output of a 3C Li-
Poly over a signal header...

~~~
bigiain
This is why I like prototyping with Arduinos - you'll 99% likeley get away
with plugging an 11.1V (or 12-13V fresh off the charge) battery into any of
the pins on an Arduino. You'll be looking for another RasPi if you made _that_
mistake...

~~~
falcolas
In this case, it wasn't the voltage, which had been brought down to 5v by the
motor controller, it was the 160+amps. Not milliamps, amps (3300 mah, 50c
battery).

Drone batteries are nasty pieces of work...

~~~
bigiain
Indeed.

I wasn't paying enough attention when soldering a plug onto a 7 cell 5800mAhr
40c battery once. I melted the tip of my iron, and pretty much vapourised the
plug's contacts... (The battery seemed fine about it - I got 6 or 8 months out
of it powering a bicycle before it started to show signs of imminently-firey
puffiness...)

------
std_throwaway
A quicker guide for real beginners:

Do you want to understand in detail what's happening? => Arduino UNO

Is the UNO too small/slow? => Arduino Due

Still too small or you really just want a small computer running Linux but
with GPIO-Pins? => Raspberry PI

~~~
jwr
I disagree. Everything you listed a) can't be used for products, b) doesn't
let you make progress beyond "oh look, I lit up an LED!".

Sure, if you never programmed a small device, by all means, start with an
Arduino. But after you do light up that LED, please learn more. Go bare metal,
learn about interrupts, state machines, entering sleep states -- without those
things you'll stay forever in the toy world. In the real world, if you work
with battery-powered devices, you never have the comfort of busy waiting for
your UART/I2C transmission to finish, or calling analogRead() and getting
immediate results (because ADC takes time and you want to do it
asynchronously).

It's my pet peeve: I'm very happy that Arduino has been such a success, but I
think too few people progress beyond that, and many believe this is how one
programs embedded devices.

As for RPI, it's neither a production device, nor a learning tool for embedded
programming. The complexity involved means there is no way a beginner can
understand everything that's going on.

~~~
std_throwaway
As the other poster stated, you don't really disagree, just misunderstand.

You can actually do everything you need in the Arduino IDE and then leave the
IDE, compile and upload your own program written from scratch to the UNO. All
that while staying compatible to the dozens of hardware extensions out there.

The "Arduino" part is not the destination, it's three quarters of the path to
the destination and that path is already paved.

~~~
jwr
No, I do not misunderstand -- I design products, as in things which are
produced. Arduino is not for making products.

------
jordz
We use NXP/Kinetis chips (Cortex M0+) and have been relatively happy with them
from a cost and hassle point of view. When developing we use SWD with a
kinetis dev board as the programmer hooked up to the target MCU. We have had
strange issues with the MSB bricking things when updating the bootloaders but
thankfully they're cheap enough to replace.

------
contingencies
1: PLAY "Shenzhen I/O"[0]

2: JMP :1

[0] [http://www.zachtronics.com/shenzhen-
io/](http://www.zachtronics.com/shenzhen-io/)

~~~
falcolas
Be sure to jump to Factorio when you want a bit more experience in designing
circuit traces. It's amazing how quickly main bus designs naturally evolve.

~~~
contingencies
Hehe, literally in Shenzhen right now. There are loads of people with better
skills. I am happy to outsource.

------
bschwindHN
How is almost no one talking about the esp32? WiFi, Bluetooth, two cores, and
an ultra low power processor that can wake the main cores for when you need
low power consumption are just the main features of this thing, there are
plenty more. Not to mention they have a great tool chain with lots of example
code.

------
plandis
Starting with a beefy ARM chip! Try Arduino. If you are not familiar with
micro controllers you might as well stick to something that is made for
beginners. Plus as you get more advanced you can always use the raw AVR chip
without the added Arduino bootloader.

------
maxander
Its slightly ironic that this article "for beginners" is filled with obscure
acronyms he doesn't define (UART, BOM, BLE...).

~~~
tptacek
A more productive way to make this point is to simply ask what the terms mean.

UART is a programmable serial interface; it usually refers to the kind of
serial you speak to peripherals in the outside world, as opposed to something
like SPI, which is serial spoken to components on the same board.

BOM is "bill of materials". It's the catalog and price of all the components
needed to ship an actual product. If your chip doesn't have an RTC (clock),
and you need to buy another part to provide it, that adds to your BOM.

BLE is Bluetooth Low Energy.

~~~
maxander
Its all readily googlable, certainly. My point was that its poor practice when
writing a piece aimed at introducing people to a subject; if they have to go
to google every few lines to see what something means, that distracts
attention from what the article is actually trying to convey. For that matter,
they could just as easily google for a different article.

~~~
skrebbel
Your confusion stems from what kind of beginner the author means. You read it
as "total beginner to anything vaguely related to microcontroller programmer".
I assume the authors means it as "has _programmed_ stuff with microcontrollers
before but never made a hardware design from scratch yet". After all, picking
a microcontroller is a design/architecture choice more than a programming
choice.

~~~
maxander
Well, then there's another term he ought to define! :D I've done several
projects using various flavours of Arduinos and Pis, but that sort of
hobbyist-maker-level experience hasn't lead me to encounter an acronym for
"Bill of Materials."

~~~
wolf550e
Few people have seriously contemplated ordering the manufacturing of a small
run of something they themselves designed. More people have seen the term BOM
when reading estimates of how much it costs big brands to manufacture a
smartphone or a game console in industry publications or even in the more
technically-oriented consumer reviews.

------
69mlgsniperdad
Couple of thoughts after skimming the article. Consider weighing the
importance of being able to upgrade or change uC. Don't choose a controller
made by only one manufacturer (unless there is a level of certainty or
confidence in their continued production/support and profitability). It would
be unfortunate for example, if you used an atmega microcontroller and they
went out of business, or changed their strategy and abandoned a platform,
requiring you to switch to an alternative and rewrite some or all of your
code. Having a codebase that can be made to run on different platforms easily
would be ideal.

If there is a good chance, after a small order, you realize from feedback you
are missing some crucial features and need to make changes, changes which
require more it's higher or more precise clock, or whatever, make sure that
the jump to the next size chip doesn't abandon or make a drastic jump in price
or available volume. If you plan to manufacturer your product for a long time,
ensure that you are confident in the availability of quantities at similar
price for however long you expect to require it. Always be wary of jumping on
board anything brand new. The Intel Edison/Curie for example based on the
Quark ended up having an unfixable segfault, and was virtually abandoned
shortly after it's release.

------
cmrdporcupine
Parallax Propeller

~~~
shmolyneaux
As someone who has used the parallax propeller, I feel like you a doing a bit
of a disservice to not include some reasons for or against it.

Cons:

\- Comparatively high price point at $8

\- The custom 8-core architecture is more difficult to make full use of

\- No other chips in the family (can't flexibly move up or down in flash size
/ IO / core count)

\- No interrupts

\- Uncertain availability, and may be nearing end-of-life (this is
speculative)

\- Programming in C is secondary to the proprietary scripting language SPIN
(which has an interpreter in the chip)

Pro:

\- The processor is open source under GPL v3

\- Multicore architecture makes it easy to create systems that work
concurrently

\- VGA output

\- No interrupts

\- SPIN isn't that bad... and assembly code integrates nicely with it

~~~
cmrdporcupine
Wow, some lovely downvotes for making a suggestion. Not sure how two words can
be so offensive to people...

Other advantages to Propeller in addition to what you say:

    
    
      - DIP form factor, easy to breadboard
    
      - Very little supporting circuity needed. Very easy to set up.
    
      - Enthusiastic intimate helpful community on the forum
    
      - GCC available (not an advantage over Arduino but it exists you don't have to use SPIN)
    
      - Pretty high performance compared to Arduino -- 80mhz on 8 cores [tho that doesn't tell the whole story since memory accesses to the shared memory take a lot of cycles)
    

Other disadvantages:

    
    
      - Small memory space.  32k of slow shared memory space, only 2k per cog (core)
    
      - New Propeller 2 is taking years to come out and the old Prop 1 is really starting to show its age

~~~
Taniwha
I'm not sure DIP form factor is a pro these days - it ups manufacturing costs
a lot - unless of course all you are making is breadboards - are there SMT
versions available?

~~~
cmrdporcupine
Yes, they sell in both. DIP is generally better for hobbyists.

