Which microcontroller to start?( for beginner with my needs)?

[elissaios]

Hallo,

i am new here,I am seaching for a 8 bit mC to start  and a kit .i have been searching for 5 days and i have spent many hours searching in forums,youtube and kits.

i want to buy a uC because i like it and i think it will help me understand how a computer works in low to high level and how it co-opperate with the peripherals.So i want to learn both assembly and c.

I know about avr,pics,it .i dont care so much which of them i will learn.The most important feature that i want to have is a great tutorial with step by step what to do,how to start,sample code in assembly and c,exaples.I know both avr and pic have many examples but i didnt find any excelent tutorial how to start step by step.So i will buy the uC which can find how to study and learn because in my university we learn only theoritical things.So if you can suggest me any kit or tell me how you start to learn.

i dont like arduino because its so abstract and all tutorials is about "wiring" and not in c and assembly
I study in university computer enginiring and i have basic knowledge in c programming,electronics,pc architecture and logic design but i have never use any microcontroller.

If you help me to find a solution i would be very grateful

[firewalker]

You want a development board or just a plain mcu+programmer+breadboard? Do you use Windows or Linux? What is your target price?

It doesn't really matter witch one you choose to start with. Once you get used to code C on a micro you can interchange between families and vendors.

I would say that PIC and Atmel is the way to go if you need a big amount of tutorials. Personally I started with Atmels's AVR family just because it was more easy (for me) to use it under GNU/Linux (my OS) than PIC.

If you weren't able to find something that cover your needs in five days maybe you should consider buying a book for the subject.

Someone had mentioned that http://www.mikroe.com/ is a good place to begin. It offers tutorials, book, kits, etc.

Alexander.

[elissaios]

i have dual boot linux and windows.(i use both of them).

i would prefer  mcu+programmer+breadboard but if there is a very good development board with a nice guide how to start out i could buy.

IF i want to buy book first i have to find what uC i will use.
The most money i can give is 90 euros if i am sure it would be ok.
ANy ideas of how could i start or how you started with uC's?

[Ferroto]

You may want to start off with the Arduino UNO. It's the most user friendly MCU platform I've used with a huge userbase and tonnes of free code avaiable on the net. Just remember to get the one with a socketed DIP MCU (some have surface mount MCU's). This will give you alot of flexability if you want to take the chip off board and use it in a finished product.

[AndyC_772]

Grab yourself a PICKIT 3, or perhaps the PICKIT 3 "debug express" kit which includes a target board to play with, and head on over to Gooligum Electronics. Their tutorials are excellent.

They also now have their own development board:
http://www.gooligum.com.au/devboards/base-mid/base-mid.html

[AndreasF]

The TI Launchpads (the original MSP430 variants) are also very good for beginners who want to dive a little deeper than the Arduino. You have the programmer and debugger directly on board, can program a variety of different microcontrollers with it, which are all socketed in case you want to use them stand-alone later, and the development environment it comes with is decent as well.

[mrflibble]

Yeah, them MSP430 launchpad is a nice start. Code Composer Studio is easy to use, and when just getting used to things the Grail configuration plugin is nice. No substitute for actually reading datasheets and such, but to I found it useful to get started quickly. So if you want cheap and easy enough, MSP430 would be a good one.

[Simon]

I'm not well up on the support for AVR/atmel, I started with pics and mikroBasic but then went microC and now I have managed to use mplabx from microchip to program in C using the Hi-TECH compiler.I use a pickit2 still trying to work out why my pickit3 won't work.

I started with 12F615's and 16F88, now I'm using 16F883 and 16F887 that mickroE use as a base.

I always prefered a breadboard and programmer, I tried the arduino but didn't even bother (it's up for sale now)

[madires]

Get inexpensive kits for both worlds: ATmega and PIC. Since you already got some basics of CPU/MCU architecture you should be able to understand the datasheets, guides and notes provided by Atmel and Microchip. Check your local book store specialized in technical literature for books matching your needs. Start with assembler and you'll understand the differences between ATmega and PIC.

PS: I've started with the venerable 68HC11 and still got my first dev kit.

[mrflibble]

Start with assembler and you'll understand the differences between ATmega and PIC.

Or skip assembler altogether and enjoy the faster time to completion for a first project. ;-) Just get a decent C compiler and use that, IMO that will get you going faster than the asm route. Then again, you didn't advocate using asm. You pointed out that (and I am paraphrasing here) assembler on PIC sucks donkeybawls and on AVR it's fairly doable. I concur.

[Simon]

assembler is a waste of time unless you have a specific need. I wasrted 2 years not doing MCU's and nearly abandoned electronics all together because I dared not sin. Then I used a bit of mickrobasic and finally ended up on hitech C

I am actually wondering, what should I do if i wanted to look at AVR/atmel ? the website is as clear as mud and don't even cover the ground !

[madires]

assembler is a waste of time unless you have a specific need. I wasrted 2 years not doing MCU's and nearly abandoned electronics all together because I dared not sin. Then I used a bit of mickrobasic and finally ended up on hitech C

If you just want to get the job done, that's fine. But if you try to understand how MCUs work assembler is the best way to start. One doesn't need to become an assembler guru :-) You'll do C anyway later on.

I am actually wondering, what should I do if i wanted to look at AVR/atmel ? the website is as clear as mud and don't even cover the ground !

Really? I got no problems to find docs and stuff. There are websites much worse :-)

[Simon]

well I finally figured out where to find their software for which I had to register. I'll have a look.

Are AVR simpler register wise, that is the bit that bugs me on pics, I generally take so long getting all the correct registers setup

[madires]

Are AVR simpler register wise, that is the bit that bugs me on pics, I generally take so long getting all the correct registers setup

Yep, that's one of the main differences with a major impact on the MCU performance and the way of coding. Besides the datasheets and family overviews Atmel provides nice application notes about using all the different parts/functions of each MCU family. You might also have a look at an open hardware project as a starting point (hint for ATmega: http://www.mikrocontroller.net/svnbrowser/transistortester/ :-)

[Simon]

well providing I can code them in C without too much havoc I'd be happy. At the time i was told that PIC had more support, maybe atmel caught up.

[RCMR]

As others have said -- use C as your language.

By doing that, the individual architecture of each MCU becomes far less relevant.

You'll still have to fart around setting the right configuration bits to ensure you've got an I/O line operating as a digital connection rather than an ADC or an SPI port -- but other than that, using C will allow you to ignore the time-wasting details as to how many registers there are, whether memory is banked, etc, etc.  Ultimately, most of today's C compliers will produce pretty damned good code and if you plan to program MCUs for money then C is way more productive.

By going the C route, the choice between AVR or PIC becomes far less of an issue -- you can just select the best horse for the particular course you're trying to negotiate.

It'll also make the transition to more advanced MCUs such as the ARM-based families easier as well.

[Kremmen]

well providing I can code them in C without too much havoc I'd be happy. At the time i was told that PIC had more support, maybe atmel caught up.

