Embedded Systems: Bridging Hardware and Software | Summaries Physics

1.1 Embedded Systems

In computing disciplines (computer engineering, software engineering, computer science,

information systems and technology), the term “embedded system” is used to refer to an electronic

system that is designed to perform a dedicated function and is often embedded within a larger

system.

Embedded systems differ from general-purpose computing devices mainly in two aspects:

• First, an embedded system is designed simply for a specific function, whereas a general-purpose

computing device, such as smartphone, laptop, or desktop computer, is not; they can be used as

Web servers or data warehouses, or can be used for writing articles, reading news, playing games,

or running scientific experiments, to mention only a few applications.

• Second, an embedded system is traditionally built together with the software intended to run on it.

Such a parallel model of developing hardware and software together is known as hardware-software

co-design. Recently, there has been a trend where an embedded system is built with a well-defined

interface open to third-party embedded software providers. In contrast, a general-purpose

computing device is often built independently from the software applications that may run on it.

An embedded system is a combination of computer hardware and software, and sometimes mechanical

components as well. Figure 1.1 gives a bird’s-eye view of a generic embedded system architecture,

where the microprocessor and the memory blocks are the heart and the brain, respectively. Embedded

software is commonly stored in nonvolatile memory devices such as read-only memory (ROM),

erasable programmable ROM (EPROM), and flash memory. The microprocessor also needs another

type of memory—random-access memory (RAM)—for its run-time computation.

When an embedded system is powered on, its microprocessor reads software instructions stored in

memory, executes the instructions to process input information from peripheral components (through

sensors, signals, buttons, etc.), and produces output to meet the needs of the external embedding system.

Given that the hardware components are chosen, most of the design effort is in the software, including

application, device drivers, and sometimes an operating system. In many cases, it is possible to build a

customized integrated circuit (IC) that is functionally equivalent to an embedded system. An IC-based

solution is a hardwired solution that does not contain software and a microprocessor. However, the

embedded system solution is more flexible and less expensive, especially when the product needs to be

frequently upgraded to accommodate new changes. In response to a new change, for the hardwired

A generic embedded system architecture.

Partial preview of the text

Download Embedded Systems: Bridging Hardware and Software and more Summaries Physics in PDF only on Docsity!

1.1 Embedded Systems

In computing disciplines (computer engineering, software engineering, computer science, information systems and technology), the term “embedded system” is used to refer to an electronic system that is designed to perform a dedicated function and is often embedded within a larger system. Embedded systems differ from general-purpose computing devices mainly in two aspects:

First, an embedded system is designed simply for a specific function, whereas a general-purpose computing device, such as smartphone, laptop, or desktop computer, is not; they can be used as Web servers or data warehouses, or can be used for writing articles, reading news, playing games, or running scientific experiments, to mention only a few applications.
Second, an embedded system is traditionally built together with the software intended to run on it. Such a parallel model of developing hardware and software together is known as hardware-software co-design. Recently, there has been a trend where an embedded system is built with a well-defined interface open to third-party embedded software providers. In contrast, a general-purpose computing device is often built independently from the software applications that may run on it. An embedded system is a combination of computer hardware and software, and sometimes mechanical components as well. Figure 1.1 gives a bird’s-eye view of a generic embedded system architecture, where the microprocessor and the memory blocks are the heart and the brain, respectively. Embedded software is commonly stored in nonvolatile memory devices such as read-only memory (ROM), erasable programmable ROM (EPROM), and flash memory. The microprocessor also needs another type of memory—random-access memory (RAM)—for its run-time computation. When an embedded system is powered on, its microprocessor reads software instructions stored in memory, executes the instructions to process input information from peripheral components (through sensors, signals, buttons, etc.), and produces output to meet the needs of the external embedding system. Given that the hardware components are chosen, most of the design effort is in the software, including application, device drivers, and sometimes an operating system. In many cases, it is possible to build a customized integrated circuit (IC) that is functionally equivalent to an embedded system. An IC-based solution is a hardwired solution that does not contain software and a microprocessor. However, the embedded system solution is more flexible and less expensive, especially when the product needs to be frequently upgraded to accommodate new changes. In response to a new change, for the hardwired A generic embedded system architecture.

solution, a new circuit needs to be designed, constructed, and delivered. In contrast, for the embedded system solution, software patches can be rapidly developed, and the upgrading process can be done over the Internet and may typically take just a few seconds. Embedded systems are widespread in consumer, industrial, medical, and military applications. Just look around your home or workplace, and you may realize that almost every aspect of our everyday life has been wonderfully touched by embedded systems: dishwasher, garage door opener, TV remote control, microwave oven, programmable thermostat, Xbox controller, and USB memory card reader. This list goes on and on. Someone said that there are more computers in our homes and offices than there are people who live and work there. If this is true, then there are even more embedded systems that have been and will continue changing every part of our lives. One proof of this statement is that about 98% of microprocessors go into embedded systems, whereas less than 2% of microprocessors are used in computers.

1.2 Real-Time Systems

There are systems that need to respond to a service request within a certain amount of time: they are called real-time systems. To a real-time system, each incoming service request imposes a task (job) that is typically associated with a real-time computing constraint, or simply called its timing constraint. The timing constraint of a task is normally specified in terms of its deadline, which is the time instant by which its execution (or service) is required to be completed. Depending on how serious missing a task deadline is, a timing constraint can be either a hard or a soft constraint:

