Embedded Linux Primer 59
s1axter writes "Embedded system development is crucial in this day of high tech specialized appliances and devices. However much of the knowledge of embedded development resides in the heads of engineers who have been doing it for years. The hardware aspect of embedded systems is now available to the smaller startup companies, however many specialized, proprietary operating systems are not. This is where Linux and the book Embedded Linux Primer: A Practical Real-World Approach enters. Embedded Linux Primer is written to introduce engineers and designers to using the Linux operating systems for embedded applications." Read on for s1axter's review.
Prentice Hall's Embedded Linux Primer by Christopher Hallinan was published September 18th, 2006 as part of their Open Source Software Development Series. Very much like a textbook, Embedded Linux Primer is very informative and an excellent source of information for an engineer looking to enter or move to the embedded Linux field. The text is a decent size, with 537 pages spanning 17 chapters and 6 appendices; it retails for around $45 USD.| Embedded Linux Primer | |
| author | Christopher Hallinan |
| pages | 537 |
| publisher | Prentice Hall |
| rating | 9 |
| reviewer | s1axter |
| ISBN | 0-13-167984-8 |
| summary | A Practical Real-World Approach to Embedded Linux |
I had some reservations on reviewing a detailed technical book since most of the ones I have are dry and have a very segmented structure. However after taking a look at the sample chapter, chapter 7 "Bootloaders", available on the Prentice Hall website along with the table of contents for the text I figured I would give it a look and I am very glad I did.
Many technical books focus on a specific demographic in the technology world, mostly beginners or professionals expanding their knowledge base. I was quite pleased to see this text is written for both professional developers and emerging embedded engineers.
Professional engineers will find the text informative on the Linux operating system and how flexible it is to implement on even the most custom hardware. The author understands that a large number of embedded system engineers work with proprietary systems and explains items that might be new and different than these systems. For example Chapters 4-6 detail the Linux boot sequence and describe common pitfalls engineers new to the embedded Linux methodology might make. Chapters 8-11 dive further into the operating system and explain device driver creation, the important file system and how Linux handles volatile and non-volatile memory systems using the MTD subsystem.
Engineers starting in the field of embedded systems will find information on what an embedded system is in Chapter 1, processor and board comparisons in Chapter 2 and setting up an embedded environment for development in Chapter 12.
It is quite obvious throughout the text the author has an extensive in depth understanding of embedded systems and the inner workings of the Linux operating system. With such a deep understanding of the material an author many times explains items in such detail it clouds the mind of the reader. The first line in Chapter 2 says (paraphrasing) that the best way understand something is to understand the 'big picture' . This is exactly the approach the author takes through out the text, first explaining the theory and high level aspect of the system, then diving into the detail of how it is done on the low level. Also, rather than get sidetracked in chapters by explaining every processor attribute or software package, the author suggests external sources mid-text and in the "Suggestions for Additional Reading" at the end of each chapter.
For the first edition of a book, Embedded Linux Primer is rather complete, with the only exception being chapter 8, Device Driver Basics, which is...well, rather basic. I started the chapter expecting to finish with a detailed understanding of how the Linux kernel processes driver requests and a look into some common drivers. This is not the case; for a second edition of this text I would suggest beefing up this chapter to provide more of an insight into kernel-driver interaction.
Overall Embedded Linux Primer is an excellent source of information for both the seasoned professional and aspiring embedded engineer. I know that when I dive fully into the world of embedded Linux this book will have a permanent place on the bench right next to the spec sheets.
s1axter is the main poster for Geeksinside.com, which is a hardware hacking, technology blog that showcases projects, reviews and technical links.
You can purchase Embedded Linux Primer from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Embedded (Score:4, Interesting)
Re:Engineers doing it? Yeah, plenty of them. (Score:3, Interesting)
I will probably buy a book like this one to help me understand the issues. I have a little familiarity with low-level Unix workings, and it would be instructive to get an overview of the subject.
HW recommendations? (Score:3, Interesting)
I've seen a lot of embedded developer kits but I don't know where to start as none really list what kind of OS they'll support.
Any suggestions on HW would be welcome!
What is an embedded system? (Score:5, Interesting)
I do embedded systems for a living, and was asked this question during my intervuiew. My answer: "a system that is the brains of something else, and is not necessarily visible as a computer". They thought that was an interesting answer, and I got the job.
I think embedded systems are interesting. The challenge is obvious: it's easy to make a system with a multi-GHz processor, gigabytes of RAM and terabytes of disk do something interesting and/or useful. Can you make a computer the size of a stick of gum do something interesting and/or useful? That is the challenge.
The other challenge is that your embedded system must be reliable. People will not tolerate toasters that won't boot. The testing requirements can be interesting, and nerve-wracking too. How do you report "I'm broken" when all you can do is flash an LED?
This is where you get to find creative new abuses for mmap(), learn what those MTD device drivers in the kernel do, find just what JFFS2 will (and won't) do, and so on.
...laura, embedded Linux on 68k and StrongARM
Re:What is an embedded system? (Score:3, Interesting)
It's sometimes also stressful, if you made a bug it can cause the machine to break. I once was bug-hunting with half a factory looking over my shoulders because production had halted. You have to be able to stay calm then.
PS: to answer your question: learn morse
Re:Device Drivers issue (Score:2, Interesting)
I've been programming for a good 25 years now, and the one thing that goes through my head all the time is "Why is this stuff as baroque as it was 25 years ago?" It comes out in various forms, like "Why do I have to write yet another business app that's 99% identical to the last" and "Why in god's name did some Web 2.0 idiot have to invent yet another Smalltalk dialect?", but the underlying sentiment is the same.
The hardware has evolved by leaps and bounds, yet software is still blah. If I invent some neat little gadget that scratches an itch, I don't want to spend weeks teaching my PC how to talk to it. Ultimately, we're ferrying data back and forth. I don't care if it's a NIC, 3d accelerator, USB controller or god-knows-what, what they do with the data is very different, but getting it to/from the CPU/RAM should be consistent (in a pure-design technicolor dream). Quite frankly, I don't care if the bits get shipped over CAT5, DVI or a cheap dumb USB cable, once it leaves the FSB it becomes the peripheral's responsibility. If that means hardware manufacturers need to add a little front-end controller chip to their devices, in exchange for a dramatically simplified driver implementation, well... they're the hardware guys, it should be easy!