Havoc? Assembler is the one causing havoc, not C or higher level languages. Forget the registers and assembler already  . Too much is made of assy and knowing every last bit of the HW architecture of a controller. Sure, knowing it all won't hurt, but almost always it is useless knowledge that you don't need for anything. What you do need to understand are the embedded peripherals and how to control them from C or C++ source level. Not a big deal as it is just a bunch of registers or memory addresses, IMO reasonably well documented in Atmel datasheets for each processor.
My recommendation: leave assembler and migrate over to C++ as fast as possible. That lets you design the program much closer to the problem space instead of wading in the spurious detailology of the particular processor implementation. What little assy you may need (so far, i haven't needed any) you can pick up quickly. At least with AVR-gcc there is no reason not to write in C++. One caution though - it looks like Atmel Studio 6 + JTAGICE3 does not support C++ yet. For some strange reason... No problems with Studio 5 and JTAGICE2 though.

[Simon]

well providing I can code them in C without too much havoc I'd be happy. At the time i was told that PIC had more support, maybe atmel caught up.

Havoc? Assembler is the one causing havoc, not C or higher level languages. Forget the registers and assembler already  . Too much is made of assy and knowing every last bit of the HW architecture of a controller. Sure, knowing it all won't hurt, but almost always it is useless knowledge that you don't need for anything. What you do need to understand are the embedded peripherals and how to control them from C or C++ source level. Not a big deal as it is just a bunch of registers or memory addresses, IMO reasonably well documented in Atmel datasheets for each processor.
My recommendation: leave assembler and migrate over to C++ as fast as possible. That lets you design the program much closer to the problem space instead of wading in the spurious detailology of the particular processor implementation. What little assy you may need (so far, i haven't needed any) you can pick up quickly. At least with AVR-gcc there is no reason not to write in C++. One caution though - it looks like Atmel Studio 6 + JTAGICE3 does not support C++ yet. For some strange reason... No problems with Studio 5 and JTAGICE2 though.

you didn't read my posts correctly, I am using C, I have used mikroC and hitech C. But I have to dissagree on the registers, you still have to mess with them and in the case of hitech C they couldn't be assed to write libraries to handle PWM and ADC modules which are probably the most popular periferals. So I still have to play with registers, and as for code interchangeability you have to hope they gave registers the same names or your buggared.

I'm just installing the AVR software and will have a poke at it. Anyone car to recommend a programmer ?

[mrflibble]

I suspect Kremmen meant the cpu registers as opposed to peripheral registers. So yes for pwm and such you still need to play with peripheral registers, but no you do not need to mess with the cpu registers. The latter is taken care of by your favorite C compiler.

[Simon]

so why do i have to write the configurations word(s), but they have more use than peripheral registers, if in mikroC I do an ADC read with the library I still have to tell the stupid compiler that yea, actually, that input was meant to be an input AND an analogue one! pointless.

But I would like to be able to tell it the speed I want.

[mrflibble]

so why do i have to write the configurations word(s), but they have more use than peripheral registers,

I dunno, you tell me. Lack of decent libraries?

[Simon]

are the copy cat avr programmers any good ? ebay is flooded with them

[elissaios]

Thanks for all the answers.

FInally ,
Finally,I found a guy at university and he will help me.He has an arduino but he dont use the language "wiring".He programs it in c.So its the same like he use atmega 328p.He is using bootloader to program it.

but I want to buy a avr programmer/debugger because i will buy more that one ?C's.?lso i want to buy an lcd 16x2.
Could you suggest me any good,cheap and popular programmer/debugger and a lcd 16x2?

Not a special lcd but a common because i want to find tutorials

[PuterGeek]

I would vote for an ARM Cortex processor. ARM MPUs are available from lots of different companies and are found in almost all cell phones and tablets. They are also available as embedded hard processors or as soft processors in FPGAs.

Very inexpensive boards with full IDEs are available include the TI Stellaris LaunchPad and NXP LPCXpresso series. The LaunchPad has particularly good learning support and the LPCXpresso is pretty good also.

The LaunchPad is $12.99 direct from TI (http://www.ti.com/ww/en/launchpad/stellaris_head.html) and is a little like Arduino with the BoosterPack (like Arduino shields).

There are several different LPCXpresso boards that start about $30 and can be bought from various distributors such as Digi-Key (http://www.digikey.com/product-search/en/programmers-development-systems/general-embedded-dev-boards-and-kits-mcu-dsp-fpga-cpld/2621773?k=lpcxpresso).

More of a leap from a learning standpoint, but you can also find inexpensive ful featured development boards like the Land Rover (http://www.ebay.com/itm/ARM-NXP-LPC1768-Cortex-M3-KIT-JLINK-On-board-AVR-DSP-MSP-C80h51-FPGA-STM32-/110924495694?pt=Art_Prints&hash=item19d39d7b4e) which has USB, Ethernet, color LCD, serial ports and CANbus. It is also available with a larger touchscreen LCD.

If you use the ARM CMSIS (Cortex Microcontroller Software Interface Standard) your code should be portable to any of the various Cortex processors (Actel, Atmel, EnergyMicro, Freescale, TI, etc.). A full list of ARM MPUs is here (http://www.keil.com/dd/search_parm.asp).

Open source tools are available in addition to the vendor supported tools. The Eclipse CDT IDE (http://www.eclipse.org/cdt/) is the basis of vendor tools like TI's CodeStudio as well as major commercial IDEs like CodeSourcery, CodeRed, IAR and many more. GCC (GNU Compiler Collection) is the basis for the tools I listed plus many more and ARM supports a free distribution (https://launchpad.net/gcc-arm-embedded) that is updated regularly.

Anyway, my 5 cents (inflation).

[RCMR]

I'm still waiting for my STM32 Discovery board to arrive so haven't looked but how do the range of useful libraries for the ARM chips compare to those which are readily available (and built in to compliers such as the Hitech C) for PIC and the like?

ie: if you want to read an ADC,  do some simple processing on the numbers and then write them to a QVGA LCD -- how much of the code will simply be library calls and how much will be stuff you have to write (reinvent) yourself for the ADC/LCD routines?

[Kremmen]

you didn't read my posts correctly, I am using C, I have used mikroC and hitech C. But I have to dissagree on the registers, you still have to mess with them and in the case of hitech C they couldn't be assed to write libraries to handle PWM and ADC modules which are probably the most popular periferals. So I still have to play with registers, and as for code interchangeability you have to hope they gave registers the same names or your buggared.

I'm just installing the AVR software and will have a poke at it. Anyone car to recommend a programmer ?

Yes i did read it but my reply was more like a general rant about assembler. Sorry about that. And yes you do need to mess with the registers of the embedded peripherals like pwm generators/timers and stuff. Because there is no other way. Of course Atmel for instance have their ASF framework support if you want to use that. What i meant that you can forget the general purpose registers completely because the compiler will do the housekeeping for you. 99.9% of the time and unless you are into more exotic stuff such as writing hypervisors/ OS kernels and stuff.

As for programmers, i got the STK600, JTAGICE 2 (and 3) and never looked back All of those will program any Atmel AVR processor and some of them ARMs as well. Of course there are cheaper alternatives, AVRDude being a popular one afaik.

[westfw]

I'm a big believer in the Arduino boards.

1) The arduino hardware is a reasonable piece of hardware that accommodates several AVR chips (and the AVR is a reasonable first microprocessor.)
2) You don't have to use the Arudino IDE just because you're using arduino hardware.
3) You don't have to use the 'wiring' libraries just because you have arduino hardware.
4) Studying the way that the Arduino libraries and core work can be particularly educational.
5) Studying the (assembler) code produced by Arduino "sketches" is also educational.
6) in fact, you can think of an Arduino sketch as a "design document" on the way to actually implementing your code in pure C or assembler.  Like a flowchart, or pseudo-code.
7) Many of the Arduino "tutorials" are more about the chips and devices being interfaced to than about the Arduino itself.  So they're useful (as "pseudo-code") even for non-Arduino based code.  An arduino tutorial about LED current limiting resistors, or relay switching, is just as valid for a bare AVR (or any other CPU, really.)
If the going is tough in pure C or assembler (someone mentioned "too many registers to set"), then you have the Arduino simplification to fall back on, in case you'd still like to actually DO something.

