Embedded software is in almost every electronic device designed today. There is software hidden away inside our watches, microwaves, VCRs, cellular telephones, and pagers; the military uses embedded software to guide smart missiles and detect enemy aircraft; communications satellites, space probes, and modern medicine would be nearly impossible without it. Of course, someone has to write all that software, and there are thousands of computer scientists, electrical engineers, and other professionals who actually do.

Each embedded system is unique and highly customized to the application at hand. As a result, embedded systems programming is a widely varying field that can take years to master. However, if you have some programming experience and are familiar with C or C++, you're ready to learn how to write embedded software. The hands-on, no-nonsense style of this book will help you get started by offering practical advice from someone who's been in your shoes and wants to help you learn quickly.

The techniques and code examples presented here are directly applicable to real-world embedded software projects of all sorts. Even if you've done some embedded programming before, you'll still benefit from the topics in this book, which include:

• Testing memory chips quickly and efficiently

• Writing and erasing Flash memory

• Verifying nonvolatile memory contents with CRCs

• Interfacing to on-chip and external peripherals

• Device driver design and implementation

• Optimizing embedded software for size and speed

So whether you're writing your first embedded program, designing the latest generation of hand-held whatchamacalits, or simply managing the people who do, this book is for you.

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 43 Ratings

Over-rated - 2006-06-17
Reviewer Rating:
"But keep in mind, it is extremely superficial. In other words, it's a great introduction for people who have no idea whatsoever what embedded development involves." This is a quote from a reviewer that gave it 5 stars. I agree with this reviewer comments but don't buy a book you will outgrow before you finish reading it! For now, I still recommend the David E. Simon book.

Promptly returned ... - 2006-10-06
Reviewer Rating:
In agreement with an earlier reviewer who also gave this book 1-star rating, it took me about 10 minutes of going through this relatively thin book to realize that its contents was not substantive (at all). Too much hand-waving, and not nearly enough meat. And there's barely any C or C++ code in the book.

Not so good - 2007-07-26
Reviewer Rating:
I'm new to embedded system programming so I bought this book. I was disappointed because I didn't get much from this book. Buy something else.

Excellent - 2006-08-07
Reviewer Rating:
I am curious for the meaning of "advanced users" and what they would enjoy on a "advanced book" and why they despise this book for its basic content, And perhaps, they are after a title like "do my work". I guess much of the material here is very important to embedded developers, being experienced or not. For ex, start up code, the memory initializations and the excellent introduction to a RTOS. I am an Electrical Engineer, always writting embedded application code ( mostly dealing with API calls when it comes to low level ) and I was looking for clarification of several issues and the book did it well. Have a manual for your processor, your compiler and it will be all that you will need. Tips for embedded applications might be easily found on application notes ( be it ARM based processors or AVRs or Freescales ). This book is about writting the software not about the applications them selves.

Friendly introduction book - 2009-06-04
Reviewer Rating:
Even though the book does not render enough details in almost every topic it touched, it still manages to be an very interesting read. For example, the following paragraph is all it talked about context switch, concise yet inspiring, that's why I gave it 4 stars.

8.2.3 Context Switch
The actual process of changing from one task to another is called a context switch. Because contexts are processor-specific, so is the code that implements the context switch. That means it must always be written in assembly language. Rather than show you the 80x86-specific assembly code that I used in ADEOS, I'll show the context switch routine in a C-like pseudocode:

void
contextSwitch(PContext pOldContext, PContext pNewContext)
{
if (saveContext(pOldContext))
{
//
// Restore new context only on a nonzero exit from saveContext().
//
restoreContext(pNewContext);

// This line is never executed!
}

// Instead, the restored task continues to execute at this point.
}
The contextSwitch routine is actually invoked by the scheduler, which is in turn called from one of the operating system calls that disables interrupts. So it is not necessary to disable interrupts here. In addition, because the operating system call that invoked the scheduler is written in a high-level language, most of the running task's registers have already been saved onto its local stack. That reduces the amount of work that needs to be done by the routines saveContext and restoreContext. They need only worry about saving the instruction pointer, stack pointer, and flags.

The actual behavior of contextSwitch at runtime is difficult to see simply by looking at the previous code. Most software developers think serially, assuming that each line of code will be executed immediately following the previous one. However, this code is actually executed two times, in pseudoparallel. When one task (the new task) changes to the running state, another (the old task) must simultaneously go back to the ready state. Imagine what the new task sees when it is restored inside the restoreContext code. No matter what the new task was doing before, it always wakes up inside the saveContext code-because that's where its instruction pointer was saved.

How does the new task know whether it is coming out of saveContext for the first time (i.e., in the process of going to sleep) or the second time (in the process of waking up)? It definitely does need to know the difference, so I've had to implement saveContext in a slightly sneaky way. Rather than saving the precise current instruction pointer, saveContext actually saves an address a few instructions ahead. That way, when the saved context is restored, execution continues from a different point in the saveContext routine. This also makes it possible for saveContext to return different values: nonzero when the task goes to sleep and zero when the task wakes up. The contextSwitch routine uses this return value to decide whether to call restoreContext. If contextSwitch did not perform this check, the code associated with the new task would never get to execute.

Browse Similar Topics

Top Level Categories:
Programming

Sub-Categories:
Programming > C
C > Embedded
Programming > C++