LJ Brain Trust: Embedded programming books?

[cjsmith]

I'm on a Quest. I suppose I need some shining armor and a mystical blade, except that I'm also the Damsel in Distress, which messes up the iconography quite a bit.

1. I want to understand how Ethernet MACs work. I want to know enough about it that I could easily program one -- write an Ethernet driver, that is. This also implies some knowledge of PHYs and what they do. I do NOT need to know anything about TCP, UDP, IP, cabling, security, routers, hubs, name service, subnets, or how to program a web server using Java. Some of that I'm familiar with already and I don't need any of it right now anyway. We are talking link layer only here. (Well, ok, a bit of physical.)

2. I want to get better at embedded software development in general. Principles. Concepts. Gotchas. Debuggggiiiiiiiiiing. So far, I have learned by doing. This has benefits and drawbacks. I'm looking to spackle the holes.

I am on a quest for books on these two subjects. I want good books -- I'm lazy, and if a technical book doesn't make me learn its subject any faster it's not worth reading. I want books that are worth the money -- I'm not rich enough that I want to spring for a $60 book because it has one chapter that touches on what I need. Ideally, I want books that come personally recommended by people who have benefited from the material themselves. (This means I can search amazon.com as well as the next geek, thanks.)

Yes, I'm aware that there's a strong possibility that what I am looking for is not out there. I honestly don't know how many people a) write Ethernet drivers for a living, b) don't already know how to do it, c) read English, and d) like to learn from books. If I were a publisher I admit I wouldn't print it. On the other hand, maybe it does exist. Yesterday I saw a book titled "Blogging for Teens" and I wouldn't have printed that one either.

Lemme know, embedded gurus.

Comments

Debugging book

[elflet.livejournal.com]

I found a great general book on debugging, written in a way that it's especially useful for low-level debugging:

"Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems" by David Agans

It's good enough that I've been using it as a sourcebook for teaching troubleshooting and debugging in a biomanufactoring environment.

[gorillashaman.livejournal.com]

The sort of stuff you're looking for (MAC/PHY) is often found in the data sheets for the chips you're using, and tends to escape a general treatment.

Almost sort of ditto for the embedded development. Know your chips. Know how they're glued together. Avoid dynamic memory allocation at all costs. Know your compiler. Lots of cheap embedded compilers have bugs, but embedded processors are getting more and more like standard chips (Atmel has a lot of chips supported by GCC, and lots of other embedded processors have PPC cores; it's not just 8051s any more). Know your tools.

There's a lot to know here, and I've never seen a book that really treated it well in a very general sense.

[jmkelly.livejournal.com]

I would think you'd want to know something about hubs and bridges/switches . . .

Tanenbaum's Computer Networks has a good section on Ethernet/IEEE 802.3, as I recall. And there are a zillion webpages -- see here (http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ethernet.htm), especially the one from Cisco (http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ethernet.htm).

Anything by Rich Seifert is probably good.

[lkeele.livejournal.com]

There. Now you can be both. ;)

[quasigeostrophy.livejournal.com]

I suppose I need some shining armor and a mystical blade

Not a bad visual. ;-)

[hitchhiker.livejournal.com]

I've heard that BSD source is very well commented - it might be worth a try if all else fails.

Re: Debugging book

[cjsmith.livejournal.com]

Mmm, thanks -- I'll check it out! I also have "Debugging by Thinking" by Metzger. I have read only the first few chapters, and so far, I'm not impressed. It could improve, though.

[cjsmith.livejournal.com]

This comment makes loads of sense to me, and my gut says that you're absolutely right: a general treatment either won't exist or won't help. Ah, sigh, I always want to look for an easy way! :)

[cjsmith.livejournal.com]

Yay! Lisa found me a picture!

I recognize the style of the artist... can't name who it is, but still... I've seen jigsaw puzzles with that person's work. :)

[cjsmith.livejournal.com]

Wearable art project number seventeen... :)

[cjsmith.livejournal.com]

Hmm, I actually hadn't thought of that. Thanks!

[cjsmith.livejournal.com]

Thanks! I'll check out those web pages. Seifert, I've run across that name in my amazon explorations...

[lrc.livejournal.com]

I humbly submit this thing I wrote years ago:
http://red4est.red4est.com/lrc/debuggable.html

I highly reccomend subscribing to embedded systems programming, also at http://www.embedded.com

I probably have a bunch of old copies lying around.

The embedded systems conference is also coming up (Scott Adams is keynote, I saw Douglas Adams keynote there, let's hope that Scott doesn't die two weeks later like Douglas did).