[Galenbo]

Someone had mentioned that http://www.mikroe.com/ is a good place to begin. It offers tutorials, book, kits, etc.

I use that too

[Simon]

Someone had mentioned that http://www.mikroe.com/ is a good place to begin. It offers tutorials, book, kits, etc.

I use that too

they are good for starting but the libraries are crap

[mrflibble]

ie: if you want to read an ADC,  do some simple processing on the numbers and then write them to a QVGA LCD -- how much of the code will simply be library calls and how much will be stuff you have to write (reinvent) yourself for the ADC/LCD routines?

I'm still far from being really proficient with the STM32, but for the ADC part at least things are okay. For setting up the ADC you can use STM32F4xx_DSP_StdPeriph_Lib calls. In a current project I also have the "sample stuff and do some processing". For that you can use DMA + double buffering. The ADC is sampling and writing to buffer A, and in the meantime you can crunch the numbers collected in buffer B.

To be honest, the StdPeriph calls are still all about setting up config registers. Just in a way that I find is a bit more readible + maintainable than writing straight to the hardware config registers.

I do currently find I need something more, like threads to handle commands entered via uart. So maybe ChibiOS/RT...

[Simon]

I remember a big thread (row) we had on here where someone belittled 8 bit MCU's. Personally I think they will always have a place, particularly as more and more "electronics people" are more programmers and digital only people and tasks even simple that could be done with "discrete" electronics can end up on a cheap 8 bit micro like time delays or the old flashing LED.

Sure there are more and more complex applications but the simple jobs will always exist. I've downloaded Atmel studio and will have a tinker, I guess i need to buy another bloody programmer (I may sell my pickit3 again) but it looks like Atmel have made some serious effort at making their micros and it's tool chain more user friendly. Indeed, I recently did a design (no software yet just physical layout so that we can quote the customer) and I had to change from a 16F88 (18 pin) that has enough pins to a 16F883 (28 pin) simply because the damn things didn't have enough ADC channels, it also take such a larger pic to get 2, yes just 2 PWM channels where as AVR's seem to have quite a few even on 20 pin devices.

[andersm]

I remember a big thread (row) we had on here where someone belittled 8 bit MCU's. Personally I think they will always have a place, particularly as more and more "electronics people" are more programmers and digital only people and tasks even simple that could be done with "discrete" electronics can end up on a cheap 8 bit micro like time delays or the old flashing LED.

I'd say the opposite. If you have a strong programming background, the 32-bit MCUs offer an environment more like the desktop, and with far fewer of the quirks inherent in shoehorning C into an 8-bitter. For hobbyist purposes there's no real price advantage either. However, the popularity of the AVRs kind of make it into a self-perpetuating success.

[Simon]

you mean 32 bit is as cheap and easy with atmel ?

[mariush]

Often, the 32bit chips are not breadboard friendly, so for a person that just starts to work with microcontrollers, the 8 bit ones are just fine.

I'm playing with 8 bit PIC chips and the MPLAB X supports C just fine, and the compilers also work fine (Hi-Tech C compiler, XC compiler etc).

I would recommend going for a kit that contains the programmer and a ready made pcb with a microcontroller.

