Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Embedded Linux Primer

samzenpus posted more than 7 years ago | from the read-all-about-it dept.

Book Reviews 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.

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.

cancel ×

59 comments

This is a book (1, Funny)

stratjakt (596332) | more than 7 years ago | (#19584659)

Consisting of lost of pages, many of them with interesting facts and diagrams.

I highly recommend this to both the hobbyist and the seasoned professional!

I dont know how to do referral links so just give me money directly thanks k bye

Re:This is a book (0)

Anonymous Coward | more than 7 years ago | (#19584795)

Sure you might learn all sorts of things about embedded linux systems, but will it make your penis larger or help satisfy your wife? WHAT OF YOUR MORTGAGE?!?!? How does it help you become a better person, and a superior toaster salesman? Will this book teach you the fine art of Origami? Important questions need important answers!

Re:This is a book (0)

Anonymous Coward | more than 7 years ago | (#19585355)

What is there to know about embedded Linux or any other type of Linux? All you need to know the the open sores software infringes on the property of poor old Microsoft. Microsoft needs the money than those hippies that work on Linux, especially has the hippies will just spend the money on drugs and discuss why they hate America.

Just adopt Windows as your embedded system. It doesn't infringe on anyone's [wikipedia.org] property and is completely secure [wikipedia.org] .

Sounds promising. (1)

jshriverWVU (810740) | more than 7 years ago | (#19584701)

Looks like a good book. I've dabbled in embedded systems before. For anyone who has had reflashed their router with DD-WRT or think programming your toaster could be fun, this could be a good read.

Re:Sounds promising. (2, Funny)

jimstapleton (999106) | more than 7 years ago | (#19584771)

I ran NetBSD on my toaster! But the edges of the windows started getting black and crispy, so I went back to just using it for toast...

And NetBSD isn't Linux, but you did mention running things on toasters.

Re:Sounds promising. (1)

eneville (745111) | more than 7 years ago | (#19586711)

Looks like a good book. I've dabbled in embedded systems before. For anyone who has had reflashed their router with DD-WRT or think programming your toaster could be fun, this could be a good read.
i've always expected embedded linux to require a lot of kernel experience. i chatted to someone at the linux expo a few years ago, and they were mainly interested in the porting of the kernel to a risc processor. i'm not sure what their end goal was once they could get their risc system to work, but i'm sure it's got a lot of applications.

personally i've wanted to make a huge port router, something like a 48 port beast, but getting that on a system with enough irqs is hard. the best i can get is 8, and that's using epia systems, and not really embedded.

Re:Sounds promising. (1)

billcopc (196330) | more than 7 years ago | (#19589209)

I must be missing some important detail here: how is a 48-port router any different from, say, a regular router with a 48-port switch ? Do you really need an IRQ for each port ? Don't they use "switch fabric" for those things ? Hypercube-style topology or the like.

Re:Sounds promising. (1)

eneville (745111) | more than 7 years ago | (#19600735)

I must be missing some important detail here: how is a 48-port router any different from, say, a regular router with a 48-port switch ? Do you really need an IRQ for each port ? Don't they use "switch fabric" for those things ? Hypercube-style topology or the like.
yes it's possible, no, but it's something i've wanted to do for a long time... i just want to make a single, all contained device that has proper dedicated ports. the switch fabric has a single point of contention, using dedicated ports means the hardware at the card can handle the buffers and all the magic.

Re:Sounds promising. (0)

Anonymous Coward | more than 7 years ago | (#19589279)

radioshack has extra irqs on discount this month!

Engineers doing it? (0)

Anonymous Coward | more than 7 years ago | (#19584733)

much of the knowledge of embedded development resides in the heads of engineers who have been doing it for years.
I know lot's of engineers, and most of them have never done it, much less "been doing it for years."

Re:Engineers doing it? (0)

Anonymous Coward | more than 7 years ago | (#19584817)

much of the knowledge of embedded development resides in the heads of engineers who have been doing it for years.
I know lot's of engineers, and most of them have never done it, much less "been doing it for years."
Nowhere does it say that most engineer's have knowledge of this. It says most knowledges that does exist is in the heads of engineers.

Re:Engineers doing it? Yeah, plenty of them. (2, Interesting)

mollog (841386) | more than 7 years ago | (#19584899)

Dood, where I work they have been porting a *nix OS to printers for years, like 10 years. It's voodoo and the results are often spooky. It's actually pretty cool to be able to use typical Unix commands to work in the printer's OS. I work in the test department and we spend a lot of time logging in and working on the printer. I can compile new 'firmware' and load it when I need to, and I have sometimes looked at the source for failure analysis reasons.

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.

I bet! (3, Funny)

iknownuttin (1099999) | more than 7 years ago | (#19585103)

It's voodoo and the results are often spooky.

I bet! Do you get a lot of zombie processes?

And how many chickens do you guys kill per port?

Re:Engineers doing it? Yeah, plenty of them. (0)

Anonymous Coward | more than 7 years ago | (#19586733)

Dood, where I work they have been porting a *nix OS to printers for years, like 10 years. It's voodoo and the results are often spooky. It's actually pretty cool to be able to use typical Unix commands to work in the printer's OS. I work in the test department and we spend a lot of time logging in and working on the printer. I can compile new 'firmware' and load it when I need to, and I have sometimes looked at the source for failure analysis reasons.
My friend, you are a shining example of someone who has never done it, and, in all likelihood, never will do it.

(in case you missed it, we're talking about women here...)

primer (1, Funny)

Anonymous Coward | more than 7 years ago | (#19584737)

Sweet. I'll head down to Home Depot after work and see if they have any.

Breaking Linux news: (0, Troll)

PurifyYourMind (776223) | more than 7 years ago | (#19584767)

I just pooped my cute little pants.

Why worry about embedded driver development? (4, Insightful)

Weaselmancer (533834) | more than 7 years ago | (#19584809)

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.

Embedded or not, Linux uses the same driver structure. Most often, the same drivers as well. That's the main advantage of "embedded" Linux - it's no different than any other Linux. Just smaller. Try running a Windows XP program on Windows CE to see what I mean.

If you want to chase driver development, read Linux Device Drivers [oreilly.com] , by O'Reilly. It's IMHO the definitive book, and works just the same for embedded Linux. A single chapter in an embedded how-to book could hardly be expected to capture everything you'd need.

Re:Why worry about embedded driver development? (3, Informative)

tzanger (1575) | more than 7 years ago | (#19585189)

If you want to chase driver development, read Linux Device Drivers, by O'Reilly. It's IMHO the definitive book, and works just the same for embedded Linux. A single chapter in an embedded how-to book could hardly be expected to capture everything you'd need.

I didn't like this book; it stuck to basic network, char and block devices, and while it provided a good deal of detail on these, it completely avoided actual hardware interfacing: PCI (e/x too), PCMCIA, USB, basic memory/interrupt allocation, etc. Unfortunately, those are the trickier bits to driver writing.

Re:Why worry about embedded driver development? (1)

wellingj (1030460) | more than 7 years ago | (#19587139)

Well you could look at someone else's code...

Re:Why worry about embedded driver development? (1)

tzanger (1575) | more than 7 years ago | (#19595443)

That's what I ended up doing, and I got it to work, although I can't say I fully understand all of the details yet. the PCMCIA system is in an enormous state of flux, and the code is the only place you can really look. I spent a lot of time going through lxr.linux.no, but some documentation would have been helpful.

Re:Why worry about embedded driver development? (0)

Anonymous Coward | more than 7 years ago | (#19587553)

I agree. I looked at the book the other day, and it was crap. Few examples, and only a cursory touch on PREEMPT_RT. Note to everyone: If your embedded system ain't real-time, you have no business praising this book.

Real-time Linux has grown cold and dead as Anna Nicole. Blame WindRiver for buying out the RTLinux patents.

Embedded (4, Interesting)

HomelessInLaJolla (1026842) | more than 7 years ago | (#19584863)

The smallest Linux computer in the world: Picotux! [picotux.com]

Re:Embedded (1)

$RANDOMLUSER (804576) | more than 7 years ago | (#19585075)

OMFG!! That is just adorable! Thanks!

Re:Embedded (2, Informative)

belphegore (66832) | more than 7 years ago | (#19587017)

The gumstix is smaller. At 80x20x6mm the gumstix is 9600 cubic mm. The picotux at 35x19x19mm is 12635 cubic mm, or more than 30% larger than a gumstix. It's also not a linux device, but rather a uclinux device, which is not the same thing.

MOD PARENT DOWN (0)

Anonymous Coward | more than 7 years ago | (#19603921)

I'm sick of seeing this troll continuously modded up. Since most of you haven't noticed, he trolls in cycles. First starting out posting short, but relevant, posts such as above. If he gets in early enough, it's always an automatic +5. Once his karma gets back to the positives, he then starts trolling again. Topics generally include, conspiracies of the government, large corporations, or some form of both. He always oversteps himself and gets called out, resulting in his karma substantially dropping. Then the cycle repeats...

Routers, Phones, Now What? (1)

Cygfrydd (957180) | more than 7 years ago | (#19584989)

Am I the only one that read that subject, initially, as "Embedded Linux Printer"? Not that that's a totally uncool idea, now that I'm thinking about it...

@yg

Re:Routers, Phones, Now What? (1)

GreenEnvy22 (1046790) | more than 7 years ago | (#19585153)

I did too.

Re:Routers, Phones, Now What? (1)

jeevesbond (1066726) | more than 7 years ago | (#19585341)

Am I the only one that read that subject, initially, as "Embedded Linux Printer"?

Me too, although I wouldn't be suprised if there isn't some Postscript, network printer out there that runs embedded Linux...

Well here it is, a quick Scroogle search finds: Red Hat's Open Source Embedded OS to Power Post-PC Printer Device From Brother [findarticles.com] .

Embedded Linux? No thanks. (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19585031)

I'm waiting for Apple to release their embedded version of OS X. It is going to be much faster, more secure, and will be written and supported by domestic engineers, rather than foreigners and illegal immigrants.

Think Better. Think Different. Think Apple.

Re:Embedded Linux? No thanks. (1)

jshriverWVU (810740) | more than 7 years ago | (#19585137)

While your post was trollish. There is an embedded form of OS X/darwin. What do you think powers the iPhone. :)

Re:Embedded Linux? No thanks. (0)

Anonymous Coward | more than 7 years ago | (#19585143)

You are obviously trolling, so here's a countertroll reply:
Basically OSX embedded would be BSD with a different kernel, which is what you get when stripping the GUI out of it. We already have these products; they're open+free (which OSX is not) and they support a plethora of hardware that OSX would only dream of.

Re:Embedded Linux? No thanks. (2)

bvankuik (203077) | more than 7 years ago | (#19585369)

A lot of people will see EMBEDDED and think ooh scary! But nowadays there are very cheap $100 small boards with enough ram and flash to code in plain old C. This stuff has come so far that these boards are NOT a big step from desktop programming.
 
Just a reminder.

Re:Embedded Linux? No thanks. (1)

revengebomber (1080189) | more than 7 years ago | (#19586071)

Bah, I remember when $100 wouldn't even get you a line printer. Get off my lawn!

Re:Embedded Linux? No thanks. (1)

scroby (1097383) | more than 7 years ago | (#19588299)

you need a $100 board to program in C? The Atmel AT90USBKey is $30, needs no additional hardware and has more than enough ram & flash to program in C. There's also plenty of other small 8Bit development boards out there, for much less than $100, that will easily handle a good chunk of compiled C.

Ammunition? (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#19585427)

Am I the only one who read "primer" and immediately wondered what Linux had to do with ammunition?

...oh, so I am then... nevermind.

Linux is too heavy (0)

Anonymous Coward | more than 7 years ago | (#19585627)

For most 4-, 8-, and 16- bit microcontrollers... In those cases, it's best to just do things yourself...

Re:Linux is too heavy (1)

ClosedSource (238333) | more than 7 years ago | (#19587355)

I agree. Traditional OS's aren't the best choice for true embedded systems, but if what you're really building is a general purpose computer in a smaller form-=factor, they make sense.

Device Drivers issue (3, Informative)

MrCopilot (871878) | more than 7 years ago | (#19585855)

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

Detailed understanding requires a whole bookshelf, and several years hacking away at a couple of drivers, but here is a good start.
http://lwn.net/Kernel/LDD3/ [lwn.net]

Re:Device Drivers issue (2, Interesting)

billcopc (196330) | more than 7 years ago | (#19589533)

I hope I'm not alone when I ask: Why does it have to be so complicated ?

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!

Re:Device Drivers issue (1)

MrCopilot (871878) | about 7 years ago | (#19622795)

OK, OK , OK. relax, deep breathe.

You are welcome to use any standard you like, its not so complicated. Serial Data over rs232 still works great. Hell zigbee wireless emulates rs232 behavior even over usb. It's not as complicated as it sounds. Now you want to talk in the kernel. Then you have to think "in the kernel". And that can be complicated, it is documented, but you cannot expect to just get it.

elinux.org (4, Informative)

embill (551301) | more than 7 years ago | (#19585877)

Great review and great book. Just wanted to also point out that http://www.elinux.org/ [elinux.org] (a site I edit) is a fantastic wiki for information regarding embedded linux and it's only getting better. We recently merged content from elinux.org (the original) and the CELF Public Wiki. Also, the wiki will be relaunched officially at OLS.

HW recommendations? (2, Interesting)

ChilyWily (162187) | more than 7 years ago | (#19586067)

Does this book supply any HW recommendations? For me that has been one of the stumbling blocks... what architecture, what device, how much memory etc. to get going.

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!

Re:HW recommendations? (3, Informative)

JustForMe (863749) | more than 7 years ago | (#19586305)

You are better off the other way around. Pick your developer kit (based on the processor, memory, peripherals etc.). Then pick any RTOS that has support for the processor. This way, you can skip learning the boot code for the processor (or, what they call the board support package). If you plan to go with Embedded linux, I would recommend to go through a boot loader like U-BOOT. If U-BOOT supports the processor on your developer kit, you are good to go. Assuming you can get the cross compiler (build tools) for building linux image for the processor. Enjoy :)

Re:HW recommendations? (2, Informative)

wellingj (1030460) | more than 7 years ago | (#19587347)

I recommend Gumstix [gumstix.com] for beginners.
It uses U-Boot and the whole uClibc [uclibc.org] BusyBox [busybox.net] Buildroot [uclibc.org] stack for development.
It is rather slick to work with. They even added support for the rt patch not too long ago which was a big bonus for me.
I've been working with it for about a year now and I have to say it's really the best solution for embedded Linux beginners.

Re:HW recommendations? (1)

j.boulton (661381) | more than 7 years ago | (#19586983)

Can't go past a gumstix (http://gumstix.com/) for a open embedded linux platform.

Here you go (1)

geekoid (135745) | more than 7 years ago | (#19588917)

http://www.atmel.com/dyn/products/tools_card.asp?t ool_id=4102 [atmel.com]

click on the AVRfreaks wiki link for advice on exactly what to do to get started.

at 75 bucks, it is one of the cheapest kits you can get. If I am not mistaken you can download all the software for free.

Or find a embedded engineers PUG and talk to them. Someone might set you up with something they don't use anymore.

Won't GPL3 kill embedding? (0, Flamebait)

harryjohnston (1118069) | more than 7 years ago | (#19586247)

Won't GPL3 pretty much kill embedded Linux? Richard Stallman has said one of the design criteria of GPL3 was to prevent "Tivoisation", i.e., embedding.

(Granted I gather there are no plans to GPL3 the Linux kernel, so as long as you aren't using any of the GNU components I guess you'd still be OK.)

Re:Won't GPL3 kill embedding? (1)

doti (966971) | more than 7 years ago | (#19586783)

Tivoisation doesn't mean "no embedding", instead it's more like "no need of a hardware key to run".

Re:Won't GPL3 kill embedding? (1)

stratjakt (596332) | more than 7 years ago | (#19586953)

Your post makes me wonder about all this coming mess of more license bullshit.

I set up an embedded tivo-like device. The kernel needs a hardware key to boot. This is ok, the kernel is still v2.

So, once past that and booted, its full of gnu tools, and other GPL3 stuff.

Those tools dont require any hardware key. GCC needs no key. It's stock, and I happily ship the source, etc. Does GPL3 invalidate me using it now? Does the license have that much reach, basically saying "you cant use this software on certain types of hardware?"

I'd almost rather figure out MS licensing v9.0 or whatever the fuck they have now.

What is an embedded system? (4, Interesting)

spaceyhackerlady (462530) | more than 7 years ago | (#19587297)

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? (2, Interesting)

Mr2cents (323101) | more than 7 years ago | (#19588179)

I write embedded software for industrial machines. It is fascinating. When you run your software and see a machine come to life, it's thrilling. Also, I get to see the insides of lots of machinery, it's like hacking but with a direct line to the company's engineers :).

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:What is an embedded system? (1)

spaceyhackerlady (462530) | more than 7 years ago | (#19589585)

PS: to answer your question: learn morse :).

In a current project I found myself with a sufficiently flexible LED interface (because I designed it :-) that I could do exactly that. And that's what it does. It's not Linux, but Brew is so bizarrely idiosyncratic that it must count for something.

The other thing with embedded stuff is you have to get it right, because the code is going to be burned in to lots of devices that are going to go out in the field, and you can't get them back if you goof.

...laura

Re:What is an embedded system? (1)

Mr2cents (323101) | more than 7 years ago | (#19601577)

I just spent the whole evening writing a morse translator :). It works with my keyboard led, tomorrow I'll compile it on an ARM.

The idea has been nagging me for ages :).

BTW, I've never heard of brew before, so I looked it up. Is it any good? My gut feeling tells me it's more marketing than software, but that's just by looking at the website.. I could be completely wrong.

Re:What is an embedded system? (1)

spaceyhackerlady (462530) | more than 7 years ago | (#19602995)

Brew suffers from the usual cell network security paranoia, and specifications written by lawyers. It's really one for the pros - Qualcomm make it just about impossible for a hobbyist to do anything with Brew on real hardware. Any schmuck can download the SDK and play with the emulator, but that's as far as you can go unless you're a company.

At runtime, Brew apps are reminiscent of really old Windows apps (i.e. completely event driven), but with non-blocking I/O to make things interesting. What looks like a function call, like ISocket_Write(), just starts the operation; you have to check back later (or register a callback) to find out what really happened.

...laura

Re:What is an embedded system? (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#19590649)

...Marry me.

Re:What is an embedded system? (1)

s-gen (890660) | more than 7 years ago | (#19592397)

I was asked "What is the embedded equivalent Hello World?" -- my answer "Hello LED" went down fine.

Good Embedded Linux Starter Kit (2, Informative)

az1324 (458137) | more than 7 years ago | (#19587747)

Atmel has put out a nice and cheap (80 bucks!!) kit called NGW100 for developing embedded linux devices on their AVR32 series. There is a lot of open community support around it and it seems like a great place to start. I've been thinking about getting into embedded linux for a while.

Am reading the book now (2, Informative)

iksrazal_br (614172) | more than 7 years ago | (#19588883)

I'm on a project building a router using the freescale mpc8548e on a custom board - a pretty powerful processor for embedded work. This is my first embedded project, though I'm a long time linux user and had an early career doing primarily electronics work.

This book is uneven, but largely its a good book. The bootloader chapters are a very good intro - it even has a porting section going into the ppc assembly part of u-boot. The init sections of the kernel are also a good intro. The chapter describing gdb and kernel debugging is good, as I learned several tricks using macros with gdb that I think will help me a lot. Lots of tools like cpp are explained that I didn't know about.

However, where it comes short is that I still really need help with early debugging the bootloader and kernel init using the bdi-2000 (a hardware debugger that connects to the jtag interface that most boards have). It barely mentions the bdi-2000, which is a fundamental tool as its pretty much the only way to debug very early booting problems when porting.

I also think the flash section has too much of a jffs2 focus, and not ext2 focused to match most users. The driver section is very module focused and so bare it could be omitted.

Overall, I'm happy with the book in that it does have a lot of info that I haven't found elsewhere. It really convinced me I need to read the manuals of my hardware more as there is no alternative. The book has helped, and I think its a great intro.

First hand experience: Books not enough (1)

ifakemyadd (1070340) | more than 7 years ago | (#19589223)

I recently began a coop at an embeded systems company, doing, whatelse, linux development for their platforms. I've read everything I could get my hands on about linux on embedded systems. For they most part, they're all redundant. Orielly's Understanding the Linux Kernel and Linux Device Drivers have been the two most useful books.

That said, neither is the "linux is the same embedded or not" argument all that good. I sure wish it was. Most information out there is about the x86 system, which embedded applications tend to avoid. On the other hand, books that target themselves towards the embedded market tend to mix and match different architectures. What I needed was comprehensive coverage of different processes specific to all the different platforms, because this is where kernel documentation or other resources tend to be rather skim.

Long story short: there was no quick substitute for paging through assembly code, and the very beginings of c code, to learn what I needed to know. For example, bootstrapping elfs verses non bootstrapping elfs, figuring out which code is which, the addresses that code executes at, etc. is all different for different platforms. In the least, it was only well explained for x86, and there was no explinations for the different standards and structures used in the boot process. (Mips, for example, uses an argv/c boot standard, ppc looks for the begining and end of a string address).
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...