Which microcontroller should I learn?

[Sal Ammoniac]

Just a random pick: Tiva™ C Series TM4C129x errata sheet is more than 100 pages! NXP's LPC407x (also Cortex M4F) errata sheet is only 9 pages long (including title pages and disclaimers). Based on the dates the NXP LPC407x seems to be older than the Tiva C.

If lack of errata is the criteria, then take a look at the Kinetis K64. Its errata is only 10 pages and the Eclipse-based Kinetis Development System is free without any code limits.

They have a series of boards called Freedom boards that are in the US$35 range. They have a built-in debugger or you can use an external JTAG or SWD debugger like a J-Link.



If you need something more expandable, look at the Kinetis tower system:

[nctnico]

The board I propose comes with a full software suite and heaps of examples!

BTW I wouldn't be too fixated on ICD. In the past 25 years I have tried to use that several times but gave up on it because it always was slow and unstable. There are far better and easier ways to do debugging and unit testing which result in much more stable code.

[tggzzz]

Nobody really explained (to me) why it has to be C and why C++ is sooo bad.

See http://yosefk.com/c++fqa/

If you don't understand the points therein, you shouldn't be using the language.

[Roicker]

The board I propose comes with a full software suite and heaps of examples!

BTW I wouldn't be too fixated on ICD. In the past 25 years I have tried to use that several times but gave up on it because it always was slow and unstable. There are far better and easier ways to do debugging and unit testing which result in much more stable code.

