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

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