Look for stuff written by Jack Crenshaw or P.J. Plauger

The most important thing WRT test and debug is to not try to tack it on at the end. Plan for it up front from the design stage. Even design and write limited scope programs that'll test specific sections of the code and hardware.

[lrc.livejournal.com]

There used to be a good Linux networking howto that described a lot of the low level stuff. I also reccomend W Richard Stevens books on networking, also Douglas E. Comer's books.

[cjsmith.livejournal.com]

*nod* I've got both the Stevens set and the Comer set. (Thank goodness, 'cause I'm too pennypinching to want to spring for them right now! Handy that I already own them!) I should go back and review the relevant sections. Good reminder, thanks.

[cjsmith.livejournal.com]

I was wondering whether Embedded Systems Programming would be useful. Thanks for the recommendation. And yes, I'll be at ESC! :-) (See you there?)

design and write limited scope programs that'll test specific sections of the code and hardware

*nod* To my company's credit, this is actually an explicit part of my job. Thumbs up!

[eichin.livejournal.com]

There was a book about eCos (the cygnus/redhat embedded platform that was getting off the ground around when I left) out a couple years back - since it had to talk a lot about integration (eCos was supposed to be easy to integrate and not too hardware specific, though I don't know how much it ended up being true) it might be around the level you want (and you might be able to find locals or local bookstores with copies...)

I'd also give http://www.circuitcellar.com/library/ccofeature/lightner0799/index.asp (and some of the other hits for atmel web server) a look - it's from a couple years back, someone wirewrapped an atmel CPU to an ISA ethernet card and did bit-banging I/O (none of this "bus abstraction" nonsense :-) to talk to it and make it act as a very-thin-stack webserver. (I got most of my [somewhat out of date] experience with this stuff by doing it - my first hacking involved TRS-80's and IMSAIs, the latter having front panel switches, and being very Embedded Systems-like even if we were using them as business systems...)

Vendor datasheets have always been a good source of material, or even better, "Application Notes" which are typically "look, see, our product can actually be built into something useful" (Part Of This Complete Breakfast :-) And in the Modern Era you can usually get them as free PDFs and just flip through them to find the good bits. Sometimes the linux or BSD device drivers will have footnotes pointing them out directly.

The other class of books to take a look at is in the Robotics space - possibly more on the hobbyist side - generally won't do ethernet itself, but if you avoid the "abstract manipulator space" and "goal-directed planning" material you should end up in a useful hardware range (again, easier if you can go through bargain buckets of books, stuff from 5 years back will be more useful, and won't be as much "drop a used PDA into a pile of lego".

Most embedded debugging seems to come down to (1) think hard (2) use your mental model to come up with experiments (3) hook up enough instrumentation to confirm your experiment. (A recent ipod-reverse-engineering effort that got a lot of blog traffic involved dumping the firmware out with audible "chirps" over the speaker port and using a sound card to instrument it - "instrumentation" can vary a lot, the standard Cygnus embedded hello world involved making an LED blink, even for something as high end as SPARClite :-)

One more thought - the Debugging Rules! (http://debuggingrules.com) site has what looked like (from the two free chapters) a good "how to think about debugging problems" book, and overview poster - I think I'd point beginners at the book, and people with experience at the poster :-) since it covers the key concepts in easily convincing ways. The "war stories" in the free chapters are pretty good too.

[cjsmith.livejournal.com]

I've got the eCos book, thanks! (Well, ok, a coworker has it. Well, ok, he's now left the company, so he might have taken it with him... oops, no, he didn't, so maybe I hafta find him and hand it over.)

Thanks for the web site -- both of them, in fact. I printed out the Debugging Rules, the less-flowery version found in "chapter two", and will display it in my office until I get distracted by something newer and shinier. :-)

DEFinitely vendor datasheets. Incredible how grateful I am to Google for being able to find random datasheets in a couple of tries. Incredible how grateful I am to companies willing to put their datasheets up on the web, instead of making you go sign an NDA and get a licensed copy (*cough* not that I've worked with M--, er, I mean any company like that).

Robotics, eh? I wouldn't have thought of that. Any specific books come to mind?

I'm seeing a lot of examples of "clever instrumentation" in Debugging Embedded Microprocessor Systems, a book I've borrowed from a friend. (How lazy and cheap can ya get? BORROW the thing!) He does everything from instrumenting the code (including bit-banging dumps of various things at various events) to creating little bits of hardware that will blink or count or what-have-you when hooked to a couple of pins. If nothing else, it's breaking my old limiting habit of equating "debugging" with "using a debugger".