|
An embedded system is a different beast than your personal computer, and the
some of the challenges developing embedded systems are also different.
Embedded developers generally learn a wide array of skills because we must
be more aware of both the hardware and software in the device.
Your software is connected pretty darn
closely to the hardware, and your job is more than making sure that the compile and link return no errors.
You'll spend less time in your cube and more time in the lab with the hardware folks and integration/
test folks. (In some companies, you will BE the hardware, test and integration folks!)
Some of the characteristics of embedded systems and development methods used to
create them are listed below. This is not comprehensive, but designed to
be an introductory overview.
An embedded system has several typical parts. Usually it has much less hardware
support than a PC - the only hardware that is included is hardware that needed for the application.
It includes a microprocessor which is generally MUCH less powerful than whatever is in your
personal computer, some memory (RAM), some nonvolatile storage (memory like your hard drive
that remembers data when the power is turned off), buttons or sensors to provide input, and often a display.
The device also has a battery and/or a power supply that plugs into the wall.
Think about your phone or DVD player - embedded systems generally don't need a disk drive, CDROM,
high resolution video, keyboard, multimedia, or high speed networking capabilities
[Rehman and Paul, 2003]. However,
cell phones are now transferring high speed data, and the storage devices
(like USB memory sticks) require very little power and are being integrated
into embedded devices.
(picture of embedded system components here)
- Central Processing Unit (CPU)
- The CPU is within the microprocessor, and is the brains of the device.
It controls all timing, communications with memory
and the outside world, updating any displays, lights, or output devices, and
reads all input data from external devices like keypads and buttons. The CPU
contains the ALU, or Arithmetic Logic Unit that performs data processing operations
like addition and subtraction, and logical operations. It also contains internal registers needed
to access and decode the program instructions.
- Memory (RAM)
- RAM is memory that is used for temporary storage of variables. The microprocessor
usually contains some RAM, and additional RAM may be included as separate chips.
- Nonvolatile Memory (ROM or Flash)
- ROM is Read Only Memory. This is where the main program is usually
stored. It is written once when the device is manufactured, and then
never changed. Flash is a different and newer kind of memory
that can also be used to store the program. One difference is because it
can be rewritten like a hard drive. Nonvolatile memory is used to store
any data that must be saved over time. In the past, only ROM was include inside
the microprocessor; now it is common to find flash memory inside as well.
- Inputs
- Embedded systems typically wait for, and then respond to, data that they
sense from the outside world. Common inputs include sensors and buttons.
My microwave waits until I enter a time using numbered buttons. When I press start,
it takes the number I entered and runs the microwave for that period of time.
The rest of the time, my microwave sits happily on the counter waiting for someone
to press more buttons.
-
- Buttons are digital inputs (the button is either pressed or not pressed
.) Inputs may be analog as well. The thermometer on my window sill measures the
temperature outside every few minutes, and then displays the value for me to
see at any time. Analog data like temperature must be converted into digital
signals that the computer can understand. This is done using
A/D (analog to digital) converters that are often included as an internal part of the
microprocessor.
- Outputs
- Embedded systems don't just sense external conditions, they often respond by
moving motors, flashing lights, and sending data messages through cables
or over the air. My microwave responds to the "START" button by shooting microwaves
into my cup to heat my cold coffee. Outputs can also be analog or digital. To create analog
outputs, a DAC (digital to analog converter) is used.
Trends in Embedded Systems
Technological advancements allow four different trends in embedded systems:
smaller size, lower price, same features-different technology, and new features.
The first trend is size; embedded systems are getting smaller and smaller as the components
inside them shrink. Semiconductors (e.g., chips, ICs, microprocessors, memories)
continue to shrink as manufacturers try to pack the same functionality
in a smaller package. Remember the first cell phones that came in suitcases?
How about the first portable video recorders were? Check out this
1967 General Electric portable video tape recorder tri-pack: TE-23 cctv camera, TH-31 monitor
and the TD-1 tape recorder. [Ref]
This is an embedded system!
The second trend is toward lower prices for the same devices. This is due partially
to cheaper components and performing some design and manufacturing done overseas,
but it is also due to
component customization. A single custom ASIC (application specific integrated
circuit) can be created to perform the tasks of several individual hardware
chips and support circuitry. An entire circuit board can be shrunk into a chip!
Creating an ASIC is a common step in the development and manufacturing process of
a product. If the product is successful, a larger profit can be had if the
cost to build the device is decreased, and an ASIC can make this possible.
The third trend is in maintaining functionality using a different technology.
For example, consider old and new phone answering machines.
When answering machines first came out, they were larger than most phones and somewhat expensive.
Messages were stored on tape and the device had many moving parts. Moving parts
are potential points of failure, leading to returns and reduced profits.
New answering machines
perform the same functions as the older machines, although messages are stored
digitally on memory chips rather than on tape. Fewer moving parts and
cheaper components result in a more robust product with fewer returns and increased
profit for the manufacturer.
A fourth trend, and maybe the most obvious,
is creating totally new devices, or creating new features for existing devices.
Washing machines can now sense the level
of water "dirtiness" and adjust the wash cycle accordingly. Your car can remember
exactly how you like your seat positioned. Cell phones now take pictures and video
and allow you to send these to your friends and family over the air. USB memory
sticks are replacing floppies for easy transfer of large data files and pictures.
(Remember backing up your computer in the 1980's using 360K DD 5.25" floppies? Then
the high density, and then the much loved 1.44M 3 1.2 " floppies came along, and in funky
colors.]
Even if embedded systems seem "low tech" compared to your personal computer,
many technological advances are targeted specifically at the embedded market
to improve characteristics (like power consumption) that are less important
to the PC market.
As a developer, you will be more concerned about how often your device needs
be charged than if your device can support high speed graphics for multi-player
interactive games (at least for the present!). The hardware design will
determine a baseline level of power consumption for your device, but
careless software can radically reduce battery life.
The code I write affects how fast the battery drains?
Yup. More specifically, how you write the code is as important as what
you write. Although this may sound strange, a major goal when writing embedded software
is to keep it from running. All the time that your
code is running, the battery is being drained at a higher rate than if the
microprocessor is sitting there doing nothing (i.e., in "idle" or "sleep" mode).
Inefficient code takes longer to execute and it keeps the microprocessor busy
for longer periods of time. And the battery bars start dropping!
What does "idle mode" mean?
Think of it this way -
you work in the mail room and whenever a package
or letter comes in, you have to deliver it to the correct department.
Say you deliver a letter to the marketing department and when you return,
another letter is waiting, so you have to turn around and
walk all the way back to marketing again. And so on.
You could end up exhausted at the end of the day. So you get the idea to wait up
to an hour before delivering anything to marketing . . .if the marketing
folks are okay with receiving letters up to one hour late, then you only
have to walk over up to 8 times a day rather than continuously.
You save energy and you have time to do other things, and you
are not exhausted at the end of the day.
You can use the same technique to conserve power (battery life) in
embedded systems. Microprocessors are like people in
a way - if you don't ask them to do anything, they don't tire out (drain the battery)
as quickly. Running a local 5K race for charity requires more energy than watching
the Saturday Monster Garage Marathon. Your cell phone battery lasts a lot
longer when you don't make phone calls. Anything that is not really time critical
can be done less frequently to conserve power.
Embedded folks have special language to refer to
processors that are in "idle mode" or "sleep mode." These modes are pretty
self-explanatory; when the processor is in sleep mode, it's almost dead to the world.
It is not very aware of what is going around it, and as a consequence, it draws
very little power. But it has to "wakes up" regularly to check things out
and see if it has to do anything. If something important and unexpected happens,
the processor can be roused from sleep mode with a special interrupt.
In idle mode, the processor is awake and "listening" but may not doing much. In this
mode, it can respond to requests much more quickly but burns through batteries faster.
Software can save (or waste) battery life even when it's doing its normal job.
It depends on how efficiently it does its job.
Using the mail room example again: you might walk to marketing using a direct route,
or you might wander by the courtyard and the cafeteria each time because the view is nice.
But your manager might suggest that you take the stairs and walk through the dreary middle
of the building to get there faster. Same thing with embedded systems - you will end up at some
point rewriting parts of your code to run faster and more efficiently
so it isn't wasting power wandering through inefficient code. These software revisions
change no functionality, but are just to save battery life.
"Live long and prosper: juggling
performance and battery life in hand held systems" by Boris Donskoy, at EDN.com
An important part of designing embedded systems right the first time is to pay close
attention to the requirements. Not a favorite activity for most developers,
but embedded systems often have real-time constraints that are more
important that a flashy user interface and cool packaging.
Back to the mail delivery example. Maybe the folks in marketing
only open their department door every hour on the hour for just
60 seconds at a time. If you are a little late delivering the mail,
you have to wait another hour for the door to open again.
But what if they need that FedEx document RIGHT NOW?
You just failed a major "hard" timing requirement.
The "canonical definition of a real-time system"
(from Donald Gillies), is the following:
- "A real-time system is one in which the correctness of the
computations not only depends upon the logical correctness of the
computation but also upon
the time at which the result is produced. If the timing constraints of the
system are not met, system failure is said to have occurred." (Emphasis added.)
Let's talk about different TYPES of Time... Embedded engineers must assure not only
that the system performs as advertised, but that it guarantees timing
behavior - timing constraints can radically affect how the system must be designed. Below
are different TYPES of TIME that embedded engineers must handle...
(adopted from Agrawal and Bhatt) and
Ganssle.
- Hard real time: System responses must be within the deadline, late response means
system failure (e.g., medical equipment monitoring vital functions)
- Soft real time: Requirements based on average response time. Deadlines are important,
but still functions correctly with delay (e.g., airline reservations)
- Firm real time: Multiple definitions 1) soft real time, but no benefit from late
delivery, 2) shorter soft requirement and longer hard requirement, e.g., mechanical
ventilator can be few seconds late, but not more.
- Real real time: Hard real time with very short response time.
Embedded systems typically have significantly less memory than
regular computers. This places a challenge on the developers to
carefully plan how much memory is needed for the device, and to
make sure that the software is written efficiently in the available
space. While it may be tempting to just throw in a larger memory
chip, that drives up the total cost of the device and your company
makes less money for each one sold. Although some folks may say that
software is free because it is just ones and zeros, this simply is
not the case for price-critical embedded systems.
Many embedded systems must run for long periods of time without failure.
System reliability may be for safety
(pacemakers are turned on once and expected to run indefinitely),
remote access (a transmitter at the
top of a cell phone tower or attached to a whale for location tracking is more
difficult to service) or product life
(embedded systems in sneakers, some toys, and singing birthday cards are
not designed to be repaired).
With some devices, death could result in the time it takes to reboot the system.
Next time your computer presents the "[program name]
has detected an error and must close" message, think about what software you'd like running in the
navigation control unit during your next airline flight.
Okay, this sounds a little doom-and-gloom, but reliability is a major
consideration when designing, developing, and testing embedded systems.
And reliability is more than just ensuring that the system doesn't need
to be periodically rebooted; reliability refers to the selection of
appropriate parts (hardware and software), stress testing, life cycle testing
(simulating the wear and tear on a device during its entire life cycle),
and failure mode analysis (how does it fail, and what happens when it fails?).
For example, if your anti-lock
brakes fail, you'd expect that normal braking function will still perform without the
extra ABS feature. This is often referred to
as "failing gracefully" in which the
minimum functionality is retained.
Another example is my scuba diving
computer, which has some basic features that tell me how much air I have in my
tank and how deep I am. It can also compute how long I can stay at this depth
before I risk the bends, depending on what type of gas I am breathing
(e.g., regular air, air enriched with oxygen,
pure oxygen, helium and oxygen). If the computer fails or enters some type of
lockout mode, it is supposed to default to a "dumb" gauge and just provide
basic information: my depth and the air left in my tank. In this case, failure
mode will still give me the information I need to return safely to the surface.
Of course it may flood and stop working completely, but one reliability goal is
to have the device try to fail with at least some minimum functionality.
A major challenge in designing effective embedded systems is the user interface.
As users, we like consistency and intuitive interfaces, and we don't like
to read the manual. So the interface had better be pretty self-explanatory.
Most embedded systems do not have a Windows-like display. So designing a
custom display allows us to start with a blank slate and do whatever we want!
Use wild colors!
Put buttons in rows or in circles!
And use different colored LEDs to make it
flash like a Christmas tree!
Pick up several devices and look for common elements like ON/OFF
buttons. Since this is the first button you look for, it is generally
in a logical place. The ON button for all my remote controls is either
on the top right or the bottom right, and most of them are green
buttons to contrast the black ones. (Except TiVO. There is always the
exception...) Consistency teaches us to expect the ON button to be in a
similar place for other remotes and devices, and a check around my
house shows this to be true. While some actually say "On/Off," a trend
is towards the international symbol for the power ON/OFF switch:
An entire field of research and development focuses on the creation of appropriate
user interfaces. There are a lot of ways to do it correctly, and apparently even MORE ways to
screw it up. Since I am not an expert, but a student in the field of user
interfaces, I offer some humorous examples of
User Interfaces Gone Bad. If you let even
ONE person try your proposed user interface, you will receive valuable feedback.
|