|
|||
In embedded software, a microprocessor is incorporated into a custom device, and much of the functionality of the device is implemented as code executing on that microprocessor. This is done for three reasons: it provides the ability to implement things which couldn't be done with discrete hardware, the resulting system is more adaptable to customer needs, and the software portion of the system can be manufactured for negligible money and as a result it has a huge markup over manufacturing cost because it still provides a great deal of perceived value to the user. The downside is that you have to hire all those hippies who wear jeans to work and wear headphones listening to rock music while they type strange unreadable gibberish. Oh, for the good old days of white shirts and black ties. One of the reasons the field is invisible is that people have come to take intelligent devices for granted, and don't even realize any more all the places that microprocessors are used. They are everywhere because the vast majority of microprocessors manufactured each year cost only a buck or two. Nearly anywhere that any kind of control is needed, it is simply easier to do it with software. So there's probably a couple in your washing machine; one in your dish washer, one in your microwave oven; there may even be one in your refrigerator. You've got at least two in your cell phone; and there may be as many as five in your car. Your computer keyboard contains one; there's one in your monitor; there's one in your mouse; each disk drive you own contains one; and in other places inside your computer there could be as many as ten others in addition to the big one you know about. There's at least one in your TV and one in every stereo component you own, and one in every remote control you use. Nearly everything which has push buttons on it has a computer reading those buttons. The distinguishing characteristic of embedded software is that it is small. The processors are tiny and slow and memory is very restricted. All of these things are done to shave manufacturing cost. The microprocessor which controls your microwave oven is probably only 8 bits with a total of 64K of memory including both ROM and RAM, and it may only have a 50 MHz clock rate, if that. (If the device is battery powered, the processor almost certainly has a very slow clock rate, because high clock rates burn batteries.) Over a career in embedded software extending back to 1974, I have only once worked with a processor which had more than 2 MB of memory total, and I've never programmed an embedded processor faster than 100 MHz. Most of them were much smaller than that; the smallest I ever programmed had a total of 3K of ROM and 256 bytes of RAM, running at 5 MHz. (It was controlling a tape drive.) The vast majority of embedded software uses what are called "microcomputers" because they are completely self contained. You feed it power on one pin; a clock on another; and connect a couple of pins to ground. Every other pin on the chip is used for I/O. All the memory and everything else is completely self contained on the chip. (This can make debugging rather exciting since you can't directly tell what the processor is doing except by observing the I/O it performs.) Over the course of 25 years in this field, the one thing I have learned beyond all others is this: non-embedded programmers don't have the faintest idea what we embedded programmers really do. Occasionally one of them with a computer religion notices all of us grinding away in our holes twiddling bits and hammering iron, and decides to save our souls by converting us to computer-religion-du-jour. He joyfully informs us about how his shining star of an idea is going to change our world -- and every time this has happened to me it's turned out to be something which was completely, totally useless. What we are doing is so much different from what other programmers do that it is nearly an entirely separate engineering field. Some tools are common and a bit of basic theory applies to both (i.e. we both use linked lists) but at any level above that it is completely separate. When Java first hit the screen (with a splat) one of the places that Sun decided it was going to be a big hit was in embedded software. They worked hard and came up with a lean-and-mean run time machine which "only" required 3.5 MB of storage. That was just for the JVM, before you started adding user code. (It also required about 512K of RAM for overhead before you got to application storage.) At that time I was working on state-of-the-art cell phones, and our phone had a 
| |||