声色不动已成峰 保利中央海岸2期开盘劲销再续传奇

Could you concisely define "embedded system design" off the top of your head? This article looks at the essential characteristics of an increasingly prominent specialization within the field of electrical engineering.

A definition can be an elusive thing. Sometimes we understand a word but can’t really define it. Other times, in the process of trying to define it, we realize that we don’t really know what it means, after all. I suspect that the term “embedded design” would leave many of us in the latter situation.

To some extent the uncertainty is justified, since there is no official organization that can establish and enforce the precise use of vague technical terminology such as “firmware” (as opposed to “software”), “wearable” (it is possible to “wear” things that are quite large), and “embedded design” (which seems to imply that the designer is laying out a PCB while being “embedded” in something).

The simplest definition of "embedded system design" is that it is the design of embedded systems. It’s a concise and straightforward definition, but one that is also quite useless without a discussion of the meaning of “embedded system.”

What Is an Embedded System?

The following definition of an embedded system is based on my experience and a bit of online research: An embedded system is an electronic device that

• has a central component that performs computational tasks,
• is designed for specific and limited functionality, and
• is implemented as a component of an electrical or mechanical system.

Perhaps the most irksome aspect of this definition is the conflict among the terms embedded system, electronic device, and electrical or mechanical system.

It seems to me that, in discussions such as this, “system” should be reserved for physically larger collections of mechanical and electrical components that are integrated into a functional unit; examples would be an MRI machine, a heating system, and a laser printer. “Device” should be used when we’re talking about an individual circuit board or electronic module that serves as a component of a system—for example, the gradient timing and control module in an MRI machine, the programmable thermostat in a heating system, or the data-processing module in a laser printer.

However, the term “embedded system” is helpful because it reminds us that these devices usually exhibit characteristics of a system, even if it is a purely electronic system and a rather small one at that. It’s a system (embedded) within a system.

I suppose that a standalone IoT device (such as this one from Silicon Labs) could be considered an embedded system if the Internet (or a private network) is viewed as the larger system.

For the remainder of this article, we’ll use the definition of “embedded system” to explore concepts and techniques that should be high on your list of priorities if you’re trying to initiate or solidify a career in embedded system design.

What's in an Embedded System? A Central Component for Computational Tasks

An embedded system is, by our definition, a central component that performs computational tasks. In most cases, this will be a microcontroller, but it could also be a microprocessor, a digital signal processor, or an FPGA.

Every embedded designer should be thoroughly familiar with firmware development. (FPGA skills, on the other hand, are usually optional. If I had to guess, I would say that less than 5% of embedded systems use an FPGA as the central component.)

A block diagram of an embedded system that I designed for the C-BISCUIT robot.

“Firmware development” encompasses the following tasks:

• Writing code. ...usually in C. Knowledge of assembly language is essential, in my opinion, because assembly instructions tell you how a processor really works. You don’t need to write code in assembly, but you do need to understand it.
• Configuring peripherals. Many, probably most, embedded systems will incorporate the use of peripherals such as an analog-to-digital converter, a programmable counter module, an I2C interface, or a USB controller. Embedded designers need to thoroughly understand these hardware modules: how they work, how they’re typically implemented, and how to translate between the desired functionality and the bits in the configuration registers.
• Testing code. This doesn’t mean powering up a device and watching it for three minutes to confirm that it works. You need to systematically test all the functionality while exposing the device to a variety of operating conditions.
• Refining code. Maybe your firmware always works perfectly the first time, but mine doesn’t. Initial testing is primarily a means of determining the corrections and adjustments that are needed to bring the code to a functional state.
• Debugging code. “Debugging” is a somewhat vague term; here I’m using it specifically to describe the process of finding and correcting subtle errors in code that is already more or less functional. Debugging is an essential skill that is difficult to learn from books and articles; proficiency comes from extensive personal experience and observation of seasoned embedded designers.
• Verifying code. At this point, you do whatever you can to ensure that the code correctly performs the required functions and doesn’t catch fire when something unexpected occurs elsewhere in the system or in the surrounding environment. An example is the “monkey test”—you give the code continuous random input (as if a monkey is playing with a keyboard) and confirm that the device doesn’t malfunction.

A flowchart for an SPI state machine that I used in one of my projects using an EFM8 microcontroller. Careful firmware design is not always easy—but hastily written, poorly organized code can be a major headache down the road.

What Does an Embedded System Do? Specific and Limited Functionality

Embedded design requires us to be diligent in establishing, understanding, and satisfying requirements. Maybe someone in the organization wants lower noise or faster sampling rate or longer battery life or an additional communication interface. The embedded designer’s response is, “Well, it’s nice to have wants.” (Note that this is usually something that you would just think, not say, especially if the “someone” is your boss.)

An embedded system is intended for specific functional objectives, and it is an engineer’s responsibility to identify the capabilities and characteristics that are truly necessary and then design the device accordingly.

How Do You Implement an Embedded System Design? A Component of a Larger System

An embedded device may be tested as a standalone unit and it may even be capable of functioning as a standalone unit, but embedded design, in general, is fundamentally bound to the concept of integration. Designers of embedded systems need to be familiar with power distribution, communication interfaces, and interconnection techniques because these are the tools that we use to successfully integrate a device into a larger system.

It’s important to remember that the people working on other components of the system may know almost nothing about the embedded device that you’re designing. And furthermore, they may not want to know any more than is strictly necessary—they have their own projects to worry about. This is where an interface control document comes into play. A critical aspect of successful embedded design is developing organized, straightforward interfaces and then carefully documenting these interfaces so that your device can be efficiently integrated into the larger system.

Conclusion

Embedded design is an interesting field because it incorporates a pleasantly diverse set of skills and tasks, including analog design, firmware development, PCB layout, interface design, and system integration. If you’ve worked on something that you would consider an embedded system, feel free to describe it in the comments so that we all can form a more complete idea of the types of devices that fall within this category.