QualityInspection.org

Quality Assurance, Product Development, and Purchasing Strategies in China

You are here: Home / New Product Development / Selection of a Chip Set and Planning the Writing of Firmware

Selection of a Chip Set and Planning the Writing of Firmware

by

After the design of the PCBA schematics comes the time to choose a chip set and to start working on the firmware.

(If you are not inclined to read technical how-to articles, this will be quite boring to you… But we are trying to give a complete picture of what it takes to develop an electronic product.)

Let’s look at these 2 steps one by one.

1. Chip set selection

A microprocessor uses microelectronic fabrication techniques to shrink the Central Processing Unit (CPU) to a very small size; usually a single “chip.”

A microcontroller uses the same techniques to shrink the entire computer to a single chip (or very small module.) Just connect power and it starts doing its thing.

A microcontroller is just the thing you want, if you want to talk to individual switches, motors and LEDs for example, just like we are looking for in our drone project.

Common applications to name a few include:

  • Audio products
  • Industrial controllers
  • Motor control
  • Networking systems
  • Medical devices
  • Other complex communication and drive systems

Many Chinese suppliers can do this for you, but will NOT be transparent about the supplier of microcontroller. It means you will have a hard time re-developing all from scratch if, for whatever reason, you decide to drop that supplier. (Imagine, for example, that they double their price… this is not uncommon.)

When considering what chip set (microprocessor) to use, there are different factors to take into consideration. We found a good article which outlines 10 steps to selecting a microcontroller — those 10 steps are summarized here.

Step 1: Make a list of required hardware interfaces

Using a general hardware block diagram, start by making a list of all the external interfaces that the microcontroller will need to support. There are two general types of interfaces that need to be listed.

  • Communication interfaces. These are peripherals such as USB.
  • Digital inputs and outputs, analog to digital inputs, etc.

These two interface types will dictate the number of pins that will be required by the microcontroller. Here is a generic example of a block diagram with the i/o requirements listed.Block_Diagram_Example

Step 2: Examine the software architecture

How heavy or how light the processing requirements are will determine whether you go with an 80 MHz DSP or an 8 MHz 8051. Estimate how long and how often each task will need to run. Get an ‘order of magnitude’ feel for how much processing power will be needed. The amount of computing power required will be one of the biggest requirements for the architecture and frequency of the microcontroller.

Step 3: Select the architecture

Using the information from steps 1 and 2, an engineer should be able to start getting an idea of the architecture that will be needed. Can the application get by with eight bit architectures? How about 16 bits? Does it require a 32 bit RAM core?

Step 4: Identifying memory needs

Flash and RAM are two critical components of any microcontroller. Make sure that you don’t run out of program space or variable space.

Step 5: Start researching the microcontrollers

By now, you have a better idea of what the required features of the microcontroller will be. A good place to start might be a microcontroller supplier such as Arrow, Avnet, Future Electronics, or similar. It is always best to talk to a representative and discuss your needs and outline the requirements for the project.

Step 6: Examine costs and power constraints

Let’s say you have a number of potential candidates. Now comes the time to examine the power requirements and cost of the part. If the device will be powered from a battery and mobile, then making sure the parts are low-power is absolutely precarious. If it doesn’t meet power requirements, then keep weeding the list down until you have a select few.

Step 7: Check part availability

What will the lead times be for the part? Are they kept in stock at multiple distributors?

Step 8: Select a development kit

One of the best parts of selecting a new microcontroller is finding a development kit to play with and learn the inner working of the controller. Once an engineer has settled his heart on the part he wants to use, he should research what development kits are available. If a development kit isn’t available, then the selected part is most likely not a good choice and they should go back a few steps and find a better part.

Step 9: Investigate compilers and tools

The last consideration is to examine the compiler and tools that are available. Most microcontrollers have a number of choices for compilers, example code, and debugging tools. It is important to make sure that all the necessary tools are available for the part. Without the right tools the development process could become tedious and expensive.

Step 10: Start experimenting

Usually, the development kit arrives long before the first prototyped hardware. Take advantage by building up test circuits and interfacing them to the microcontroller. Choose high risk parts and get them working on the development kit.

It may be that you discover the part you thought would work great has some unforeseen issue that would force a different microcontroller to be selected.

Another good resource about microcontrollers is this article.

2. Firmware layout and planning

There are basically five steps you can follow to get the firmware architecture right. It is well explained in this article.

Is this something you should let your Chinese supplier do? In most cases, they have to subcontract this to a specialized company (which you will never be in direct contact with, naturally). It has several implications for you:

  1. That specialized company generally works only with one type of microcontroller, so they will tend to guide your selection based on that factor and you might end up with a subpar component selection. 
  2. You will never be able to see the source code. 
  3. Down the road, even the smallest change in firmware will be invoiced 5,000 RMB. Be ready for that… And keep in mind that you have other options for developing the firmware and owning the source code.

Here is a quick overview.

Step 1: Identify the requirements

Properly written requirements define the WHAT of a product. WHAT does the product do for the user, specifically.

If a requirement is written properly, a set of tests can be easily constructed to verify that requirement is met.

Step 2: Distinguish architecture from design

The architecture is hard to change and must be got right through careful thinking about intended and permissible uses of the product. Architecture is best documented via a collection of block diagrams, with directional arrows connecting subsystems.

Step 3: Manage time

Some of the product requirements will mention explicit amounts of time. For example, consider the drone example from earlier, the intruder capture device must be deployed within a “30 millisecond timeframe once the action to deploy has been triggered”. That is a timeliness requirement.

“Within 30 ms of trigger” is just one deadline for the drone implementation team to meet. (And something to be tested under a variety of scenarios.) The architecture should make it easy to meet this deadline, as well as to be certain it will always be met.

Step 4: Design for test

Every embedded system needs to be tested. Generally, it is also valuable or mandatory that testing be performed at several levels. This is just like any other type of programming.

Step 5: Plan for change

Will you use a single source code base to build firmware for a family of related products? The architecture might have to be stretched in the direction of foreseeable planned feature additions.

—

Next week we’ll look at the next step (prototyping).