My way into the embedded developpment went through microcontroller programming (8-Bit Atmel). Afterwards I switched to the AVR32 with a Linux distribution. So if you are not on the first hand interested in embedded Linux but in hardware. Maybe it would be a good way to start with a Datasheet from this microcontrollers. They a good structured and you get a better understanding of the prinicple embedded busses like i2c, spi, 1-wire, u(s)art. Pros: the data sheet is for free and a development kid shouldn't be too expensive. Cons: it's just the first step to become a embedded linux guy (if this is, what you want...). Regards, Matthias 2010/10/20 Greg Freemyer <greg.freemyer@xxxxxxxxx>: > On Tue, Oct 19, 2010 at 3:16 PM, StephanT <stman937-linewbie@xxxxxxxxx> wrote: >>> >> >>> Any suggestions what can I read ? >>> >> >> Is your list ready ? Â Â Â Â:o) >> >> 1. User Guide - Data Sheet >> 2. Application Notes >> 3. Code examples >> >> 4. Use Wikipedia to get quick answers and directions. >> >> >> I assume you have the basics (from what I already know about you). >> So, unless you have a very good recommendation don't spend money >> on books. >> >> Each manufacturer provides these docs on his WEB site. Download, >> scan-read and delete if not interesting. Keep otherwise. This is not >> pleasure neither casual reading. DO not try to read them like an History >> book or the last NYT bestseller. Learn to scan quickly. At the beginning >> you may get lots of questions. Clear them on Wiki and the NET. Use the >> Application Notes to "see" how others implement >> >> From my experience it is important to focus on one problem at a time. >> Go as deep as you can and when you sure you got it go to next topic. >> Do not try to read the UG from the first page to the last. Go straight to >> the chapter of interest. Say this is the UART. Start reading. They will >> mention the system clock - jump there get some insight come back >> and follow - and so on. If this really fires you fine - you are on your >> way to the knowledge. If not, go switch to Java :o) >> >> Actual micro-controllers, SOCs, CPUs are roughly the same - well from >> 30,000 feet above. You study the UART on one you'll have no problems >> to switch to another. >> >> This is it - don't look for some magic. And don't forget to use the Wiki, >> Luke, use the Wiki. >> >> Good luck, >> Stephan. >> >> ps. There are lots of Wikis. There is Mother Wiki but you will find >> more specialized. Search the net for Wiki. > > I agree with the above approach. > > I can typically now read a data sheet and know what it means, but if > you come across a phrase or concept you don't know, then you have to > look up what the words mean. > > To get you started, here's the AHCI spec. Â130 pages of pleasure reading! > > http://download.intel.com/technology/serialata/pdf/rev1_3.pdf > > Even if you're not interested in storage/sata, I recommend you take an > hour or so and scan that spec. ÂIt's very well written and gives you a > good feel for what you as a software person should be interested in. > You will note that it spends very little time if any talking about > voltages, physical parameters, etc. ÂInstead it is predominantly > filled with information a hacker working on the AHCI linux driver > would need to know. > > You can find some other nic and controller specs here: > http://gkernel.sourceforge.net/specs/ > > Alternatively, this list all links to the above docs, but is a little > easier to review for me: > http://www.linuxfoundation.org/collaborate/workgroups/networking/network-adapters#Hardware_specifications > > But, when I think of "hardware", I also include the ATA, SCSI, and > Ethernet standards at a minimum and you may want to get a copy of the > PCI / AGP / PCIexpress etc. standards too. > > Since I'm a storage guy, I'll hit the ATA and SCSI standards real quick: > > The ATA-8 standard incorporates IDE drives, SATA drives, and the > latest and greatest SSD drives. Â(You may have trouble finding a ATA-8 > spec. ÂWhat you typically find are draft specs that are piecemeal. > Once a spec is finally accepted, it is my understanding you have to > pay for them. ÂSo most of us work from the latest draft spec. which is > typically free, even if it's hard to find!) > > The SCSI standard is actually more like a 7-layer network stack. ÂSo > to my surprise several years ago I found out that USB drives actually > fit in the SCSI stack and SCSI commands are sent back and forth across > the USB bus. ÂThen at least for USB enclosures with rotating disks you > will typically find a SAT (SCSI to ATA Translator) inside. ÂIt is used > at the end of the USB bus to map the commands to ATA for delivery to > the actual drive. > > There is actually a SAT spec. out there somewhere if you really want to dive in. > > So the SCSI standard(s) cover parallel SCSI, SAS, FC, iSCSI, and USB > at a minimum! > > Clearly you need to decide if this kind of "hardware" interests you. > > fyi: To get extremely detailed in the hardware side you will need some > test equipment, but don't let that scare you away. ÂAs an example, for > SATA they make a bus analyzer that can monitor everything on the sata > bus and decode the commands for you. ÂIf you're getting into the nitty > gritty of what's going on you may need one of these, but I don't get > the impression most linux kernel developers have this type of > equipment. ÂIt's simply too expensive for the majority of people / > companies and you can do a lot of productive work without having one. > > Greg > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- motzblog.wordpress.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