Alright, I'll take your work for it. In that case it's up to the OP to further investigate these options and see which one is best for him. I still believe that for the price and features, the Tiva C is better than other options (remember many students don't have a lot of money to buy tools and kits  ).

While I do agree that having a proper tool like a Green Hills Probe to debug is WAY better than the ICD included in the Tiva C, the price can't be beat. For $12 there are not a lot of options as complete for a beginner. I use this ICD often and I agree it's not super stable, but it gets the job done. It has helped me to debug the errors I had with this project. Would I rather use the Green Hills tools? Of course, but I can't spare the 10k at the moment. I know there are cheaper tools out there, but all this analysis would be the topic of a separate discussion because the question is not what is the best toolchain / MCU combo at the moment.

Remember that when you join a company it is very likely the MCU you use is not the one you have used since many big companies use custom SoCs and MCUs that are not available to the public. I know that is what we use, so I don't expect anyone to be familiar with it.

What I think it's important for someone just starting is to be able to step into his code, see the memory and what the peripherals are doing. I you don't have that, then it's more of a guessing game and it's not what you would do on a professional environment. If you want to do that with other tools you need a bigger investment and although they are better tools, not everyone can afford it.

[tggzzz]

If the designers don't understand their creation, what chance do mere users have?

IMO, the issue for a programmer isn't to enumerate all the weirdest consequences of a language, but to use it well and get work done.

Of course.  But the problem with C++ is that it is so complex that the nasty corner cases often bite even experienced programmers. Subsetting the language helps, but the problem is that every developer/team uses a slightly different subset.

I first started writing K&R style C more than 30 years ago and probably understand 95% of the language.

So did I. There were only two books on C at that time

Because I'm vastly more productive with C++'s strong typing, particularly when it comes to refactoring a big chunk of code.

C++ data is, of course, untyped. Sure, its variables are typed, but they can and do lie about the data. Consider, for example, the endless unresolved and unresolvable discussions about whether it should necessary (for general purpose libraries) or impossible (for assertions and optimisation) to "cast away constness".

If you want a strongly typed OO language, you have to use something like Smalltalk or Java. The refactoring capabilities of a Java or a Smalltalk environment are decades ahead of C++.

[tggzzz]

Can you tell me what do you look for in a interview? How does a candidate with no experience shows you that he know how to program embedded systems?

The simplest technique, which can be very revealing, is to ask them to present what they've done, then to talk about the decisions they made and what they would change now they have 20:20 hindsight.

If they have no experience, they can't show they can program embedded systems. The experience doesn't have to be professional; hobby/amateur can be acceptable - and even desirable.

[Sal Ammoniac]

Can you tell me what do you look for in a interview? How does a candidate with no experience shows you that he know how to program embedded systems?

A candidate with no experience, by definition, doesn't know how to program embedded systems. Just because you don't have professional experience doesn't mean you have no experience--lots of people have plenty of experience doing embedded programming as a hobby. As a hiring manager, I'd certainly consider hiring someone with hobby-level experience, but I would certainly question them closely to try and get an idea of how much they really know and how much is just BS. I've interviewed plenty of people who's only experience with a language, for example, was reading "Learn XX in 24 Hours" the night before the interview. It doesn't take an experienced interviewer long to root out these candidates and show them the door.

Here are some of the things I ask candidates for embedded software positions:

1. What's the difference between re-entrant, thread-safe, and position-independent code?
2. How would you write a bootloader for a microcontroller with only a single FLASH region?
3. What does the C keyword "volatile" do and when/how is it used? Same for "const" and "static".
4. Draw the state diagram for a simple FSM on the whiteboard (a 4-way traffic signal is a good starting place).
5. What is interrupt latency and why is it important?
6. What's the difference between a semaphore and a mutex and when would you use them?
7. What is a critical section and how would you implement one?
8. Have you used an oscilloscope? A logic analyser? Give me examples of how you've used them.
9. What is a pull-up resistor used for? How about a pull-down resistor?
10. What's the difference between a successive approximation ADC and a Sigma-Delta ADC?
11. What are the differences between SPI and I2C?
12. How fast do you have to sample a 10 kHz signal to faithfully reproduce it?

[nctnico]

Unfortunately there are a lot of people out there which just talk a lot of bullshit so when interviewing I let the candidates make a test with relevant questions. That works really well to get an idea of their capabilities and doesn't take asking so many questions. The test results can also lead to asking more questions about their strong and weak points.

[legacy]

Here are some of the things I ask candidates for embedded software positions:
...

11 of 12 passed, can I have a chance  ?

[obiwanjacobi]

That line of questioning is soo last century. I would look for potential, is this person able to pick up new things quickly, does he/she grasp new concepts quickly, is he/she passionate about this stuff. The rest can be learned and is then real knowledge instead of (read) information.

[tggzzz]

That line of questioning is soo last century. I would look for potential, is this person able to pick up new things quickly, does he/she grasp new concepts quickly, is he/she passionate about this stuff. The rest can be learned and is then real knowledge instead of (read) information.

I have sympathy with that, but I interpreted the questions as being a starting point from which you can probe their level of experience.

If someone attempts to bullshit the difference between I2C and SPI, that's a bad sign. If they say "I don't know in detail, but ISTR...", that's OK.

If someone hasn't heard of re-entrant, thread-safe, PIC code, or scopes/LAs, mutex/semaphores, interrupt latency, then I know I'd have to teach them a lot.

If they don't know what an FSM is, or remembers they are used in compilers (don't laugh), I'd be worried.

If they gave the standard answer about const, I'd ask them whether it was possible to "cast away constness", and the desirability/undesirability of doing it.

If someone thinks they understand the effect of "volatile" in real-world C compilers and code, I'd think they have some experience but haven't been bitten by rare unreproducable "interactions".

[dannyf]

", but I don't feel like I'm really programming an embedded system, "

In case it hasn't been said, the arduino environment you have, the hardware, the ide, and the programmer, can be used to develop "real embedded programming".

So you have all you need right now to do what you want.

[andyturk]

Can you tell me what do you look for in a interview? How does a candidate with no experience shows you that he know how to program embedded systems?

The simplest technique, which can be very revealing, is to ask them to present what they've done, then to talk about the decisions they made and what they would change now they have 20:20 hindsight.

Yep. Ask 'em what they've done, and what they're passionate about--hopefully that's something in the embedded world. Having passion for this kind of work is key. It's the only thing that'll get you through those nasty bug hunts where the gizmo falls over and you have no idea why.

