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.
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!