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. V 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. 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. . 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. 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. 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