Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've just finished watching the first week of Functional Hardware Verification course at Udacity. In the promo, it says, it requires both Electrical Engineer and Software Engineer skills. This is why it intrigued me. But I got an impression like, it is only for chip designers. Am I wrong?
Can it be also useful for embedded software developing ?
For example, how can I utilize this information with a Raspberry Pi and/or an Android device ? Is it possible or am I wasting my time with this course?
I'll be happy if someone could give me an insight.
1) is this a stack overflow question? not sure, will see what happens.
2) is this a waste of time, I would argue no, its free, just watch, learn something
3) does it apply to embedded on a raspberry pi or android? probably not, depends on your definition of embedded first off, if you are making api/library calls to an operating system or environment, that is just writing applications. if you are digging down into the bare metal, it gets closer, but not quite. Now if you are working somewhere where you work hand in hand or are or are going to be designing chips, fpgas, cplds, etc. And, the company is such that they are willing to move into the 1990's or 2000's and allow the software developers to develop against the rtl in simulation, access to the simulator licenses (very expensive, doesnt take very many cadence licences to shadow your salary).
During the chip development phase of time (vs the post silicon sell the chips for a while before the next chip starts) we build our own sims using the kinds of things I assume this class is teaching, but perhaps not since the traditional testing methods are not quite what I am talking about. we sim portions or the whole chip, use the "foreign language interface" or whatever the vendor calls it, to interface software to the simulated hardware. We do it using an abstraction layer in such a way that a high percentage of the code we write against sim will run against silicon using a different abstraction layer/shim. This can give months to a year or more head start on the software, and can find bugs in the logic design as well as the design of the hardware/software interface (are interrupts a good idea, can we poll fast enough, use dma, etc).
Cadence is of course going to push their product and their ways of doing things even though their products support a wide range of features. There are other tools. I am a fan of verilator, open source, free. but it is very particular about the verilog it supports, mostly synthesizable only, and that is fine by me, so depending on the verilog author you are relying on they may not have habits that support whate verilator is looking for. icarus verilog is much more forgiving but very slow. verilator is like 10 times slower than cadence, icarus is slower than that. but free is free...There are a number of things at opencores for example that you can play with if you want to see this in action, amber, mpx, and altor32 are ones I have played with for example.
If you land one of these chip/board company jobs then familiarity with simulators like cadence and modelsim and the free tools (verilator, icarus, gtkwave, ghdl, etc) are valuable. Being able to read verlog and/or vhdl (which is not hard if you are already a programmer, the only thing new is that some of the code is truly "parallel", which with multi-core processors today that is not actually a new thing for a programmer). If you are able to interface software to the simulator, then you are an asset to that company because you can facilitate this development against the simulated hardware and save the company money in units of multiples of your salary with found bugs before silicon and shorting the schedule by many months.
Lastly, being able to look at waveforms and see your code execute is an addictive experience.
Just like learning bare metal, or assembly, getting familiar with hardware at this next lower level can only help you as a programmer, even if the experience is with logic or processors that are not the ones you are programming. Remember that just like programmers, take any N number of programmers given the same task they may come up with anywhere up to N different solutions. Just because one implementation of a mips clone has certain details does not mean all mips nor all processors look like that on the insides.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I would like to learn something about embedded development. I think the best thing would be to buy hardware stuff and play with it but I don't know where to start and, if possible, I would like not to pay too much....
If you have experience in this field, which would be the best road to follow?
I assume you mean real embedded and not embedded linux or some other operating system thing.
All above are good, sparkfun.com is a GREAT resource for sub $50 cards. Dont buy the embed. The armmite pro is nice, trivial to bypass the high level canned package and load your own binaries (I have a web page on how to do it if interested).
Stellaris is good, the 811 is easy to brick so be careful, the 1968 eval board is not a bad one. The problem with the stellaris boards is almost all of their I/O is consuemed by on board peripherals. The good thing about the stellaris eval boards, based on what you are wanting to do is that all the I/O is consumed by on board peripherals. Lots of peripherals for you to learn how to write embedded code for.
You are going to eventually want a jtag wiggler, I recommend the amontec jtag-tiny, it will open the door to a number of the olimex boards from sparkfun. the sam7 and stm32 header boards are good ones as well.
the lillypad is a good starting place for arduino (sparkfun), same price as the arduino pro mini, but you dont have to do any soldering. get a lillypad and the little usb to serial thing that powers it and gives you serial access to program it. Just like the armmite pro I have a web page on how to erase the as-shipped flash and have a linux programmer that lets you load any binary you want not just ones limited to their sandbox.
avoid PIC and 8051 unless you are interested in a history lesson. the PIC32X, not sure my first one is in the mail, it is a MIPS 32 not a PIC core.
the ez430 msp430 board is a very good one, the msp430 has a very nice architecture, better than the avr.
You can get your feet wet in simulation as well. I have a thumb instruction set emulator, thumbulator.blogspot.com. Thumb is a subset of the arm instruction set and if you learn thumb then you can jump right into a stellaris board or stm32. My sim does not support thumb2, the thumb2 processors also support thumb, the transition to thumb2 from thumb is trivial.
avoid the stm32 primer boards, avoid the stm32 primer boards, avoid the mbed2 boards, avoid the mbed2 boards, avoid the lpcxpresso boards, avoid the lpcxpresso boards!!
I recently found a behavioral model of an arm in verilog that you can simulate your programs, have not played with it much. qemu-arm is probably easier, not a bad place to get your feet wet although it can be frustrating. Which is why I wrote my own.
ARMS own armulator is out there, in the gdb source release for example, easier than qemu-arm to use, but can be frustrating as well.
go to codesourcery for arm gcc tools. use mspgcc4.sf.net for msp430 tools. llvm is rapidly catching and passing gcc, if nothing else I expect it to replace gcc for the universal cross compiler tool. at the moment it is much more stable and portable than gcc when it comes to building for cross compiling (because it is always/only a cross compiler wherever you find or use it). the msp backend for llvm was an afternoon experiment for someone, sadly, I would really like to have that supported. If you use llvm, use clang not llvm-gcc.
If you want to get your feet wet, get a cheap evaluation board like Stellaris LM3S811 Evaluation Kit (EK-LM3S811) which is $50 at Digi-Key then download CodeSourcery G++ which provides free command line tools or the IAR Kickstart Edition which allows you up to 32KB of code.
I would suggest starting up with MSP430. The MSP430 launchpad is quiet cheap. Alternatively, you could start up with the Stellaris (ARM Cortex M3) Boards. You can use the already provided libraries first to start developing apps rite away and then start writing your code for configuring and getting things done by referring the data sheet.You also get example codes, relevant documents and Keil 32K limited evaluation version. If you want to do things write from scratch, then get an ARM based board with IO breakout headers and start working. Lot of them are available from vendors like Olimex. One word of caution ARM is difficult to start with if you are working from scratch with little or no idea about embedded. So if you are looking for something easier go for AVR or 8051, but 8051 core is too old. So, Stellaris would be a good option in my opinion with their already available driver libs and codes.
Well, depending how much money you want to spend, and how much development expertise you have, you could either get an Arduino (arduino.cc) or a FEZ Domino (C# .NET) (tinyclr.com). Both are premade MCUs, with all the tools you need to start developing out of the box.
The Arduino is going to be very simplistic, but probably better for a beginner. The FEZ is a little harder to work with, but FAR more capable. Both have the same physical pinout, so you can use "shields" between them
I would recommend a kickstart kit from iar systems. They're fairly complete and work out of the box.
http://www.iar.com/website1/1.0.1.0/16/1/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have completed my degree in Computer Engineering. We had some basic electronics courses in Digital Signal Processing, Information Theory, etc. but my primary field is Programming.
However, I was looking to get into Embedded Systems Programming, and I have NO knowledge of how it is done. However, I am very keen on going into this field.
My questions :
What are the languages used to program embedded systems?
Will I be able to learn without having any basics in electronics?
Any other prerequisites that I should know?
Without a doubt, experience or at least a significant understanding of digital electronics and low level computer engineering is required. You'll need to be able to read device datasheets and understand them. Scopes, multimeters, logic analyzers, etc... are tools of the trade.
C is used mostly, but higher level languages are sneaking in slowly.
Getting started in Embedded Systems is a complex task in itself, because it is a very vast field with numerous options in hardware and software.
What are the languages used to program embedded system programs?
Assembly Language, C, C++, Python, C# and others.
Will I be able to learn without having any basics in electronics?
Learning embedded systems without the basic knowledge of electronics would not be a good idea. Embedded systems is a mix of hardware and software. You can follow the approach of learning-by-doing instead of going through the lengthy and detailed text books.You can refer to this blog
to learn embedded systems by doing practicals, step by step. It will help you to get started from the scratch.
Any other prerequisites that I should know?
Basic electronics, digital electronics, knowledge of microcontrollers and C programming. Since you are from computer science background you would need a development board of any 8-bit microcontroller (students of EE and ECE have enough knowledge and background to build it on breadboard or pcb) to get started. (Don't prefer simulators in the start, you might get your concepts wrong!).
You have to accept constraints and be able to work with them:
CPU speed
scarce memory
lack of networking facilities
custom compilers and OSes
custom motherboards and drivers
debugging with a logic analyzer
weird coding and testing practices
...
The reward is a deep understanding on what is going on.
VHDL, Verilog, and FPGA's are serious players in this arena as well. With a good background in CS, plenty of commitment, and maybe some MIT OpenCourseware you'll be able to pull off something good. A good knowledge of cpu architectures and some ASM will go a long way too.
I went into that field with no knowledge of how it was done as a fresh graduate and quit after 1,5 years. So, what I say may be a little bit rusty, and definitely not comprehensive.
The language we were using was C. But at that time, the disc space was 4MB and memory was 8MB on the devices we were developing for, and I know that C was used due to its libraries' tiny footprint. Apparently, performance was a criterion as well.
As to basic electronics, for an entry level position almost none is necessary. You will gain the required information and experience with time.
Not prerequisites, but having experience in the operating system internals and system development is definitely a plus.
Embedded systems are generally programmed in C, although there are systems at the ends of the range which use assembler when code space or timing is really tight (or there is no decent C compiler available), and at the other end, C++ up to .NET compact. It depends on what you mean by embedded systems, they go from really small microcontrollers with a few hundred bytes of RAM and program space, up to the smartphone type of device running a full multitasking operating system and user interface.
You'll get further in the higher end of this range without a background in electronics, because its less tied to the hardware and more similar to desktop development. As you go down the range of applications, a knowledge of electronics, analogue and digital, and power supplies, noise issues, compliance issues, heat issues and others all combine to make a really challenging design environment.
Start by reading some of the links here and embedded.com
The one thing that I have not seen mentioned in the answers so far is that up until now you have probably done most of your coding in the context of an operating system. In many (perhaps most?) cases, with firmware as opposed to software, you will not have the convenience and benefits of coding on top of an operating system. This is why so many of the other answers indicated that a good knowledge of electronics was critical.
As others mentioned, embedded can mean many things. In my world (Aerospace and Defense), we work with real-time operating systems (VxWorks and Integrity are the biggest players) and occasionally Linux. We program in C primarily, although C++ is also used as well if the project has decided to use Object Oriented Programming and Modeling.
So, as for the Pre-Reqs, C for sure. You really need to learn all about C, including BIT wise operations, dealing with hex values, pointers, all the low level stuff. Assembly as well, but I only use it for debugging the hardest stuff nowadays. You need to know enough to read and understand.
I think An Embedded Software Primer is a great start to change your thinking towards embedded. Handling interrupts, real-time issues, etc...
As Mickey mentioned, sometimes you don't even have an OS. In these cases, you usually write your own task manager of some sort, but that usually wouldn't be something for the newbie to start with. Good luck.
Languages: C, Assembler, Processing, Basic and a whole variety of others, it depends on what platform you're using as to what's available.
You might get more specific information if you ask the same question at ChipHacker or Electronics Exchange which are both stack exchange style sites (like this is) but geared to electronics and "physical computing".
You'll want to get pretty comfortable with C and build a solid understanding of assembly. In systems / embedded, usually you're working with small amounts of memory and slower processors, so you need to understand how to use limited resources wisely.
If you're getting into this as a hobby, pick up a gumstix board or an arduino, these dev boards will give you hundreds of hours of learning and fun.
If you're trying to make a career of this, find a job where the projects sound interesting and get your hands dirty. Take every task that comes your way and ask yourself how you can do better and learn from this task.
Either way, have fun and happy coding!
Learn C. Learn to apply C to all problems. Other languages can wait. Eventually assembly will help and no programmer should be without the use a scripting language.
Depending on what embedded targets you use there could be very little difference between a PC and your target. With little electronics background this would be your easiest entry.
Small processors will give you the the steepest learning curve but you will learn the most about embedded programming. However with no electronic background this can present extra problems you might not have the skills to solve yet.
Eventually you will have to learn electronics if you want to make further progress beyond the basics.
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.