Another great web-era interview technique is, "Show me your public git repos!"

[nctnico]

Can you tell me what do you look for in a interview? How does a candidate with no experience shows you that he know how to program embedded systems?

The simplest technique, which can be very revealing, is to ask them to present what they've done, then to talk about the decisions they made and what they would change now they have 20:20 hindsight.

Yep. Ask 'em what they've done, and what they're passionate about--hopefully that's something in the embedded world. Having passion for this kind of work is key. It's the only thing that'll get you through those nasty bug hunts where the gizmo falls over and you have no idea why.

This line of questioning won't tell you whether the person has real experience or is just telling fairy tales.

[andyturk]

This line of questioning won't tell you whether the person has real experience or is just telling fairy tales.

Sure it does. Folks with passion talk about products they've shipped, or projects they've done at home in their spare time. They've got war stories and can defend (or criticize) their own implementation choices.

Ha, can you imagine the interview conversation between me and tggzzz re C++? 

[nctnico]

This line of questioning won't tell you whether the person has real experience or is just telling fairy tales.

Sure it does. Folks with passion talk about products they've shipped, or projects they've done at home in their spare time. They've got war stories and can defend (or criticize) their own implementation choices.

No it won't. From my experience: some people will lie and just tell stories during job interviews. There are those who just lurk around on an R&D department and listen to the stories of real engineers. A test/quiz is the only way to get solid information about someone's abilities.

[Sal Ammoniac]

That line of questioning is soo last century. I would look for potential, is this person able to pick up new things quickly, does he/she grasp new concepts quickly, is he/she passionate about this stuff. The rest can be learned and is then real knowledge instead of (read) information.

That's okay for interviewing new college grads, although you still need to ask them technical questions. Case in point: I recently interviewed a candidate who was halfway through his last year of a four year EE program at a well-known and respected local university. This guy didn't know what a diode is.    I kid you not... How can you get through 3-1/2 years of an EE program and not know what a diode is? That's why I ask the technical questions.

When interviewing for positions that require senior people, I look for knowledge and experience in addition to passion and potential. By the time someone has gotten a few years into their careers they'd better have a good measure of knowledge and experience. Passion is important, but can't compensate for experience.

[andyturk]

No it won't. From my experience: some people will lie and just tell stories during job interviews. There are those who just lurk around on an R&D department and listen to the stories of real engineers. A test/quiz is the only way to get solid information about someone's abilities.

Well, if an interviewer can't tell fact from fiction, then that person should be part of the candidate's schedule. At least, not for the technical due diligence part.

To your point though, usually someone on the interview team will have a candidate demonstrate their ability with a quiz/test of some sort. But hopefully, the interview day won't consist solely of such quizzes.

[boost240]

I have a similar problem as OP so I hope he doesn't mind if I jump in with my own thoughts.

I've always had an interest in technology/computers and over the last year it has grown immensely.  I've started to learn about the intricacies of the actual hardware and how it works.  I've been also been learning about electricity and electronics since the go hand in hand.  I've had an Arduino for a few years now but never really used it.  So I've decided that I would like to learn how to program microcontrollers for hobby reasons.  Maybe make an GPS/Alarm system for my car.  Or my own smart thermostat.  I want to bypass the Arduino environment because programming the bare metal gets me excited.  Plus it'll help me understand how CPUs work.  My issue is I can\t focus on one thing at a time.

I bought a great C programming book a few months ago but I haven't passed chapter 8 yet.  The reason being that when I get home I jump on the internet and I start looking at cool projects to make, different development boards, datasheets and etc.  In and of itself that's not bad, but I won't be able to do any of those things because I'm not learning C or how to actually program these chips.  Also, I'm in limbo because I decided to just learn to program the AVR 328p that came with the Arduino because it seems simple.  But then I'm like "maybe I should try a different board?".  Hmmm 16-bit?  ARM?  Maybe a TI board? Maybe, maybe, maybe.  I just want to be able to decide on a direction and actually stick to it and get the work done.

