Hardware versus Software

Another major “what’s good enough” criterion for embedded systems comes from deciding what belongs in hardware vs software. Products designed with three major philosophies:

  • Put as much as possible into software and ignore the extra processing power the system might need.
  • Put as much as possible into hardware to reduce the software chore.
  • Implement in hardware whatever you’re familiar with and then use software to implement the stuff you don’t know how to handle.

The tradeoff between hardware and software presents a difficult decision for most products. Remember, too, that hardware brings along a recurring cost for every unit produced, and don’t forget that the more hardware a product contains, the more chance that a unit can fail in the field.Software design and complexity, though, can quickly overwhelm the cost savings of moving features over from hardware. Anticipate the future; think about what might change within the product and how the design (both hardware and software) would change to accommodate the requirements. For example, on a measurement and control system, the following often change:

  • The loop-control time might decrease for better control.
  • The system might store more parameters than the initial requirements spec’d.
  • The required analog resolution will probably increase with time.
  • The math-processing requirements will probably increase.
  • The system might need more analog inputs to handle additional sensors.

Just like practicing defensive driving, you can also design embedded systems with caution. In the above example I’d probably create a system with the following features:

  • One or more extra analog input channels, if these channels won’t easily fit into a design, leave room-not just board space, but also chip-select lines and loading capacity-for an additional chip you could later load if needed.
  • Make sure processor bandwidth has sufficient room to add 50% more capability. Today this aspect generally doesn’t significantly impact processor cost, but it could affect the device’s EMC characteristics and power usage.
  • If not outrageously expensive, design in an A/D with more bits of resolution than what the application presently calls for, such as going from a 10-bit to a 12-bit converter. Again, the upgrade entails little cost difference, but it might extend the life of a product line.
  • Design software to easily allow additional sensor inputs for use in the control loop or for recording control quality. Good structured design with object-oriented philosophies easily allow new features without destroying existing code.

Try to avoid is eliminating any hardware control loops. Sometimes they’re necessary, but if the software does this chore, you’ll have more control over future changes, plus it’ll be easier for a technician or ATE device to diagnose a problem.

Source: www.sltf.com

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s