For example, this kit contains the programmer, cable, CD with manuals and examples and the software (but you should get the latest MPLAB X from the website, it's free) :

http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=DV164131
http://www.microchipdirect.com/ProductSearch.aspx?keywords=DV164131

If the microcontroller provided on the sample pcb seems too complex for you, you can basically buy other PIC microcontrollers for as low as $0.20, put them on a breadboard and connect the programmer to it using 4-5 wires. The whole process is very easy and explained in the programmer manual and in the PIC controller datasheets

I actually bought this kit and to this day (months later) I didn't touch the board that came with it.

It was easier to get get a PIC16F1519 that I had around (8 bit microcontroller in DIP40 package), put it on the breadboard, get a few wires to make the connection between the programmer and the pic and simply load some sample code that came with the MPLAB X package in Hi-Tech C compiler's folder.  Just had to change a line of code to get a LED running, it was as simple as that.

[andersm]

you mean 32 bit is as cheap and easy with atmel ?

The Cortex-M0s are quite cheap. "Easy" is subjective, but I don't remember having more difficulties getting started with the Cortex-M3 than with ATmegas. However I've been doing this long enough that reading data sheets and accessing hardware registers directly is my preferred way of working. I recall running into some minor gotchas regarding the AVR C implementation, but I don't remember the details.

[PuterGeek]

A problem with Microchip are their non-standard C extensions. All compilers have them to some degree or another but AFIR Microchip is in their own little universe. I would recommend sticking with GCC or one of the derivatives. I don't think Microchip is any danger of going under but they are the only game for PIC devices. And then you get into the 'flavors' where you end up needing 3 or 4 compilers. OK, can you tell I don't really care for PICs?

As far as 8 bit vs. 32 bit micros, the 8-bit manufacturers that make them will hawk them as long as there are buyers. The low cost advantage they had is quickly vanishing which makes it a harder sell. Sure the 8-bitter can handle the task but so can a 16-, 32- or 64-bit processor. If you can get a Cortex-M0 for the same price as a PIC and it has the feature you need why wouldn't you use the M0?

I don't recall many dip packages available for anything but PIC, Atmel and a few older parts. Adapters are available to allow breadboarding SMD packages.

Because of little volume demand, thru hole parts are becoming uncommon for new devices unless they have some unique advantage. For instance, thru hole power devices are easier to mount to a heatsink. I would recommend everyone adapt to surface mount. Yeah, the tiny parts are a pain, especially when you get older (bad vision, less stable hands, etc. [and yes I mean me]) but fewer and fewer parts will be available in thru hole.

[PuterGeek]

...so haven't looked but how do the range of useful libraries for the ARM chips compare to those which are readily available (and built in to compliers such as the Hitech C) for PIC and the like?

ie: if you want to read an ADC,  do some simple processing on the numbers and then write them to a QVGA LCD -- how much of the code will simply be library calls and how much will be stuff you have to write (reinvent) yourself for the ADC/LCD routines?

The ideal behind the ARM CMSIS is a standard way to manage peripherals amongst ARM suppliers. The latest version also adds interfaces to RTOS and DSP libraries. It doesn't however cover much else like an LCD.

There are lots of frameworks for managing other devices, from free to very expensive. The TI Stellaris libraries are very complete and well integrated into Code Composer. They are free as long as you are using their chips.

TI and Atmel probably have the best IDE integration since they are the only ones really offering their own tools. NXP LPCXpresso products use CodeRed and Freescale seems to support just about every IDE possible.

[westfw]

The ideal behind the ARM CMSIS is a standard way to manage peripherals amongst ARM suppliers.

My impression was that CMSIS is an attempt to manage the STANDARD "peripherals" that are part of the ARM core, like the SYSCLK and NVIC.  There's a very wide variation in the non-core peripherals (UARTS, I2C, SPI, even GPIO) that makes standardization very difficult.  (Oh, for instance, Atmel's "GPIOs" are handled by a "parallel IO controller", while TI Stellaris chips have more traditional memory mapped registers echoed by the pins, with bit-banding to do single bit manipulation.  You can wrap an abstraction around them both, but it might as well be Arduino's "digitalWrite", and a significant portion of the population would be upset that you're interfering with code efficiency.

[BravoV]

In the next 5 to 10 years, I'm guessing that we are going to see the 8-bit/16-bit MCU market severely eroded by the low-end 32-bit MCUs on new designs.

Probably by that time, the current 8-bit/16-bit generation will looked like the ancient 8051 as we see today. 

[andersm]

My impression was that CMSIS is an attempt to manage the STANDARD "peripherals" that are part of the ARM core, like the SYSCLK and NVIC.

CMSIS started out as an effort to create a standard set of peripheral interfaces. However they only ever managed to create a debug-uart driver, and even that was retired in the next release.

[mrflibble]

I remember a big thread (row) we had on here where someone belittled 8 bit MCU's. Personally I think they will always have a place, particularly as more and more "electronics people" are more programmers and digital only people and tasks even simple that could be done with "discrete" electronics can end up on a cheap 8 bit micro like time delays or the old flashing LED.

Well, sortof. Sure 8-bitters will be here to stay for quite some time. But if you are talking hobby, and as a first platform ... it does make sense to pick something that could do all the stuff a smaller 8-bitter could do AND some cool stuff that the average 8-bitter could not do.

Hey, and no dissing the blinkie! My first "app" on this here 32-bit ARM was a blinkie. My first app will probably always be a blinkie. The ole debug printf() took a bit longer on that particular platform however. grrrr. First thing on fpga boards is always a led blinkie too, now that I think about it. So lets call it tradition. ;-)

Anyways, as a "my first mcu in 2012" I'd say a 32-bit arm makes more sense than an 8-bit whatever. The reason I recommended the 16-bit msp430 earlier in the thread is that it's big enough to do some fun stuff AND has an easier toolchain to get going with straight away.

So in retrospect maybe the OP should just get both a msp430 launchpad and a stm32f4 discovery board for under 20 euro total. Start with the 16-bitter real quick and use it for some tasks, and have the 32-bitter for the bigger stuff at the expense of a slightly steeper learning curve.

[mark5009]

There is an old saying that to a hammer, everything looks like a nail.  There are those that say you got to have a 32bit CPU and you have to code in C.  Rubbish.  You choose the tool for the job, designed to fit within the project design constraints, be they time, money, or any other parameter that happens to be around (like deep space radiation, etc.).

As an engineer, get away from the idea that C is the be-all and end-all of coding.  It isn't.  What it does is force processors into an artificial imitation of a PDP-7 (it was designed as a portable assembler for UNIX).  It is a fine language but there are many others that do a great job, and plenty of others where you will learn more (if that is your objective).  Examples include JAL and Forth, though there are lots of others.

Yup.  I know.  Heresy.  Get over it, folks.  Learn to be flexible in your tool choice and the world opens up.  Trust me on this one.  :-)

 .. mark

[RCMR]

There is an old saying that to a hammer, everything looks like a nail.  There are those that say you got to have a 32bit CPU and you have to code in C.  Rubbish.  You choose the tool for the job, designed to fit within the project design constraints, be they time, money, or any other parameter that happens to be around (like deep space radiation, etc.).

If you're a hobbyist then using assembler for the MCU of your choice is probably fun.

However, as someone who values his time, the use of a higher-level language such as C is a commercial necessity if you want a half-reasonable return on that time.

The reality is that most half-decent C compliers produce code that is virtually as good ( and often better) than hand-coded assembler -- especially when working with awkwardly architectured MCUs.

While I have no doubt there are instances where C won't be the best tool for the job -- I've yet to encounter one.

The *big* plus of C (or other HLL) is that you don't have to learn a new (assembly) language when required to work with a different family of MCU.  You do have to learn a new set of configuration registers (or perhaps libraries) -- but the core syntax and sematics of the actual programming language remain a constant.

Time is money as they say -- and I know of few people who can afford to throw time away by making things harder than they need be.

[mrflibble]

The *big* plus of C (or other HLL) is that you don't have to learn a new (assembly) language when required to work with a different family of MCU.  You do have to learn a new set of configuration registers (or perhaps libraries) -- but the core syntax and sematics of the actual programming language remain a constant.

Time is money as they say -- and I know of few people who can afford to throw time away by making things harder than they need be.

Exactly that! I look at the generated assembler every now and then to see if it is anywhere close to something reasonable (*), but apart from those short excursions I comfortably stay in the land of the lazy & pragmatic.

*) mostly to check if my assumptions about them compiler flags are reasonable.

[mark5009]

Time is money as they say -- and I know of few people who can afford to throw time away by making things harder than they need be.

Sure, this is the crux of the argument.  Though I would question your negative assert of "throw time away by making things harder".  My return question is, at what cost? 

You are choosing to make a compromise (ease of learning).  What are the trade-offs?  Do you indeed hop around from processor to processor?  Are your requirements such that you can live with the overhead that your standard library imposes?  Are you okay with how the, potentially unknown, implementers have created the library routines that you are using? 

Sometimes the compromise is perfectly okay.  At others, it is not.  But if you are not prepared to ask the question and understand the implications, then you can easily wind up in a hole. 

