Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm new to the world of embedded programming and I'm looking for information about interfacing with a microcontroller using I2C, USB, UART, CAN, etc. Does anybody know any good links, books, tutorials, about this subject? Since I´m a real newb on this subject I prefer if it is as basic as possible.
Since you are already a desktop developer, you can probably jump in somewhere in the middle. Download the user manual for the controller you plan to use. Get the example code from the manufacturers etc. sites for one of the simpler peripherals - UART is good.
Get a development board and an Eclipse/Crossworks/whatever development system that supports your board and get something to work - flash LED, UART echo or the like. Don't try to use a multitasker and interrupt driver first off - just poll the UART with as few lines of code as possible. Why - because just getting a development setup to compile, link, download and run one line of code is a considerable exercise in itself, without any complications from complex code. You have your development setup and hardware to debug first before you can effectively write/debug any code for the controller. Just getting 'blinky' code that merely flashes an on-board LED to work is a huge step forwards:)
Most controllers have dedicated groups/blogs, either on the uC manufacturers site or linked from it - join them.
If you want to get into this efficiently, get a board and try to get it to do something - there is no better way. Once you can get a LED to flash or a UART to issue a string of chars, you're off to the races:)
Developing simple 'blinky' or UART-polling functions are not wasted - you can continue to use them later on when you have more complex code. Blinking a LED, (with the delay-loop replaced by an OS sleep), is such a good indicator that the code is sorta running that I've always kept it in on delivered systems. The UART poll is useful too - it will run without any interrupts and so you can call it from the data/prefetch/whatever abort vectors to issue the many 'CRITICAL ERROR - SYSTEM HALTED' messages that you will get during ongoing development:)
Wikipedia really is as good a place to start as any to learn the basics surrounding each of these mechanisms.
Once you've got a grasp, I'd recommend looking at an actual datasheet and user's guide for a microcontroller that has some of these features. For example, this 16-bit PIC has a dedicated UART, I2C and SPI bus. Looking at the relevant sections of the documentation, armed with your new knowledge of the underlying principles, you'll start to see how to design a system that uses them.
The next step would be to buy a development board for such a device and then, using example code (of which there is tons), code yourself up some datalinks. Incidentally, a UART is certainly the easiest to test, since all PCs can transmit using the RS-232 protocol from a terminal, so in this case you can code a loopback to transmit and receive characters with relative ease. With I2C and SPI however, I think you would need to buy a dedicated host dongle to allow you to transmit using the protocols, although I think Windows 8 might be introducing native support (but don't quote me on that).
I haven't implemented a datalink using CAN, so I can't comment specifically, although I just did a quick Google search and there's a PIC family that supports it, so I'm sure you could follow a similar approach. As for USB, I consider it a bit of a black art, so I'll leave someone else to answer that one - although I do know you can get a USB software stack for PICs, so again, a similar approach could probably be followed.
On a final note, I've only mentioned PICs as an example microcontroller. If you're not familiar with microcontrollers in general, you'll soon realise that all the major microcontroller families from companies like Microchip, TI and Atmel generally follow the same design, so I would have a browse and pick the family who's documentation you're most comfortable with (or least uncomfortable with, as suggested by Martin James!).
For the most part the data sheet or reference manual for the microcontroller you intend to use is what you need. Each vendor will implement these interfaces in different ways, so that is your only definitive source for low-level programming information.
I2C and UART are relatively simple with no standard higher-level protocol stack; that would be defined by you or the device you might be connection to. Your microcontroller vendor will almost ceratainly have example code and/or application notes.
CAN is more complex, and typically CAN networks use a higher-level application protocol of which there are several for different application domains such as CANopen, NMEA2000, DeviceNet, IEC J1939 and more. Most often a third-party library is the most cost effective method of implementing an application protocol stack, but if the network comprises of only devices you are implementing, then that complexity may not be necessary. Again your microcontroller vendor is likely to have examples.
USB is very strongly defined by the USB Implementers Forum, and protocol stacks are non-trivial. Most microcontroller vendors that have on-chip USB interfaces will provide sample code and application notes for at least device-class USB. USB Host stacks are more complex, and again the use of a third-party library (which are relatively expensive) is the quickest way to market. Fees you would otherwise be obliged to pay the USB IF may make writing your own host stack no less expensive. Even for a USB Device interface you will strictly need a USB Vendor ID at $2000 from USB IF. Some microcontroller and library vendors will allow you to use their Vendor ID for a defined subset of Product IDs at little or no cost, but you would probably have to be a significant customer in terms of volumes. For internal experimentation, you can probably get away without an official VID, but such a product could not be released commercially.
Related
A complete novice is here seeking some help regarding MCU. The thing is that I want to develop a project which will help foster my learning of MCU but currently I am at Level (minus) 10. I have many questions regarding MCU becaue of having little to no experience with those. Since I am inclined towards 8051 variants, my questions will be around that itself. I'll list the questions in pointer form here.
What is the main point of difference between a development board/lit or prototyping board? Can I program/burn an MCU if I have one of these or do I need a separate piece of hardware called programmer to put the hex code onto the MCU?
What is the difference between the programming of AT89c2051 and ATs52? Which one of the two can I program using the USB port on my laptop without much cost on the additional hardware? I was suggested to use 89v51rd2 because it can be programmed with just MAX232 without the use of any programmer however the additional cost of this MCU prevents me from going for it. I'd rather buy or build a programmer for myself and use 89c2051. But the problem is that I don't know how to program this thing using the USB port on my laptop.
Please guide.
Thanks
this ticket should get closed since it is not a programming question, primarily opinion based and/or just go read the manual are main reasons.
First off...just go read the manual. the 8051 is still alive and well but I wouldnt go there as your first mcu. There are avr based and msp430 based and arm based (and pics, my first but least favorite). The 8051 and arm based are going to be built by many different chip vendors in many different flavors. So as far as programming/burning your program into it, it can vary per vendor or chip family per vendor or per chip, basically there is on one answer. and you will find that some chips have more than one solution.
You wont need a max232. From usb, that is likely a waste, because you need to get from usb to rs232 levels then the max232 takes you back down to the chips I/O levels (unless your chip is a hybrid and has RS232 levels). they generally if not always use the normal gpio levels for the uart. what you are looking for is something ftdi based ft2232 or one of the many variants. can get cables now with the ftdi part in them or breakout boards $15 or less (plus stuff to hook it up, pins, jumper wires, whatever).
the arduinos are avr based and are getting cheaper and are massively popular tons of examples and users out there to help. st has a number of nice cortex-m based boards for $10 to $20 (nucleo, stm32 f0 discovery, f4 discovery). ti.com/launchpad has a number of boards msp430 and arm based (and their old dsp line if interested) for similar prices. Sometimes, seems like annually they lower the entry level msp430 board to $4.30. used to be free shipping but now there is a fairly reasonable shipping cost.
Basically you have to just do your reasearch, the information is all out there, some companies docs are better than others, some products have better online communities or examples or whatever than others. Then there is the processor type which may or may not matter to you, tools (this day and age the tools should be free, if not move on), libraries if you want to use canned ones or roll your own, etc...It can be overwhelming, perhaps just take the part that you specified, and read more about it, what the programming interface is. Being atmel their docs are usually pretty good at least for avr and arm based processors but perhaps for their 8051's as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
From http://www.altdevblogaday.com/2011/08/06/demise-low-level-programmer/:
"When I started programming many of the elements we take for granted now, did not exist. There was no DirectX and not many compatible libs were available for the free compilers of the day. So I had to write my own code for most basic programs, keyboard handlers, mouse handlers, video memory accessors, rasterizers, texture mappers, blitters… the programs I wrote then were 100% my own code and I had to be able to handle anything and everything."
I am looking for advice on how to learn more about low-level programming. For example, writing a keyboard/mouse driver, a vga driver or basic function like malloc.
What is the best way to approach this? I am an undergraduate CS student and had courses about computer architecture/assembly where we wrote a simple pipelined processor in VHDL on DE0-nano FPGA. I have a decent C programming knowledge.
It seems to me difficult to learn that stuff on a modern x86 computer. Are microcontrollers better (like arduino board) ? Or FPGA (but my DE0-nano seems limited) ? Or maybe buy an old computer like Commodore 64 to learn like the people back then ?
And is there any resources like book on this subject ?
I would recommend a microcontroller approach, msp430, avr, or one of the many arms. You can get an msp430 or one of the arm launchpads from ti for about 10-20 bucks, you can find stm32 based discovery boards for 10-20 bucks as well, the stm32f0 (cortex-m0) is simple, basic. The stm32f4 is loaded with stuff like caches and an fpu, but still a microcontroller.
I think the microcontroller approach will take you back to the roots, very basic stuff, the hardware doesnt have video usually or hard drives or anything, but you do learn how to master the tools (compiler, linker, etc) and how to read the manuals, etc.
You could just fast forward to linux capable hardware like the raspberry pi or beaglebone. At all levels but in particular the linux capable levels, in addition to the manuals for the video chips, usb chips, etc you also will want to use the linux source code to learn from. Understand that the linux drivers are often very generic and often contain code to drive a whole family or whole history of hardware from one vendor, so a bunch of the code may not match anything in the manual, but some will and that is where you will get over the hump of understanding what the manual is saying. Doesnt mean you have to re-write linux in order to use this information.
Start small take it one step at a time, pcie and video alone from scratch is a major task, if you start there you are quite likely to fail unless you already have the knowledge and experience (if you did you wouldnt be here asking).
An approach you can also take is bochs or something that emulates an old 8086 DOS system, and if you can find some good, old, dos/8086 based manuals you can poke at regisiters, cga mode, vga mode, etc. The disc controllers can be difficult still, etc...
There are plenty of arm, avr, msp430, mips, etc (and x86 but I wouldnt go there for this until later) instruction set simulators that would avoid the cost of hardware and also avoid the cost of damaging the hardware and having to buy more (it happens even with lots of experience), even better writing your own instruction set simulator...vba some nds simulators, working your way up to qemu.
I am an embedded SW Engineer, with less than 3 yrs of experience. I aim to "sharpen the saw" continuously. I was wondering if there was anything specific to low level programming that C/C++ coders should be proficient with.
What comes to my mind is familiarity with the hardware's architecture and instruction set. Knowing how to fiddle with bits is also important, resource management and performance have been part of my job, is there anything else?
EDIT: I work with an in-house customized RTOS, not embedded Linux.
I see a lot of high-level operating system answers here, but you specifically said low-level.
Some scattered thoughts:
Design for test. As you work through a problem only change one thing at a time per test.
You need to understand busses and interfaces, spi, i2c, usb, ethernet, etc. Number one interface, today, yesterday, and tomorrow, the uart, serial.
The steps involved in programming a flash.
Tricks to avoid making the product easily brickable.
Bootloaders in general.
Bit-banging above said interfaces on various families of parts (different chip
vendors have different ideas about io pins, pull ups, direction
controls, etc).
Board and chip bring up, you certainly never want to
boot a many tens of thousands of lines of code program on the first
power up (think led on, led off).
How to debug a product without using too much test equipment (logical analyzers and scopes), at the same time you have to learn to use a scope for debugging, you are far
more valuable if you don't HAVE TO have a tech or engineer in the lab
with you.
How would you reprogram the unit in the field? What would
you do to minimize human error when allowing the user to field
upgrade the unit? Remember field downgrades as well.
What would you do to discourage hacking (binaries, etc).
Efficient use of the flash/rom (don't wear out one bank or section, spread the wear around, or see if the flash is doing it for you).
How and when to use a watchdog timer.
State machines, very useful with bytestreams (serial and ethernet), design packet structures that stream well and are tailored to a state machine, and that have a header and checksum or other structure that insures you do not interpret partial packets or
random data as a good packet.
Specific concepts like,
Endianness (this link is to an old but good linuxjournal article)
Effective use of multithreading architectures (the Embedded site is good in general)
Debugging embedded and multithreaded systems
Understand, Learn and Follow good programming techniques (the link is very old and the point very generic and subjective, but think about it)
Other things (this IBM page on embedded linux sums up most of the other points I want to make)
One more thing -- never underestimate testing! or, planning test cases!!
Use the reference links I give as concepts,
please followup further for deeper knowledge.
I'd study the electronics of the actual chips. Learn how they work internally (such as architecture), interface with peripherals, electrical and timing characteristics, etc.
Basically, read the data sheet start to finish a few times and dig into anything you've not seen/used before.
By the way, what chips do you work with?
Similar to what Brian said, learn how to create unit tests and automated builds.
These skills are are good for all levels of software engineers to be proficient in. They will help improve the quality of your code while also making it easier to refactor and improve the code base.
If you haven't yet I think every Software Engineer should read The Pragmatic Programmer and Code Complete. I know these are not specific to low level programming, but have a large wealth of knowledge in them that applies to all sub disciplines.
Having great familiarity with pointers, the checks these languages don't do much (like buffer overflow and stuff like that), digital electronics. Operational systems internals might also help.
Get to know how stuff is represented internally, specially ready-made data structures (supposing you won't build your own one).
Above all, practice a lot. Doing it brings much more to you than just reading about it ;)
bit operations
processor architectures (caches, etc)
wcet analysis
scheduling
Edit: What I forgot to mention is model based development.
Today, the control algorithms are often implemented as some kind of automaton from which C code is generated afterwards.
Commercial available tools are for example MATLAB/Simulink, ASCET or SCADE.
Get yourself a copy of the MISRA-C book. It was originally written by members of the automotive industry, and attempts to make software written in C more robust by applying a number (quite a large number!) of rules and guidelines.
Then, buy PC-Lint (or another static analysis tool) to check your code for MISRA and other rules.
These are particularly relevant to low-level and embedded C, as between them they deal with the causes of a lot of bugs in such software, such as issues relating to pointers, memory leaks, integer promotion (there's a whole chapter on that in the MISRA book), endianness, and undefined behaviour.
Good question. Some that haven't been mentioned...
Learn your various options for achieving low-level multitasking. From basic round-robin (non-preemptive) schedulers, with timing ticks from a hardware timer, up to a preemptive RTOS. Learn why you might need an RTOS, and why you might not. If you use an RTOS, learn that beginners with a PC background probably tend to want to create too many tasks.
Getting visibility into the internals for debugging can be a challenge. There's no screen typically, so no throwing in "printf" calls wherever you want. An emulator or JTAG interface is ideal--you can set breakpoints and step through your program (as long as halting the micro doesn't make hardware go crazy, like swinging a robot arm around at full speed!). If emulator/JTAG is not available, learn how to use a spare serial port (or maybe even bit-bash a pin to make a serial port) for a debug channel, with some simple memory peek/poke commands.
I have been tasked to write a device driver for an embedded device which will communicate with the micro controller via the SPI interface. Eventually, the USB interface will be used to download updated code externally and used during the verification phase.
My question is, does anyone know of a good reference design or documentation or online tutorial which covers the implementation/design of the USB protocol stack/device driver within an embedded system? I am just starting out and reading through the 650 page USB v2.0 spec is a little daunting at the moment.
Just as a FYI, the micro controller that I am using is a Freescale 9S12.
Mark
Based upon goldenmean's (-AD) comments I wanted to add the following info:
1) The embedded device uses a custom executive and makes no use of a COTS or RTOS.
2) The device will use interrupts to indicate data is ready to be retrieved from the device.
3) I have read through some of the docs regarding Linux, but since I am not at all familiar with Linux it isn't very helpful at the moment (though I am hoping it will be very quickly).
4) The design approach, for now at least, it to write a device driver for the USB device then a USB protocol layer (I/O) would reside on top of the device driver to interpret the data. I would assume this would be the best approach, though I could be wrong.
Edit - A year later
I just wanted to share a few items before they vanish from my mind in case I never work on a USB device again. I ran into a few obstacles when developing code and getting it up and running for the first.
The first problem I ran into was that when the USB device was connected to the Host (Windows in my case) was the host issues a Reset request. The USB device would reset and clear the interrupt enable flags. I didn't read the literature enough to know this was happening, thus I was never receiving the Set-Up Request Interrupt. It took me quite a while to figure this out.
The second problem I ran into was not handling the Set-Up Request for Set_Configuration properly. I was handling it, but I was not processing the request correctly in that the USB device was not sending an ACK when this Set-Up Request came in. I eventually found this out by using a hardware USB protocol analyzer.
There were other issues that I ran into, but these were the two biggest ones that took me quite a while to figure out. The other issue I had to worry about is big-endian and little-endian, Freescale 9S12 vs USB data format (Intel), respectively.
I ended up building the USB device driver similar to UART device drivers I had done in the past. I have posted the code to this at the following URL.
http://lordhog.wordpress.com/2010/12/13/usb-drive
I tend to use structures a lot, so people may not like them since they are not as portal as using #defines (e.g., MAX3420_SETUP_DATA_AVAIL_INT_REQR 0x20), but I like them since it makes the code more readable for me. If anyone has questions regarding it please feel free to e-mail and I can try to give some insight to it. The book "USB Complete: The Developer's Guide" was helpful, so long as you knew what areas to concentrate on. This was a simple application and only used low-speed USB.
While writing a device driver for any interface (USB, Parallel port, etc...) the code needed to be developed would depend upon whether there is any Operating System(OS), RTOS running on that Processor/Micro controller.
e.g. if thats going to run say WinCE - It will have its own Driver development Kit , and steps to be followed in the device driver development. Same for any other OS like Linux, symbian.
If its going to be a plain firmware code(No OS) which is going to control the processor/microcontroller, then it's a different situation altogether.
So based on either of the above situation u are in, one needs to read & understand:-
1.) The Hardware Specification of the processor/micro controller development board - Register files, ports, memory layout, etc.
2.) USB spec
3.) Couple of pointers i found quickly. Google shud be ur friend!
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/ - Linux USB device driver
http://www.microsoft.com/technet/archive/wce/support/usbce.mspx
-AD
I've used an earlier edition of USB Complete by Jan Axelson. Indeed very complete.
From the editorial review:
Now in its fourth edition, this developer's guide to the Universal Serial Bus (USB) interface covers all aspects of project development, such as hardware design, device firmware, and host application software.
I'm curious, why did you pick the 9S12? I used it at a previous job, and was not pleased.
It had lousy gcc support so we used Metrowerks
which may have been okay for C, but often generated buggy C++
had a lousy IDE with binary project files!
The 9s12 was also slow, a lot of instructions executed in 5 cycles.
Not very power efficient, either.
no barrel shifter, made operations that are common in embedded code slow
not that cheap.
About the only thing I dislike more is an 8051. I'm using an ARM CortexM3 at my current job, it's better than a 9S12 in every way (faster clock, more work done per clock, less power consumption, cheaper, good gcc support, 32-bit vs. 16-bit).
I don't know which hardware you're planning to use but assuming that's flexible, STMicro offers a line of microcontrollers with USB/SPI support and a library of C-code that can be used with their parts. -- I've used their ARM7 series micros for years with great success.
Here is an excellent site maintained by Jonathan Valvano, a professor at the University of Texas. He teaches four courses over there (three undergraduate, one graduate), all are about using a 9S12 microcontroller. His site contains all the lecture notes, lab manuals, and more importantly, starter files, that he uses for all his classes.
The website looks like it's from the 90's, but just dig around a bit and you should find everything you need.
users.ece.utexas.edu/~valvano/
Consider AVR for your next MCU project because of it's wonderful LUFA and V-USB libraries.
I'm working on a project using the Atmel V71. The processor is very powerful and among lot's of high end connectivity offered on chip is a USB engine that will do device or host modes for 480 Mhz or 48Mhz (not USB 3.0). The tools are free and come with a number of host and device USB example projects with all the USB stack code right there. It supports 10 end points and all the transfers are done via DMA so you have most of the processor horsepower available for other tasks. The Atmel USB stack works without needing an RTOS
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking to learn about embedded programming (in C mainly, but I hope to brush up on my ASM as well) and I was wondering what the best platform would be. I have some experience in using Atmel AVR's and programming them with the stk500 and found that to be relatively easy. I especially like AVR Studio and the debugger that lets you view that state of registers.
However, If I was to take the time to learn, I would rather learn about something that is prevalent in industry. I am thinking ARM, that is unless someone has a better suggestion.
I would also be looking for some reference material, I have found the books section on the ARM website and if one is a technically better book than another I would appreciate a heads up.
The last thing I would be looking for is a prototyping/programming board like the STK500 that has some buttons and so forth.
Thanks =]
"embedded programming" is a very broad term. AVR is pretty well in that category, but it's a step below ARM, in that it's both simpler to use, as well as less powerful.
If you just want to play around with ARM, buy a Nintendo DS or a Gameboy Advance. These are very cheap compared to the hardware inside (wonders of mass production), and they both have free development toolchains based off of gcc which can compile to them.
If you want to play around with embedded linux, BeagleBoard is looking to be a good option, only $150 and it has a ton of features.
Personally I think AVR is best for the smaller-sized 8-bit platforms, and ARM is best for the larger, more powerful 32-bit based platforms. Like many AVR fans, I don't like PIC. It just seems worse in pretty much every way. Also avoid anything that requires you to write any type of BASIC.
If you just want to play around with it, I'd suggest the Arduino platform (http://www.arduino.cc). It's based on the ATmega168 or ATmega8, depending on the version. It uses a C-like language and has its own IDE.
Myself I've worked in embedded programming for 9 years now and have experience on TI MSP430, Atmel AVR (a couple of flavours) and will be using an ARM soon.
My suggestion is to pickup something that has some extra features in the processor like ethernet controller and CAN controller, even get two or three if you can. Embedded devices are nice to work with, but once they can talk to other similar devices via CAN or get onto a network, they can become much more fun to play with.
ADI's Blackfin is another option since it's quite a straight forward architecture to program, yet can also do some fairly hefty DSP stuff should you choose to go down that route. It helps that the assembly language is quite sane too.
The Blackfin STAMP boards are an inexpensive (~$100 last I checked) way in, and they support the free GCC tools and uClinux.
Whatever architecture you choose I'd definitely recommend first downloading the toolchain\SDK and looking through the sample projects and tutorials - generally having a bit of a play about. You can often get quite acquainted with the architecture through simulation without even touching any hardware.
ARM has the nicest instruction set of the widely used embedded platforms, leaving you free to pick up the general principles of writing software for embedded platforms without getting bogged down in weird details like non-orthogonal registers or branch delay slots. There are plenty of emulators - ARM's own, while not free, is cycle-accurate; and a huge variety of programmable ARM-based hardware is cheap and easy to come by as well.
The TI MSP430 is a great platform for learning how to program microcontrollers. TI has a variety of FREE Tools and some cheap evaluation boards (starting at $20). Plus, it's a low-power, modern microcontroller.
A nice choice would be PIC18 by Microchip
It has quite alot of material, documentation, tutorials and projects on the internet
Free IDE and compiler.
you can pull your own flash writer in a few minutes.
(Although for a debugger to work you'll need to work harder)
If you're a student (or has a student email address) Microchip will send you free sample chips. So basically you can have a full development environment for close to nothing.
PICs are quite prevalent in the industry. Specifically as controllers for robots for some reason although they can do so much more.
Arduino seems to be the platform of choice these days for beginners although there are lots of others. I like the Olimex boards personally but they are not really for beginners.
Microchip's PIC range of CPUs are also excellent for beginners, especially if you want to program in assembler.
BTW, Assembler is not used as much as it used to. The general rule with embedded is if you've got 4k of memory or more, use C. You get portability and you can develop code faster.
I suppose it depends on your skill level and what you want to do with the chip. I usually choose which embedded chip to use by the available peripherals. If you want a USB port, find one with USB built in, if you want analogue-to-digital, find one with an ADC etc. If you've got a simple application, use an 8-bit but if you need serious number crunching, go 32 bits.
I'd like to suggest the beagleboard from TI. It has a Omap3 on it. That's a Cortex-A8 ARM11 CPU, a C64x+ DSP and a video accelerator as well.
The board does not need an expensive jtag device. A serial cable an an SD-Card is all you need to get started. Board costs only $150 and there is a very active community.
www.beagleboard.org
Your question sort of has been answered in this question.
To add to that, the embedded processor industry is very segmented, it doesn't have a major player like Intel/x86 is for the "desktop" processor industry. The ARM processor does have a large share, so does MIPS I believe, and there are many smaller more specific microcontroller like chips available (like the MSP430 etc from TI).
As for documentation, I do embedded development for a day job, and the documentation we have access to (as software developers) is rather sparse. Your best bet is to use the documentation available on the processor manufacturers site.
Take a look at Processing and the associated Arduino and Wiring boards.
If you just want to have fun, then try the Parallax Propeller chip. The HYDRA game platform looks like a blast. There's a $100 C compiler for it now.
I started on BASIC stamps, moved up through SX chips and PICs into 8051s, then 68332s, various DSPs, FPGA soft processors, etc.
8051s are more useful in the real world... the things won't go away. There's TONS of derivatives and crazy stuff for them. (Just stay away from the DS80C400) The energy industry is absolutely full of them.
Start with something tiny. If you have external RAM and plenty of registers... what's the difference between that and a SBC?
Many moons ago I've worked with 8-bitters like 68HC05 and Z80, later AVR and MSP430 (16-bit). However most recent projects were on ARM7. Several manufacturers offer ARM controllers, in all colors and sizes (well, not really color).
ARM(7) is replacing 8-bit architecture: it's more performant (32-bit RISC at faster instruction cycles than most 8-bitters), has more memory and is available with several IO-configurations.
I worked with NXP LPC2000 controllers, which are also inexpensive (< 1 USD for a 32-bitter!).
If you're in Europe http://www.olimex.com/dev/index.html has some nice low-cost development boards. Works in the rest of the world too :-)
For a fun project to test, have a look at xgamestation
But for a more industrial used one chip solution programming, look at PIC
For my Computer Architecture course I had to work with both a PIC and an AVR; in my opinion the PIC was easier to work with, but that's maybe because that's what we worked with the most and we had the most time to get used to. We used the AVR maybe only a couple of times so I couldn't get the hang of it perfectly but it also was nothing overly complicated, or at least not more frustrating than the other.
I think you can also order microprocessor samples from Microchip's website so you could also get started with that?
Second that:
Arduino platform http://www.arduino.cc
HTH
For learning, you can't go past the AVR. The chips are cheap and they'll run with zero external components - they also supply enough current to drive an LED straight from the port.
You can start with a cheap programmer such as lady-ada's USBTinyISP (USD$22 for a kit) which can power your board with 5V from the USB port. Get the free tools WinAVR (GCC based) and AVRStudio and get a small project working in no time.
Yes the AVRs have limitations - but developing software for microcontrollers is largely about managing resources and coping with those problems. It's unlikely that you'll experience problems such as running out of stack space, RAM or ROM when you're making hobbist projects for powerful ARM platforms.
That said, ARM is also a great platform which is widely used in the industry, however, for learning I highly recommend AVRs.
I would suggest Microchip's PIC18F series. I just started developing for them with the RealICE in-circuit emulator, but the pickit2 is a decent debugger for the price. You could say this for the AVR's also, but there is a large following for the device all over the web. I was able to have a - buggy, yet functional - embedded USB device running within days due to all the PIC related chatter.
The only thing I don't like about the PICs is that a lot of the sample code is VERY entwined into the demo boards. That can make it hard to tear out sections that you need and still have an application that will build and run for your application.
Texas Instruments has released a very interesting development kit at a very low price: The eZ430-Chronos Development Tool contains an MSP430 with display and various sensors in a sports watch, including a usb debug programmer and a usb radio access point for 50$
There is also a wiki containing lots and lots of information.
I have already created a stackexchange proposal for the eZ430-Chronos Kit.
You should try and learn from developpers kits provided by Embedded Artists. After you get the kit, check their instructional videos and videos provided by NXP, which are not as detailed as they could be, but they cover a lot of things. Problems with learning ARM as your first architecture and try to do something practicall are:
You need to buy dev. kit.
You need a good book to learn ARM assembly, because sooner or later you will come across ARM startup code, which is quite a deal for a beginner. The book i mentioned allso covers some C programming.
Combine book mentioned above with a user guide for your speciffic processor like this one. Make sure you get this as studying this in combination with above book is the only way to learn your ARM proc. in detail.
If you want to make a transfer from ARM assembly to C programming you will need to read this book, which covers a different ARM processor but is easier for C beginner. The down side is that it doesn't explain any ARM assembly, but this is why you need the first book.
There is no easy way.
mikroElektronika has nice ARM boards and C, Pascal and Basic compilers that might suite your demands.