February 2023

S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728    

Style Credit

Expand Cut Tags

No cut tags
Tuesday, February 1st, 2005 06:48 pm
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.
Tuesday, February 1st, 2005 08:50 pm (UTC)
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.
Wednesday, February 2nd, 2005 10:53 am (UTC)
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! :)
Thursday, February 3rd, 2005 03:21 am (UTC)
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.
Thursday, February 3rd, 2005 03:21 pm (UTC)
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".