This three-part article is abstracted from the book "Embedded Hardware Know It All", which provides a "360 degree" view from best-selling authors.
Editor's Note: This three-part article is abstracted from Chapter 7 of the book Embedded Hardware Know It All with the kind permission of the publisher.
See also Part 2.
The book features a "360 degree" view from best-selling authors Jack Ganssle, Tammy Noergaard, Fred Eady, Lewin Edwards, David J. Katz, Rick Gentile, Ken Arnold, Kamal Hyder, Bob Perrin, and Creed Huddleston.
The Newnes "Know It All" series takes the best of what their authors have written over the past few years and creates a one-stop reference for engineers involved in markets from communications to embedded systems and everywhere in-between.
Embedded Hardware Know It All provides: "The ultimate hard-working desk reference with all the essential information, techniques, and tricks of the trade in one volume."
Introduction
The start of a complex embedded project, particularly in a small organization without engineers
who can be dedicated full-time to component procurement, can be extremely stressful.
Until a first-round prototype is built and tested (and often even after this stage), it is usual for
hardware requirements to be at least slightly vague, particularly vis-à-vis the exact breakdown
of which functions are expected to be integrated into the microcontroller and which will be
off-chip. As the design engineer, some of your goals are obviously ease of firmware and hardware
development, low bill-of-materials cost, and reliability of sourcing. You will probably
start with a list of hardware requirements and match those up against selection matrices from
different vendors to find a part that has as many of your features as possible on-chip.
At this point, what you really want is a vendor-neutral parametric search engine for which you
can select the performance and peripherals you want and obtain a list of suggestions collated
from everybody's catalogs. Unfortunately, most of the search facilities available online leave
much to be desired. Many manufacturers don't have full parametric search engines available,
and those that do obviously only list their own parts. Third-party search engines do exist, but
they are usually premium services for which you will have to pay – and again, they only list
products from manufacturers with whom they have a relationship. Also, the total startup cost
of development – evaluation boards, tools, etc. – is an important factor to us (for some readers, perhaps even more important than the unit cost of the microcontroller), and this cost will not
be listed by parametric search engines. Finally, as with any other search facility, it can be difficult to match your needs with the list of keywords provided in the search engine.
This is one occasion when there is no substitute for peer support. Even if you think you've
found a perfect match already, it's well worth searching Usenet archives (groups.google.com)
for discussions on similar applications to your own. A carefully phrased question may lead
to even more useful suggestions. Even if you are intimately familiar with every IC vendor
that impinges on your industry, you might miss a new product announcement and thereby not
know to check manufacturer X's catalog. Sometimes the only clue you need to lead you to the
right part is the information that manufacturer X makes 32-bit microcontrollers! Furthermore,
other engineers who have worked with the part may be able to point you to low-cost, third-party
evaluation platforms or off-the-shelf appliances that can be used as demo boards, and they will
be better positioned than anyone else to give you relatively unbiased opinions on real-world
difficulties of using a specific device.
In the early days, it is also doubly hard to make an optimal price/performance choice, because
the selection sheets generally won't show pricing. For any part that can't be bought anonymously
off the shelf (and unfortunately the majority of 32-bit microcontrollers fall into this
category), most chip vendors expect you to establish a relationship with their distributors. This
can waste a lot of time in profitless face-to-face meetings. My own experiences with local reps
and distributors in the United States have been very patchy, and I have often found that their
knowledge of the 32-bit parts on their line card is limited to whatever bullet points the manufacturer
printed on the sales literature. The distributors want accurate annual usage forecasts
before they will give you sensible pricing, and they obviously have little or no incentive to
deal with small-volume purchasers like students or hobbyists. Political difficulties related to
sales commissions also arise when you are designing the product in one country but intend to
manufacture it in another. Furthermore, the distributors and reps will be most likely to quiz
you on your other requirements and try vigorously to sell you other parts from their line card.
Although this possibly has some marginal convenience benefits if you intend to source and
manufacture locally, it certainly isn't the ideal way of minimizing the bill-of-materials cost of
your product.
It's all too easy to become trapped in an endless circle trying to seek an optimal solution to
all these problems, so you shouldn't attempt it. Recognize from the outset that this is a classic
"traveling salesman" problem (perhaps even in the literal mathematical sense) and that your
goal is merely to find an acceptable solution in time to finish your project and send it to the factory (or submit it to your professor, if you're a student). Your goal is not to find the best possible
solution. If your team has enough personnel to dedicate a lot of person-hours to sourcing components,
you will probably be able to find a better solution than the one-person "team" scouring
catalogs on a time limit, but a suboptimal one-person solution can always be refined later if the
project goes into production in quantities that justify it. As in any other industry, our goal is to
develop a product that works properly and is ready to manufacture in a timely fashion.
With that said, I employ the following useful heuristics to filter my short list for 32-bit microcontroller
selection:
- The device should be available for anonymous online or catalog ordering in singlepiece
quantity from at least one major distributor. (In the U.S., the big names commonly
mentioned are Digi-Key, Newark, and Avnet Marshall. Digi-Key and
Newark in particular have very broad inventories and generally allow purchases in
small quantity. Avnet Marshall seems to cater more to manufacturing rather than
prototype runs; they typically have 25- or even 250-piece minimum orders
on parts.)
- Full data sheets for the device should be available without requiring a nondisclosure
agreement or committing to any kind of purchase.
- A low-cost development board should be available for the part – either the manufacturer-
recommended board, a third-party board, or even some appliance based around
the chip, as long as sufficient documentation exists to enable use of the appliance as
a test bed for your own code. You should also ask the manufacturer and distributor
if loaner boards are available; if you can borrow a board for a month or two, it will
be enough to get at least bootstrap code up and running and establish a basic level of
familiarity with the microcontroller. You can then move to your own hardware and
return the evaluation board.
- There should be a direct technical contact available at the chip vendor, at least for
emergency issues; it should not be necessary to route all questions through distribution.
(Note that I'm not advising you to abuse such a privilege – if you have a direct
manufacturer contact, it's best to contact him or her only when absolutely necessary.
But there are times when a complex problem will take weeks to solve when there are
several layers in the communication chain, versus only a day or two if you can communicate
directly with the cognoscenti at the chip manufacturer. As a small customer,
the less you use this resource, the better chance you will have that your next urgent
question will be answered speedily.)
- The device should have been shipping to OEMs for at least three to six months.
- The core should be supported by the GNU toolchain.
- There should be at least one currently shipping commercial product that uses the
device, and the larger the market for this device, the better. All too often, parts that are
consumed only by small niche markets are discontinued in favor of parts with more
general applicability.