A piece of software that is independent of the processor on which it will be run. Most programs that can be written in a high-level language are processor-independent. Contrast with processor-specific. processor-specific A piece of software that is highly dependent on the processor on which it will be run. Such code must usually be written in assembly language. Contrast with processor-independent. profiler A software development tool that collects and reports execution statistics for your programs. These statistics include the number of calls to each subroutine and the total amount of time spent within each. This data can be used to learn which subroutines are the most critical and, therefore, demand the greatest code efficiency. program counter See instruction pointer. R RAM Random-Access Memory. A broad classification of memory devices that includes all devices in which individual memory locations can be read or written as required. RISC Reduced Instruction Set Computer. Describes the architecture of a processor family. RISC processors generally feature fixed-length instructions, a load-store memory architecture, and a large number of general-purpose registers or register windows. The MIPS processor family is an excellent example. Contrast with CISC. ROM Read-Only Memory. A broad classification of memory devices that includes all devices in which the individual memory locations can be read but not written. ROM emulator A debugging tool that takes the place of-or emulates-the ROM on your target board. A ROM emulator acts very much like a debug monitor, except that it includes its own serial or network connection to the host. ROM monitor See debug monitor. RTOS Real-Time Operating System. An operating system designed specifically for use in real-time systems. race condition A situation in which the outcome of a program can be affected by the exact order in which the instructions are executed. Race conditions are only an issue where interrupts and/or preemption are possible and where critical sections exist. real-time system Any computer system, embedded or otherwise, that has deadlines. The following question can be used to identify real-time systems: is a late answer as bad as, or even worse than, a wrong answer? In other words, what happens if the computation doesn't finish in time? If nothing bad happens, it's not a real-time system. If someone dies or the mission fails, it's generally considered "hard" real-time, which is meant to imply that the system has "hard" deadlines. Everything in between is "soft" real-time. recursive Refers to software that calls itself. Recursion should generally be avoided in an embedded system because it frequently requires a large stack. reentrant Refers to software that can be executed multiple times simultaneously. A reentrant function can be safely called recursively or from multiple tasks. The key to making code reentrant is to ensure mutual exclusion whenever accessing global variables or shared registers. register A memory location that is part of a processor or a peripheral. In other words, it's not normal memory. Generally, each bit or set of bits within the register controls some behavior of the larger device. relocatable A file containing object code that is almost ready for execution on the target. The final step is to use a locator to fix the remaining relocatable addresses within the code. The result of that process is an executable. reset address The address from which the first instruction will be fetched after the processor is powered on or reset. reset code A small piece of code that is placed at the reset address. The reset code is usually written in assembly language and might simply be the equivalent of "jump to the startup code." reset vector See reset address. S SRAM Static Random-Access Memory. A type of RAM that retains its contents as long as power is supplied to it. Data stored in an SRAM is lost when the system is powered down or reset. scheduler The part of an operating system that decides which task to run next. This decision is based on the readiness of each task, their relative priorities, and the specific scheduling algorithm implemented. semaphore A data structure that is used for intertask communication. Semaphores are usually provided by the operating system. simulator A debugging tool that runs on the host and pretends to be the target processor. A simulator can be used to test pieces of the software before the embedded hardware is available. Unfortunately, attempts to simulate interactions with complex peripherals are often more trouble than they are worth. software interrupt An interrupt that is generated by a software instruction. Software interrupts are commonly used to implement breakpoints and operating system entry points. Compare with trap. stack An area of memory that contains a last-in-first-out queue of storage for parameters, automatic variables, return addresses, and other information that must be maintained across function calls. In multitasking situations, each task generally has its own stack. stack frame An area of the stack associated with a particular function call. startup code A piece of assembly language code that prepares the way for software written in a high-level language. Most C/C++ cross-compilers come with startup code that you can modify, compile, and link with your embedded programs. T target Another name for the embedded system. This term is usually used during software development, to distinguish the embedded system from the host with which it communicates. task The central abstraction of an operating system. Each task must maintain its own copy of the instruction pointer and general-purpose registers. Unlike processes, tasks share a common memory space and must be careful to avoid overwriting each other's code and data. thread Another name for a task. This name is more common in operating systems that support processes. A task is simply a thread in a single-process system. tracepoint Similar to a breakpoint except that a counter is incremented rather than stopping the program. Tracepoints are not supported by all debugging tools. trap An interrupt that is generated by the processor's own internal hardware. For example, the processor might trap if an illegal opcode is found in your program. Compare with software interrupt. volatile A value that can change without the intervention of software is said to be volatile. For example, values within the registers of some I/O devices change in response to external events. C's volatile keyword should be used to warn your compiler about any pointers that point to such registers. This will ensure that the actual value is reread each time the data is used. W watchdog timer A hardware timer that is periodically reset by software. If the software crashes or hangs, the watchdog timer will expire, and the entire system will be reset automatically. Bibliography One of the most frustrating aspects of developing embedded software is that there are few references available. Many of the books that have been written are poor or out of print, and there are only a handful of periodicals dedicated to the subject. What follows is an annotated list of the books, magazines, and other resources I found most helpful in writing this book. This is not an attempt to itemize all of the relevant publications. In fact, I have specifically omitted several books and magazines that did not impress me. What's left is a list of books worth owning, magazines and conferences worthy of your time, and World Wide Web sites worth bookmarking. 12.1 Books Ball, Stuart R. Embedded Microprocessor Systems: Real World Design. Newton, Mass.: Butterworth-Heinemann, 1996. This tiny book is packed full of information about hardware design and embedded system development that every embedded software engineer should understand to be effective. Brown, John Forrest. Embedded Systems Programming in C and Assembly. New York: Van Nostrand Reinhold, 1994. It's a good thing I didn't know about this book a few years ago. If I had, I might not have tried writing my own. It is obvious to me that Mr. Brown and I had similar visions for our books. And since I have tried to stay away from assembly language as much as possible, this book would make an excellent companion to the one you are reading. Ganssle, Jack G. The Art of Programming Embedded Systems. San Diego: Academic Press, 1992. Some very practical advice from one of our industry's most vocal gurus. The author of a monthly column in Embedded Systems Programming (described later in this bibliography), Mr. Ganssle has helpfully collected some of his most lasting tips and rules of thumb in this book. A handy reference for topics that are too specific to be covered here. Kernighan, Brian W., and Dennis M. Ritchie. The C Programming Language. Englewood Cliffs, N.J.: Prentice-Hall, 1988. A concise explanation of C's syntax and semantics direct from the founding fathers. A necessary component of any programmer's bookshelf. Labrosse, Jean J. µC/OS: The Real-Time Kernel. Lawrence, Kans.: R & D Publications, 1992. A real-time operating system with source code and explanatory text-all for the price of a book. A great investment for someone who's thinking of writing their own operating system, or just looking for free source code. µC/OS (pronounced "micro-COS") has been ported to many processors and has a large user base. Rosenberg, Jonathan B. How Debuggers Work: Algorithms, Data Structures, and Architecture. New York: John P. Wiley & Sons, 1996. If you've ever wondered what a debugger looks like on the inside, this book is for you. It will also give you a better understanding of the split between debugger and debug monitor and the potential for interference between the debugger and your programs. Satir, Gregory, and Doug Brown. C++: The Core Language. Cambridge, Mass.: O'Reilly & Associates, 1995. An excellent introduction to C++ for competent C programmers. If you don't already have a C++ book that you like, try this one. Van der Linden, Peter. Expert C Programming: Deep C Secrets. Englewood Cliffs, N.J.: Prentice-Hall, 1994. Written by a member of Sun Microsystems' compiler development team, this book helps to fill the gaps in knowledge between an ordinary C programmer and a guru. Although not entirely necessary, an understanding of these advanced topics can only make you a better embedded programmer. This book is an excellent reference as well as an entertaining read. Van Sickle, Ted. Programming Microcontrollers in C. Solana Beach, Calif.: HighText Publications, 1994. Like many of the embedded programming books that I've found, this one is specific to a particular processor family. However, because the book is well written and Motorola's microcontrollers are quite popular, some readers will still find it useful. 12.2 Magazines and Conferences Embedded Systems Programming A monthly publication devoted specifically to the issues embedded software developers face on the job. Every article and column is packed with practical advice and written in a casual style familiar to readers of this and other Nutshell Handbooks. I highly recommend that everyone reading this sentence immediately put my book down and take a few minutes to sign up for a free subscription at http://www.embedded.com/mag.shtml. It usually takes several months to get going, but is well worth the wait. In addition, you might want to purchase a copy of the CD-ROM archive. This searchable database contains hundreds of past articles and columns and was an indispensable reference in the creation of this book. More information is available at http://www.embedded.com/cd.htm. Embedded Systems Conference A technical conference hosted several times each year by the publishers of the magazine just described. The conference has been running for about 10 years, and the number of exhibitors and attendees continues to grow each year. The knowledge to be gained here far outweighs the cost of traveling to the conference and attending the classes. I try to go as often as I can. Chip Directory (http://www.hitex.com/) An unbelievably large collection of information about common processors and peripherals. This is not the only such site on the Web, but it is one of the best maintained and it has links to many of the others. CPU Info Center (http://bwrc.eecs.berkeley.edu/CIC/) Tons of information about new and old processors alike. Includes a section specifically about common embedded processors. CRC Pitstop (http://www.ross.net/crc/) A site dedicated to information about CRC implementation, including Ross Williams' "Painless Guide to CRC Error Detection Algorithms." The latter is the most readable explanation of CRC calculations I've ever found. Electronic Engineers' Toolbox (http://www.eetoolbox.com/ebox.htm) Focused on embedded systems, real-time software development issues, and Internet-enabling technologies, the "EE Toolbox" is designed to make your job easier. The publishers of this site have identified, indexed, and summarized thousands of relevant Internet resources and brought them all together in one place. Embedded Intel Architecture (http://www.intel.com/design/intarch/) Intel's home page for their embedded processor line, including the 80188EB. In addition to technical information about the hardware, there are also free development and debugging tools and example source code listings. news:comp.arch.embedded A newsgroup devoted to many of the topics discussed in this book. Discussions frequently involve software development tools and processes, comparisons of commercial real-time operating systems, and suggestions for processor selection criteria. news:comp.realtime Another good newsgroup for embedded systems discussion. This one tends to focus more heavily on real-time scheduling issues, however, so not all of the information is relevant. A list of FAQs from this group can be found at http://www.faqs.org/faqs/by-newsgroup/comp/comp.realtime.html. Colophon Our look is the result of reader comments, our own experimentation, and feedback from distribution channels. Distinctive covers complement our distinctive approach to technical topics, breathing personality and life into potentially dry subjects. The insects on the cover of Programming Embedded Systems in C and C++ are ticks. There are approximately 850 species of these small to microscopic, blood-feeding parasites distributed worldwide. They are particularly abundant in tropical and subtropical regions. There are two main families of ticks: hard ticks, whose mouth parts are visible from above, and soft ticks, whose mouth parts are hidden. In both hard and soft ticks, the mouth is made up of three major parts: the palps, the chelicerae, and the hypostome. It is the hypostome that is inserted into the host's skin while the tick is feeding. A series of backward-facing projections on the hypostome make it difficult to remove the tick from the skin. Most ticks also secrete a sticky substance that glues them into place. This substance dissolves when the tick is done feeding. Their external body surface expands from 200 to 600 percent to accommodate the blood that is ingested. Ticks go through three life stages: larva, nymph, and adult. At each stage they feed on a mammal, reptile, or bird host. Ticks wait for a host by perching on leaves or other surfaces with their front two legs extended. When a host brushes up against them they latch on and attach themselves. Adult female hard ticks lay a single batch of thousands of eggs and then die. Adult male ticks also die after a single mating. As parasites go, ticks can be very nasty. They transmit more disease than any other blood-sucking parasite, including Lyme disease, Rocky Mountain spotted fever, and relapsing fever. They can also cause excessive blood loss. Some ticks secrete nerve poisons that can potentially cause death. A tick can be removed from skin by grasping it with a tweezer or a special tick-removing device as close to the skin as possible, and pulling in one steady motion. Do not squeeze the tick. Immediately flush it down the toilet-or place it in a sealed container and hold onto it for one month, in case you develop symptoms of a disease. Melanie Wang was the production editor and proofreader for Embedded Programming Systems in C and C++. Sheryl Avruch was the production manager; Paulette A. Miley was the copy editor; Nancy Kotary and Madeleine Newell provided quality control. Seth Maislin wrote the index. Edie Freedman designed the cover of this book, using a 19th-century engraving from the Dover Pictorial Archive. The cover layout was produced with QuarkXPress 3.3 using the ITC Garamond font. The inside layout was designed by Edie Freedman and implemented in FrameMaker by Mike Sierra. The text and heading fonts are ITC Garamond Light and Garamond Book. The illustrations that appear in the book were created in Macromedia Freehand 7.0 by Robert Romano. This colophon was written by Clairemarie Fisher O'Leary. . into potentially dry subjects. The insects on the cover of Programming Embedded Systems in C and C+ + are ticks. There are approximately 850 species of these small to microscopic, blood-feeding parasites. best maintained and it has links to many of the others. CPU Info Center (http://bwrc.eecs.berkeley.edu/CIC/) Tons of information about new and old processors alike. Includes a section specifically. learn which subroutines are the most critical and, therefore, demand the greatest code efficiency. program counter See instruction pointer. R RAM Random-Access Memory. A broad classification of