|
Embedded system programming, or writing software that drives controllers, traditionally meant squeezing more performance out of limited memory and processor resources. However, increasing processor speeds and decreasing memory costs now enable a host of new intelligent devices to such an extent that real-time, embedded computers now outnumber all other types of computers. Today, the limit to growth is the ability of programmers to write code fast enough to capitalize on these expanding resources.
You’d think that the concept of “real time” would be pretty straightforward. Unfortunately, that’s not the case. Here’s a perspective on real time and its implications for embedded systems development. Quick—come up with a one-sentence definition of embedded. With embedded PCs becoming common, and even MIPS chips buried in inexpensive consumer products, embedded is a term whose meaning is ever more nebulous. So too for the designation real time, a term whose meaning is more in the mind of the beholder than cast in linguistic concrete. In fact, the community recognizes this confusion by defining two sorts of real time: “hard” and “soft.”
A hard real-time task or system is one where an activity simply must be completed—always—by a specified deadline. The deadline may be a particular time or time interval, or may be the arrival of some event. Hard real-time tasks fail, by definition, if they miss such a deadline. Notice this definition makes no assumptions about the frequency or period of the tasks. It could be a microsecond or a week—if missing the deadline induces failure, and then the task has hard real-time requirements. Soft real time, though, has a definition as weak as its name. By convention, it’s those systems that aren’t hard real-time, though generally some sort of timeliness requirements exist. If missing a deadline won’t compromise the integrity of the system, and if generally getting the output in a timely manner is acceptable, then the application’s real-time requirements are “soft.” Sometimes-soft real-time systems are those where multi-valued timeliness is acceptable: bad, better, and best responses are all within the scope of possible system operation.
Interrupts are inexorably linked with real-time systems, as only the interrupt bypasses the time-consuming tedium of polling multiple asynchronous inputs. Yet a surprising number of very fast applications are crippled by the overhead associated with servicing interrupts. Though chip vendors specify interrupt latency in terms of the time the hardware needs to recognize the external event, to firmware folks a more useful measure is time-from-input to the time we’re doing something useful, which may be many dozens of clock cycles. The multiple levels of vectoring needed by the average processor, plus important housekeeping like context pushing, are all ultimately overhead incurred before the code starts doing something useful. Similarly, the real-time operating system (RTOS) is one of the most important and common tools in the real-time arsenal. Yet the RTOS also provides no guarantee of real-time response. The first rule of real-time design is to know the worst-case performance requirements of each activity—and only then select the right implementation (CPU, hardware design, and firmware organization). Thinking in the time domain, as well as in that of the conventional procedural, is crucial.
|