(Please don't take this as a personal attack.  It is not meant as such.  This is more of a heads-up to the OP from a guy who has been around the engineering block for a while...)

  .. mark.

[RCMR]

Mark, the beauty of the MCU market at the moment is that if you find your overheads are biting -- just switch to a faster/bigger chip and those issues go away.

Yes, there may be a small price-penalty for moving from (say) an 16F688 to an ARM Cortext M0 -- but not much, unless you're talking about a projected run of tens of thousands or millions of units.

I went through this whole process back in the 1980s -- when, to get decent performance out of the early desktop PCs you had to resort to hand-cut assembly code in many of the crucial areas.  Then faster processors and cheaper memory came along -- plus more efficient (optimising) compilers -- and the problem went away.

Sure, if you're looking to save every possible cent in terms of your hardware cost and you can amortize your code-development costs over millions of units then it might make sense to cut assembly code by hand -- but I suspect that the vast majority of those here are cutting code for 1-off or small production runs -- where every hour saved during the coding/debugging stage means dollars saved on each unit finally shipped.  In those situations, using an MCU that costs $2 more but which will half your software development time by allowing the use of an HLL like C makes lots of sense (and cents)

[nctnico]

I couldn't agree more. I see lots of people trying to cut cost on a controller to save pennies on a production run of maybe a couple of hundred units. They totally forget about engineering time which costs a lot more.

Regards C I have mixed feelings. It is very portable and a de-facto standard but also prone to errors with pointers. Using C++ in the right way helps to avoid most pointer problems but I think that script languages like Lua make more sense. I think I'll take embedded Lua for a spin when I have some time on my hands.

[SherlockOhms]

The TI Launchpads (the original MSP430 variants) are also very good for beginners who want to dive a little deeper than the Arduino. You have the programmer and debugger directly on board, can program a variety of different microcontrollers with it, which are all socketed in case you want to use them stand-alone later, and the development environment it comes with is decent as well.

As a total MCU beginner myself, I'd give a thumbs up to the TI MSP430 launchpad. For $4.30 it's worth a fling for anyone who's even remotely interested in learning microcontrollers and you can put the rest of your learning budget towards project parts and maybe a good reference book. There's enough examples and tutorials available on-line to get rolling.

[titam]

+1 on Launchpad.  Easy, minimal investment.

[madires]

Regards C I have mixed feelings. It is very portable and a de-facto standard but also prone to errors with pointers. Using C++ in the right way helps to avoid most pointer problems but I think that script languages like Lua make more sense. I think I'll take embedded Lua for a spin when I have some time on my hands.

It's more a matter of the capability of the person writing the code. There's no foolproof programming lanuage for beginners. You can't blame just pointers to be the source of all evil :-) Pointers are a really great and efficient method to deal with data and functions. And if you're allowed (by the programming language) to do some dirty magic you can solve some problems very easily (also faster code and fewer bytes) while another language forces you to write a complete novel.

[RCMR]

Yep, with languages it's horses for courses.

Languages with strict bounds-checking and perhaps automated garbage collection (eg: Modula2, etc) are more suited to applications which involve complex data-structures and a lot of dynamic memory allocation.

C is (IMHO) the best alternative to assembler when you want to cut the fastest code and retain maximum control over how your processor handles things.

As for managing memory allocations, ensuring pointers are correctly referenced etc -- well that's down to programmer discipline and good practice.  A bad programmer can write bad code in any language.

One thing I found when moving from PC-based systems to MCU-based ones is that life is much simpler in the MCU world.  The interface between the MCU and "the real world" is usually far more clearly defined and the absence of "wetware" in the input stream makes it far easier to come up with a solid specification in the first place.

I wouldn't write an accounting suite in C (although I have been forced to in the past) and I wouldn't write a realtime MCU-based process controller in COBOL either :-)

[Galenbo]

Someone had mentioned that http://www.mikroe.com/ is a good place to begin. It offers tutorials, book, kits, etc.

I use that too

they are good for starting but the libraries are crap

Could you please specify this? I used a lot of their libraries, almost no problems.
On Their forum you see sometimes minor complaints, but there are other options now with their Libstock.

[croberts]

I use the PIC16F690 to control all of the solar powered LED lights in my home via a networked master/slave system. All of the code was written in assembler using MPLAB and a PICSTART Plus programmer. I like the low overhead and device level control of assembler. I still have over half the programming space remaining in the master controller.

[brainwash]

For the future people reading this thread let me put a history of some of the embedded platforms I've used for hobby purposes and lessons learned:

1) PIC16F84 + RS232 programmer - I paid a lot of money for the ancient chip (it was 10 years ago and it was already ancient).  It needs crystal and caps to be able to do something.  Spent most of the time fiddling with wires, getting the chip in an out of the programming socket, reading assembler code examples.

Firmware upgrade time took about 2 minutes, including chip swapping.

Lessons learned: get the newest pin-compatible chip. Try to aim for integrated oscillator and wide operating voltage range. Go for the biggest memory given the same footprint.


2) AVR Butterfly - this was a complete dev platform based on an AVR Mega169. It was pretty similar to how Arduino is today BUT it had also some necessary peripherals included: display, buttons, piezo, battery. I spent most of the time trying to set up the toolchain and study the incredibly complicated examples (for a beginner) to make something useful. I picked it up again two years ago was able to program some stuff on it with the experience I gained in the mean time.

Firmware upgrade time took about 30 seconds, as I remember.

Lessons learned: integrated hardware helps a lot, so it pays to buy a thing that has most of the stuff you want included. You will want an LCD and buttons, you will want easy USB uploading. Toolchain and user support makes all the difference for a beginner.


3) PIC16F628 + PicKit2 - pretty rewarding experience because there was already a lot of support back then (5-6 years ago) for PIC MCUs. The pickit is especially nice because it can power the breadboard project, view the outputs on its signal analyzer, view the debug data on its RS232 terminal. Whenever you feel like experimenting with a new PIC just pop out the old chip from the breadboard and plug in a new one. Then spend some time rewiring because every pin is in a different place.

Went through MPLAB, asm, HiTech Picc, SourceBoost, back to MPLAB X because no toolchain provided exactly what I wanted for specific projects. SourceBoost had a nice IDE but the compiler was not free and the simulator was buggy. MPLAB had an accurate simulator but awful IDE. Microchip's ASM compiler was free but what hobbyist uses assembly? (except for fun or challenge). PICC was nice but VERY limited in its free version and costs a lot of money for the paid version (as far as I remember).

Firmware update time: about 15 seconds, I had to manually switch to the PicKit tool.

Lessons learned: a tool that offers the basic electronics bench tools is well received. Ok, a soldering iron and a multimeter might be in every house (though not necessary) but a nice power supply, signal analyzer and scope are not. Productivity and learning go up as fiddling time goes down. Switching compilers and IDEs is a pain, every one has different coding conventions, shortcuts, names for pins.


4) MSP430 launchpad - I don't remember ever using it. I got it two years ago because it was cheap. I might go back to it, see the stellaris section.

Lesson learned: unless the new dev platform offers more than the previous platform you are used to it will stay unused. In my case the low-power stuff wasn't very interesting and the board wasn't particularly powerful compared to the PICs I used. I also had to learn a new IDE (TI proprietary stuff) and coding style.