A timing constraint is hard if the consequence of a missed deadline is fatal. A late response (completion of the requested task) is useless, and sometimes totally unacceptable.
A timing constraint is soft if the consequence of a missed deadline is undesirable but tolerable. A late response is still useful as long as it is within some acceptable range (say, it occurs occasionally with some acceptably low probability). Actual systems may have both hard and soft timing constraints. A system in which all tasks have soft timing constraints is a soft real-time system. A system is a hard real-time system if its key tasks have hard timing constraints.

1.2.1 Soft Real-Time Systems

A soft real-time system offers best-effort services; its service of a request is almost always completed within a known finite time. It may occasionally miss a deadline, which is usually considered tolerable. It is worth noting that although missing a deadline will not cause catastrophic effects, the usefulness of a result may degrade after its deadline, thereby degrading the system’s quality of service. Soft timing constraints are typically expressed in probabilistic or statistical terms, such as average performance and standard deviation. Table 1.1 gives some examples of soft real-time systems.

Antilock braking system The antilock braking system should apply/ release braking pressure 15 times per second A wheel that locks up should stop spinning in less than 1s Loss of human lives Antimissile system It never needs more that 30s to intercept a missile after it reenters the atmosphere (in the terminal phase of its trajectory) Loss of human lives, huge financial loss Cardiac pacemaker The pacemaker waits for a ventricular beat after the detection of an atrial beat. The lower bound of the waiting time is 0.1s, and the upper bound of the waiting time is 0.2s Loss of human life FTSE 100 Index It is calculated in real time and published every 15s Financial catastrophe compute only an approximate firing range, which demands more weapons being activated to cover the firing range. Since the first approach consumes fewer resources, it is the default approach employed by the system to handle incoming missiles. However, the system would switch to the second approach if it predicts that waiting for the precise calculation would take too much time for the incoming missiles to be safely destroyed. In contrast, for a soft real-time system, it typically does not take any corrective actions until the bad thing really happens. For example, a DVD player has to synchronize the video stream and the audio stream. A missed deadline happens when, owing to data loss or decoding latency, the timing difference of the two streams exceeds a certain tolerable threshold. After a missed deadline has been detected, a DVD player may selectively discard the decoding of some video/audio frames to resynchronize the two streams.

4.1 Introduction to Interrupts

Interrupt is a mechanism by which a microprocessor can alter its flow of execution to handle asynchronous or synchronous events. Asynchronous events are those that can occur at any time and typically occur at unanticipated spots of the running program, while synchronous events are those that can occur only at planned or anticipated spots of the running program. Interrupts can be classified into three categories: external interrupts, software interrupts, and internal interrupts:

External interrupts, also called hardware interrupts , are asynchronous events generated by external hardware devices to get the microprocessor’s attention.
Software interrupts, also called traps, are synchronous events generated by special processor instructions placed in a program. Software interrupts are unconditional in the sense that the execution of the special instruction will always generate a software interrupt.
Internal interrupts, also called exceptions , are synchronous events generated by the processor itself whenever some abnormal condition occurs during instruction execution. Internal interrupts are conditional in the sense that the execution of some valid instruction (e.g., the division instruction) may cause an exception (e.g., if the divisor is 0).

4.2 External Interrupts

I/O devices are the liaison between an embedded system and its work environment. There are mainly two approaches for an embedded system to interact with I/O devices: polling and interrupts. Polling is the simplest approach used in embedded systems to handle I/O activities synchronously. Assume that a peripheral I/O device intermittently receives data, which must be processed by the processor. In polling, the processor needs to continuously (or at least regularly) check if data have arrived. The processor typically does nothing other than check the status register of the I/O device until it is ready, at which point the device is accessed and serviced. Polling is relatively straightforward in design and programming. In a simple system with only one I/O device, polling is perfectly appropriate because the system can just wait until the I/O device becomes ready for a service. Waiting for a device to get ready is no longer appropriate in systems involving multiple peripherals. In such a case, the polling mechanism could be improved such that the readiness of all the I/O devices is sequentially checked in an endless loop. When a device is not ready, instead of passively waiting until it becomes ready, the processor turns to check (and service, if possible) the next device. (This is actually called round-robin architecture, and is covered in Chapter 12.) When there are too many I/O devices to check, the time required to poll them can be considerable, and the system might break the deadlines of certain tasks. In such a case, the so-called interrupt-driven I/O comes into play. Interrupt is a commonly used mechanism for computer multitasking, especially in real-time computing. Hardware interrupts are events generated by external hardware devices to get the microprocessor’s attention. For example, pressing a key on the keyboard or moving the mouse triggers hardware interrupts that cause the processor to read the keystroke or mouse position. Interrupts allow an embedded system to respond rapidly to multiple real-time events. Hardware interrupts are triggered when the interrupt request (IRQ) line(s) of a microprocessor is asserted active by the electrical signals sent from hardware devices. Typically, the processor samples its interrupt input request line(s) at predefined times during each bus cycle. An IRQ is detected if the interrupt line is active when the processor samples it. Hardware interrupts are asynchronous in the sense that they can occur at any time and at any place in the running program. When an interrupt is received, the processor automatically suspends the program that is currently running, saves its status, and transfers control to a special program called the interrupt service routine (ISR). Once the ISR has run to completion, the control returns back to the original program that was suspended. There are two approaches for a microprocessor to locate the ISR of an interrupting device: nonvectored interrupting and vectored interrupting.

Embedded Systems: Bridging Hardware and Software, Summaries of Physics

Related documents

Partial preview of the text

Download Embedded Systems: Bridging Hardware and Software and more Summaries Physics in PDF only on Docsity!

1.1 Embedded Systems

1.2 Real-Time Systems

1.2.1 Soft Real-Time Systems

4.1 Introduction to Interrupts

4.2 External Interrupts

4.3 Software Interrupts