![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
LJ Brain Trust: Embedded programming books?
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.
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.
Debugging book
"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.
Re: Debugging book
no subject
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.
no subject
no subject
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.
no subject
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".
no subject
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.
no subject
no subject
There. Now you can be both. ;)
no subject
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. :)
no subject
Not a bad visual. ;-)
no subject
no subject
no subject
no subject
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.
no subject
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!
no subject
no subject