5) Stellaris Launchpad - this one stayed in my drawer as well for a few months. Then I watched some tutorials and got interested in its capabilities. After installing the toolchain I saw that it was actually Eclipse in disguise, a tool I've used almost every day for the past 8 years or so.
The board is quite overpowered but has a pretty low community support so I had to struggle with it. What kept me going was the familiar Eclipse environment and STEP BY STEP debugging. I cannot overemphasize the importance of this, being able to step through your code and check the memory and registers after each line. And on the REAL unit, not in the simulator.
Oh, firmware uploading time is about 2 seconds, the time it takes for the project to build.

Given that I know understand what the Stellaris[ware] ideology is like, I might go back to the MSP430 to use it for low-cost, low-power projects. It's most of the times cheaper than having your own design.

Lessons learned: choose a tool with a well-supported IDE. If you don't know what, choose Eclipse, it's pretty much industry standard and free, with support for a lot of languages from ASM to PHP and really nice code automation features. Choose something with step-by-step debugging whenever possible, it will make life a lot easier.


6) Arduino - I don't have one and will probably not have one unless it's very cheap or absolutely needed for something. BUT, it would be first on my beginner recommendation choice. It is like I recomend iPads to non-tech savy friends seeking advice for a tablet, even though I haven't used iOS in years.

It has the best community support, most hardware projects that you can just copy and paste, every add-on imaginable and bearable tools.
I think the only downside is the price, you are practically paying a premium for all this stuff. However, once you are confident enough you can build your own 'Arduinos', which are actually just a bootloader on a 3$ chip and some surrounding stuff.
That still leaves the problem of shields, which have again a pretty high markup just for bearing the 'shield' or 'arduino compatible' tags. But again, with consumption comes volume and competition which helps to bring the prices down and quality up.



I do have some other stuff in my drawers that I've never touched (like TI Chronos) so it makes sense to buy once and buy smart.
The MikroE stuff is very nice, but Arduino is now like an industry standard and I would choose a good community support over an good commercial support any time.

Phew, that'a long rant, I might be getting bored.

[brainwash]

Perhaps I should add the higher end development platforms here: Raspberry PI and Android.

Raspberry PI:
Very nice hardware capable of doing most of the stuff a beginner would want to do. Currently it is still of a learning curve setting up the toolchain but it's getting there. It has GPIO and that all that you need for blink-a-led. It has HDMI and provided that every house has a modern TV, DVD player or home cinema you should have the display and sound part solved.
If you get bored of it you can still set it up to serve your USB hard drive over the network or some similar utilitarian projects, so it should not end up in a drawer.

Android:
It took me about 30 minutes including reading the tutorials to have my first program running on the phone. Well, that's also because I'm very used to Java, but it shouldn't take much more for anyone.
It doesn't have GPIO, so you can't really blink a led or control a motor but it's more of a unifying platform, because you can control your bluetooth and wireless projects via a touchscreen.
Cost-per-hardware is as inexpensive as it can get. I bought a new phone for 50E and it has the following features: WiFi, Bluetooth, 480x320 color touch screen with backlight, three capacitive buttons, four hardware buttons, two cameras, two speakers, microphone, light sensor, close proximity sensor, temperature sensor, stereo out, mono in, accelerometer, compass, 3G connectivity, one week battery life. For those wondering, it's the Huawei Ideos X3.

[westfw]

"Pointers are a really great and efficient method to deal with data and functions."

And unfortunately, NOT a good way to deal with strings.  At least, not as is usually done...

[madires]

"Pointers are a really great and efficient method to deal with data and functions."

And unfortunately, NOT a good way to deal with strings.  At least, not as is usually done...

You have to deal with buffer overflows anyway. Or have I missed what you're talking about?

[nctnico]

"Pointers are a really great and efficient method to deal with data and functions."

And unfortunately, NOT a good way to deal with strings.  At least, not as is usually done...

True. I have several functions and wrappers to prevent buffer overflows.

[westfw]

NOT a good way to deal with strings.

You have to deal with buffer overflows anyway. Or have I missed what you're talking about?

No, you wouldn't.  Or not fatal ones, anyway (comparing to other languages, like BASIC, here.)  That's on top of being difficult to use.  Strings are a fundamental enough data type that they should have (IMO) more fundamental support built into the language.  Having to write:

Code: [Select]

  dest = realloc(strlen(dest) + strlen(src) + 1);
  dest = strcat(dest, src);Instead of

Code: [Select]

dest = dest + src;is ridiculous, and displays fortran-era thinking.  In any language there should be a treatment of strings that allows users "typical" usage, without having to worry about the tools behind the curtain, or pointers, or details of the dynamic memory allocation system, or the details of the structures actually use to implement strings.  This is probably getting into a weight of run-time-environmemt that the C designers were uncomfortable.  But other languages (BASIC, PL/1, PASCAL, and on and on) didn't seem to have huge problem doing it in a useable and reasonable way.

   

[Kremmen]

String handling is one of C's weakest points, that's for sure. Not much can be done since that is the way the language has been defined and it is too late to think about changing it.
C++ to the rescue. If the default string classes don't work for you, just roll your own, or extend the existing implementation with your own functionality.

[andyturk]

C++ to the rescue. If the default string classes don't work for you, just roll your own, or extend the existing implementation with your own functionality.

C++ strings on a micro? Yikes.

Personally, I'd say that C strings are exactly what you want (on a microcontroller) for dealing with text that doesn't change (i.e., string constants). When you start talking about streams of text that are sent/received with the outside world via UARTs or whatever, you should probably be thinking in terms of buffer objects.

[Kremmen]

C++ to the rescue. If the default string classes don't work for you, just roll your own, or extend the existing implementation with your own functionality.

C++ strings on a micro? Yikes.

Personally, I'd say that C strings are exactly what you want (on a microcontroller) for dealing with text that doesn't change (i.e., string constants). When you start talking about streams of text that are sent/received with the outside world via UARTs or whatever, you should probably be thinking in terms of buffer objects.

If you are happy with the C string then you have no problem. My reply was meant to suggest an alternative for those who do have a problem. While the C++ std::string might be a bit on the heavy side in a modest 8 bit MCU, i don't see a problem in writing a basic string class around say a Pascal style string where you have the length stored explicitly. The few bytes needed to store the vtable shouldn't matter unless you truly have heaps of dynamic strings. The upside is that you can hide all kinds of implementations in the inheritance tree, from simple fixed allocation strings to as dynamic and mutable as you want to have. And of course the differences are hidden by the polymorphic access methods. Look at Arduino for instance; it has a string class, and the 328 inside an Arduino is far from a powerhouse MCU.

[andyturk]

... The upside is that you can hide all kinds of implementations in the inheritance tree, from simple fixed allocation strings to as dynamic and mutable as you want to have.

If you can use std::string without dynamic memory allocation or exceptions, then perhaps its OK. I suspect that's not the case though, and both of those are deal-killers for "serious" embedded work.

Look at Arduino for instance; it has a string class, and the 328 inside an Arduino is far from a powerhouse MCU.

True, but the Arduino is more of a hobby/learning platform that intentionally relaxes some of the usual requirements of embedded development.

[madires]

NOT a good way to deal with strings.