Anyone have any tips?  Please and thank you.

[westfw]

I start looking at cool projects to make, different development boards, datasheets and etc.  In and of itself that's not bad, but I won't be able to do any of those things because I'm not learning C or how to actually program these chips. ... I'm in limb...

Having projects that match your current level of expertise is relatively important, and it's probably The Great Myth of self-education that you can learn everything you need by doing only "interesting" things.  Sometimes you just have to do the boring stuff as well.

[MT]

People who can talk their way into a job often can talk their way out of a job, craftsmen you dont have to tell what to do rather just giving them the direction and they will find their way there and also the solution to the job/problem all in tranquility. Often during the problem solving they improve on the original functionality while reducing overall production cost and increase ease of use for end customer.

They are the very opposite to people with Dunning Kruger effect or regular narcissists.

But craftsmen as all other people can also suffer from not knowing their value and go way to cheap, but knowing your value does not equal to be a nice personality, you might be forced to "act" like a narcissist in a environment who are narcissistic to establish your value. But when 45+ your already obsolete as an engineer anyway!

Dont forget loads of engineers are Asperger's! All engineering professions have a best before day a phenomenon established by HR who newer have a best before day!

So, I would like your opinion on which microcontroller should I learn.
Among other things, I would like to know which microcontroller is most in demand now and for the foreseeable future.
I'm a bit green on the subject.

So the answer to your question are, you should not become a engineer but a gardener!

[tggzzz]

My issue is I can\t focus on one thing at a time.

Anyone have any tips?  Please and thank you.

Determination, self-discipline, and doing the work where there is no internet to distract you.

[LHelge]

Here are my 5 cents...

Stay away from Arduinos! If you would like to learn embedded programming Arduinos is the completely wrong way to go. They are great if you would like to complete a project quickly without really caring for the software or for rapid prototyping when you're already an experienced embedded programmer, but you will not learn very much.

Apart from the obvious, learning C and some assembly, you should also start learning to use the peripheral hardware of a microcontroller. My suggestion is to start with one of the older/simpler models of the PIC/AVR 8-bit mainly because they have quite short and comprehensive datasheets. Your first weeks with this will be 95% reading datasheets and 5% coding, working with a 100 page datasheet is easier than a 1000 page one. When you are comfortable in setting up timers,  uarts and such as well as navigating datasheets you should move up to a 32-bit microcontroller.

My recommendation is one of the ARM Cortex-M based microcontrollers which seems to gain a lot of popularity nowadays, at least here in northern Europe. Even though 8-bitters still are very common the, usually larger, 32-bitters both allow and require more complex software and hence more developer efforts. My favorite is the ST Microelectronics STM32-series but thats probably because I've used them more than the Cortex-M's from other suppliers.

[meerweten]

Arduino's are nice for small project that needs to be finnished in e very limited time.

as many might have said before, don't just use a micro to let a led blink, thats totaly misusing a µC.

the choice of what to use ( atleast for me) depends on the requirements of the producs.
in some cases i use 16 bitters (like the pic24), but in a recent project i use a efusA9 and program in C#.
don't just learn one type of micro, start with one.

i started with pic's like the pic16f628A, just because it has a large comunity, many diferent ide's and ofcourse a cheap programmer.
if you are staying with developmentboards it might not be a problem as some (like the arduino) have a 'build in' programmer.

the http://www.keil.com/mcbstm32f400/ is a easy board (arm Cortex™-M4) and is much more powerfull than a pic16.
but a pic16 might do a better job then an arm processor. it all depends on the application you are going to make.

[LHelge]

I agree completely about the Arduinos, but if you're greater goal is to learn embedded programming it's definitely wrong.

PIC16F648A is an excellent processor to start with, I revisited that one a few weeks back when i needed something in a DIP-package. Simple enough that you spend more time programming than scrolling through hundreds of pages in a datasheet.

That keil board seems really nice, perhaps one of the cheaper STM32 Discovery or Nucleo boards could be used as an intermediate step.