You have to deal with buffer overflows anyway. Or have I missed what you're talking about?

No, you wouldn't.  Or not fatal ones, anyway (comparing to other languages, like BASIC, here.)  That's on top of being difficult to use.  Strings are a fundamental enough data type that they should have (IMO) more fundamental support built into the language.  Having to write:

Code: [Select]

  dest = realloc(strlen(dest) + strlen(src) + 1);
  dest = strcat(dest, src);Instead of

Code: [Select]

dest = dest + src;is ridiculous, and displays fortran-era thinking.  In any language there should be a treatment of strings that allows users "typical" usage, without having to worry about the tools behind the curtain, or pointers, or details of the dynamic memory allocation system, or the details of the structures actually use to implement strings.  This is probably getting into a weight of run-time-environmemt that the C designers were uncomfortable.  But other languages (BASIC, PL/1, PASCAL, and on and on) didn't seem to have huge problem doing it in a useable and reasonable way.

You can't have it all :-) C coders should use safe string functions and/or write their own convenience functions to deal with strings. If you prefer a language which does all the string magic for you, you don't need to worry about the details, i.e. you get the job done faster, but the compiler creates larger binaries and the program runs slower. If you have to deal with string details yourself you got full control and also the key to optimize things. Since most C coders already invented their wheels they simply recycle that code and it won't take much longer to finish the job.

BTW, there's one point with strings where all languages suck: parsers. 

[Kremmen]

If you can use std::string without dynamic memory allocation or exceptions, then perhaps its OK. I suspect that's not the case though, and both of those are deal-killers for "serious" embedded work.

std::string won't work without a heap since it allocates the char arrays from there. As to the general principle of avoiding dynamic memory like the plague, i'm not so sure. Try writing an embedded Ethernet implementation without dynamic buffers (the thing i happen to be working at this time). Can be done i guess, but IMO that would be shooting yourself in the other foot. The bogeyman in dynamic allocations everyone seems to fear is a) the undeterministic nature of the allocation itself and/or b) memory overruns/leaks. True, they can be problems but those issues are far better controllable in C++ since it supports some of it in the syntax. You need to pay attention to your allocation algorithms and strategy but if you can be happy with less than fully flexible heap with garbage collection and suchlike, relatively foolproof implementations are possible. But yes, i grant the point that with dynamic memory, badly behaving code can kill the app. Of course if you use a MCU with memory protection and are willing to handle the exceptions...

[...]
True, but the Arduino is more of a hobby/learning platform that intentionally relaxes some of the usual requirements of embedded development.

That was only an example. Once again: roll your own and be happy. Or if not, you can blame the guy in the mirror

[nctnico]

At one of my former employers I wrote a linked-list dynamic memory handler. It has its own API to walk through linked blocks of memory and in the end I also had malloc, realloc and free working while keeping memory consumption completely in check.

[Kremmen]

Did the a similar thing for a lowly Arduino. A camera dolly controller where all the control actions were implemented as a dynamic linked list with persistence into the EEPROM. Since i used C++ it was a class tree with inheritance and new, delete implemented using malloc and free. Worked like a charm.

[andyturk]

std::string won't work without a heap since it allocates the char arrays from there.

That's what I thought. I've looked at the std::string code a few times, but like a lot of STL it takes a long weekend and several pots of coffee to actually figure out how it works.

For server-side programs, std::string (with exceptions) is just fine. When I used to do Java stuff, I had no problem with Java's String, which has equivalent magic inside. But when you're driving a car with an automatic transmission, you can't really complain about the power brakes. 

As to the general principle of avoiding dynamic memory like the plague, i'm not so sure. Try writing an embedded Ethernet implementation without dynamic buffers (the thing i happen to be working at this time). Can be done i guess, but IMO that would be shooting yourself in the other foot.

Ha! Well, one of my current projects is fixing up a Bluetooth HCI stack that runs on MSP430. Every packet is malloc'd and free'd, which is potentially dangerous because there's tremendous opportunity for heap fragmentation. 8K of RAM and they're hitting the memory allocator several times a second even when the RF is quiet. I didn't write this code, it's just my job to fix it.

It's certainly possible to "prove" that your malloc/free new/delete calls aren't going to fragment the heap and crash your device. But once you get to that level of certainty, you've already done most the work to statically allocate pools of objects. For me, the static allocation issues are more familiar and I'd rather start off that way than be forced to go there when things break.

[andersm]

If you can use std::string without dynamic memory allocation or exceptions, then perhaps its OK. I suspect that's not the case though, and both of those are deal-killers for "serious" embedded work.

But this subthread started from westfw wanting "dest = dest + src;" semantics for strings - at that point dynamic memory allocation is already a fact of life.

[Kremmen]

[...]

Ha! Well, one of my current projects is fixing up a Bluetooth HCI stack that runs on MSP430. Every packet is malloc'd and free'd, which is potentially dangerous because there's tremendous opportunity for heap fragmentation. 8K of RAM and they're hitting the memory allocator several times a second even when the RF is quiet. I didn't write this code, it's just my job to fix it.

It's certainly possible to "prove" that your malloc/free new/delete calls aren't going to fragment the heap and crash your device. But once you get to that level of certainty, you've already done most the work to statically allocate pools of objects. For me, the static allocation issues are more familiar and I'd rather start off that way than be forced to go there when things break.

I am not suggesting that it wouldn't be a good idea to allocate the memory statically. One strategy is to assign a pool of buffers and just reserve and release them (inside the implementation, but not in the sense of generic dynamic resources). Another successful (dynamic) scheme is to only allocate/free a set of discrete block sizes. That way the heap won't actually fragment because there is always a correctly sized block in the free pool. You just have to see that the allocator is able to pinpoint it (or create one of course, if a free one doesn't exist). This does not avoid the problem of exhausting the heap, but it does mitigate fragmentation.

[westfw]

But this subthread started from westfw wanting "dest = dest + src;" semantics for strings - at that point dynamic memory allocation is already a fact of life.

It doesn't have to be.  "Strings" could always be MAXCHARS long, for instance.
It is a common aspect of poor software engineering to think that a feature should do all things for all purposes.  I'd be perfectly happy to let "complex" string tasks be relegated to pointers to dynamically allocated regions of bytes, if only the "simple" little string tasks that show up in almost all programs could be done safely by beginners without having to understand all the things that can go wrong with pointers.  (recently seen: "char *mystring;  sprintf(mystring, "%i %i", 99999, 12345);")

BASIC has reasonable string support, for instance.  EAGLE's ULP language looks like C, but has (reasonable) strings added.  It can't be that hard.  People just get hung up on stuff like "it'll have to have automatic garbage collection, and carefully avoid fragmentation of the dynamically allocated memory, and be absolutely as efficient as inhumanly possible, and..."

[nctnico]

But this subthread started from westfw wanting "dest = dest + src;" semantics for strings - at that point dynamic memory allocation is already a fact of life.

It doesn't have to be.  "Strings" could always be MAXCHARS long, for instance.
It is a common aspect of poor software engineering to think that a feature should do all things for all purposes.  I'd be perfectly happy to let "complex" string tasks be relegated to pointers to dynamically allocated regions of bytes, if only the "simple" little string tasks that show up in almost all programs could be done safely by beginners without having to understand all the things that can go wrong with pointers.  (recently seen: "char *mystring;  sprintf(mystring, "%i %i", 99999, 12345);")

If you ever programmed with Delphi you can see where that leads to: about 4 or 5 different string types each with a bunch of conversion functions and each has its unique features you'd like to have in the other. On the other hand: universal is good until is becomes a quest for the holy grail.

[goesfast]

I started with an Arduino starter kit. I highly recommend it! The controller is and code is VERY well documented on the arduino web site. Now I play with all sorts of microcontrollers. Learning code with it paved the way for learning other languages. Just my $0.02

[ktulu]

I started with a PIC16F84 more than 10 years ago, and I still belive it is a very good choice to begin with. Even though it is a very outdated uc, it has an extremely low amount of built in hardware peripherals. Therefore very few registers, which usually gets beginners confused. A very simplistic, low register count, low instrunction count, with tons of project on the internet. So if you can grab one cheaply, (becouse there are far more powerful modern uc's much cheaper) it is a very good controller to start with.

[FrozenHaxor]

I would recommend PICKit or just a USBAsp programmer and go with bare AVRs - best way of learning is to implement the chip itself without any shield garbage around it!

Start with something small like the ever popular ATMega 8 or ATTiny series chips.

[EExtrom]

MSP430 launchpad ... you can get it for only 5€!!!
Its NOT worth NOT trying it 

[Frollard]

AS recently posted on hackaday:  I'm with Atmel/arduino camp simply for the reason there are scads of example circuits and programs that (in my experience) make learning new stuff easier.  For a book to teach me the constructs of the C without showing a full example is much less helpful for me than just pulling up an example program and working out (well commented) code from there.

The tradeoff with affordability of dev boards vs the raw processors is getting a lot better - I'm even a big fan of the teensy series being able to cram a 32 bit 96mhz arm processor into a 19 dollar breadboard package.

[MikeK]

I always recommend PICAXE for beginners.

It's very cheap.
Huge archive of posts and projects.
Good support forum.
If you grow out of it or toast the bootloader you then have a PIC to use.

[melonstorm]

MSP430 launchpad ... you can get it for only 5€!!!
Its NOT worth NOT trying it 

It's really cheap and neat. However, in my opinion, it might just be too complex for somebody new to µC programming.

Developing for it works really well cross-platform, by the way. To set a development envionment up on Linux, you just need to get a msp430 GCC toolchain along with mspdebug (the Ubuntu repos carry both), and then install the CDT version of Eclipse. Finally, install the Eclipse addon available here. Once you've restarted Eclipse, you can make a C project with the type "MSP430 Cross Target Application". Select the MSP430G2553 in the setup wizard (if that's what's on your Launchpad). Once you've clicked "Finish", open up the Project Properties dialog, click on "MSP430" in the left menu list, select the "rf2500" MSPdebug driver, click "USB" and you're good to go.

The process is almost the same on Windows, but I recommend to get the toolchain from the site you get the Eclipse addon from.

[daijo]

I would get a Arduino and play around with the environment they supply. After a while you probably will want to leave the Arduino IDE and use a makefile like http://ed.am/dev/make/arduino-mk. This will expose you to the open AVR toolchain. Then write your own makefile and write some programs in C. Order and build a USBtinyISP and program the board without the bootloader. Then learn to stick an AVR on a board with some caps and a crystal and program that.

[gautamdamodar]

Yeah, them MSP430 launchpad is a nice start. Code Composer Studio is easy to use, and when just getting used to things the Grail configuration plugin is nice. No substitute for actually reading datasheets and such, but to I found it useful to get started quickly. So if you want cheap and easy enough, MSP430 would be a good one.

I love MSP430 but I think it is because I migrated from PIC and C51 platforms. Since you are having knowledge of C, architectures doesn't bother much(I think so). As MSP430 got much great user control and associated user configurations I dont know how it will affect a beginner. Considering the initial cost, MSP430 can be justified.

[andyturk]

It's really cheap and neat. However, in my opinion, [the MSP430] might just be too complex for somebody new to µC programming.

Yep. But if you're up for climbing a learning curve, figuring out the ARM Cortex-M architecture is probably a better use of your time. MSP430 and ARM are equivalently complex from a programming standpoint, but ARM has a future while the '430 mostly has a past.

If you ever get to the point where you're trying to put a lot of code on an mcu, the MSP430 will make you jump through various hoops because it's fundamentally a 16-bit design. TI has hacked it to work with 20 bits, but the toolchains are fiddly and the new instructions lead to code bloat (e.g., a 2-byte extension opcode to use the new addressing modes).

With ARM, the same architecture can take you from an 8-pin $0.50 part all the way up to a 180MHz monster.

[amspire]

The most important thing is to get started, and I think that you have more chance to get started with an Arduino or PICAXE quickly then any other alternative.

I know that once you have your programming environment organized, programming on ARM or TI processors can be as efficient as an Arduino or probably even better. I remember developing a multitasking real time operating system for 8051 type processors, and once the operating system was set up and debugged, the rest of the programming was very easy. But it took a lot of time and effort to reach that point.

I also remember with the 8051 project how long it took from the start of programming to the point the hardware could start to do something useful. It was months, and a beginner wants to see results on the first day.

If you are new to programming, I think you are going to go from idea to something that works far quicker with something like an Arduino then a MSP430 or ARM system.

Sure, you will outgrow the Arduino or PICAXE and that is good. You will probably realize that microcontroller code you develop from scratch can be far more reliable then code that uses libraries from unknown contributors and of unknown quality. That is good too.

If you start with an ARM development system, there is probably a 99% probability that it will sit on a shelf for the next 5 years. Then it will be out of date.

If you start with PICAXE or Arduino, there is a good chance you will be getting results in the first day without having to install development environments that are gigabytes in size, without needing to learn an IDE with thousands of features, without having to make sense of datasheets hundreds of pages long, and without having to make your way through language references thousands of pages long.

[brainwash]

Well, the Arduino style coding (Wiring) is now running on MSP430 and the M4F TI processors, so on both the Launchpads. It also runs on the ChipKit which is PIC-based. I think that's the fastest way to get into embedded stuff since you just copy and paste sketches from the web and maybe change the pins
Two recent stories: I was able to code a complete system on an MSP430 Launchpad without having any knowledge of the MSP430 (didn't want to read a lot of datasheets) in a few hours instead of what would have taken a few days. The other one is having bought an AD9850 DDS module and just took a sketch found somewhere, pasted it into the Energia frontend and hit upload on the Stellaris Launchpad. It worked immediately.

So yeah, if you want to go cheaper than the Arduino and have a bit more power, I would definitely suggest the Stellaris Launchpad. I think is one third of the price of the Arduino Uno and has some nice extras as well.