Where to begin? STM32F0 vs PIC32mx vs MSP432 vs ...

[HzMeister]

If you were just starting out, without knowing a single line of code or anything about microcontrollers, what would you pick? STM32F/L0, PIC32mx, MSP432 or other?

[ataradov]

Anything ARM-based. From this list STM32F.

[nctnico]

I'd definitely look at NXP's LPC series ARM Cortex microcontrollers as well. The peripherals are easy to work with and they all come with a bootloader which allows easy programming through the serial port (or even USB as a mass storage device). I know ST usually wins on price but IMHO that is about where their 'advantage' ends.

[mikeselectricstuff]

Depends entirely what you want to do, but in terms of ease of setting up the toolchain, PIC32 is very straightforward, in that MPLAB takes care of stuff like linker settings and including the right device-specific files for you.
 
If you just want to get into higher end MCUs it probably doesn't really matter which, and the core is probably the least important of all as the compiler takes care of it - it's much more about the peripherals.

[dannyf]

Unless you are already invested in pic, I wouldn't pick pic32 as a platform to learn;

STM32F0 is fairly feature limited. So I would start with F1 as a generic platform - it is older and slower. F3 for analog / mixed signal capabilities. The Nucleo boards there are great as it provides arduino compatible headers.

MSP432 is a weird platform, being new and with a mixed bag of ARM and TI/MSP430 peripherals. I would pick it if you are migrating up from MSP430 or are already familiar with Luminary / Tiva chips.

NXP's offerings aren't that exciting, and the software side is a mess. If you have to go down that path, pick LPC11xx (1114 for example) as simple beginner-friendly starting point, or LPC1768/69 for a full-featured chip.

LM4F120 launchpad is probably the most feature rich mcu out there. Great performance and lots of code. But unfortunately quite buggy.

If I were to do it again, I would go with a STM32F3 Nucleo. and then maybe STM32F1 minimalist board, or MSP432 just for the challenge.

[HackedFridgeMagnet]

After spending 2 hours helping someone get started on an STM32F4.

If they don't know how to code then I would suggest go Arduino.

[HzMeister]

Anything ARM-based. From this list STM32F.

Thanks for the reply. Would you recommend anything better that's not on the list?

I'd definitely look at NXP's LPC series ARM Cortex microcontrollers as well. The peripherals are easy to work with and they all come with a bootloader which allows easy programming through the serial port (or even USB as a mass storage device). I know ST usually wins on price but IMHO that is about where their 'advantage' ends.

Just checked their site and their software/documentation seems organized at first glance. Will be downloading their IDE to see what it's like. How would you compare their LPCXpresso IDE to ST's CudeMX+Keil? Btw, is configuring the bootloader and programming through a serial port easier/quicker than with the included stlink programmer that's on stm32 boards?

Depends entirely what you want to do, but in terms of ease of setting up the toolchain, PIC32 is very straightforward, in that MPLAB takes care of stuff like linker settings and including the right device-specific files for you.
 
If you just want to get into higher end MCUs it probably doesn't really matter which, and the core is probably the least important of all as the compiler takes care of it - it's much more about the peripherals.

That's why I included PIC in the list. I've seen several other forum posts mention how much easier PIC is compared to ARM - but those were over a year old and things change fast. With of the chip vendors updating their toolchains constantly, is that still the case?

Unless you are already invested in pic, I wouldn't pick pic32 as a platform to learn;

STM32F0 is fairly feature limited. So I would start with F1 as a generic platform - it is older and slower. F3 for analog / mixed signal capabilities. The Nucleo boards there are great as it provides arduino compatible headers.

MSP432 is a weird platform, being new and with a mixed bag of ARM and TI/MSP430 peripherals. I would pick it if you are migrating up from MSP430 or are already familiar with Luminary / Tiva chips.

NXP's offerings aren't that exciting, and the software side is a mess. If you have to go down that path, pick LPC11xx (1114 for example) as simple beginner-friendly starting point, or LPC1768/69 for a full-featured chip.

LM4F120 launchpad is probably the most feature rich mcu out there. Great performance and lots of code. But unfortunately quite buggy.

If I were to do it again, I would go with a STM32F3 Nucleo. and then maybe STM32F1 minimalist board, or MSP432 just for the challenge.

What are some negatives about PIC?

I chose the F0/L0 MCUs because you get Keil MDK free with them - apparently it's very good. The NUCLEO-F091RC/F072RB is near the top of my list. Besides, since I'm just starting out, I don't expect to be using anywhere near the available capabilities.

I considered the MSP432 because it's ARM and and since TI makes it, I expect the software, documentation, libraries, etc. to be top notch. Plus the code composer studio if free right now with their dev board. If the support isn't any good, then there is no way I would consider it.

I've read several other forum posts that NXP software is not the best. If that's the case, then it's a huge turn off. Having to deal with subpar tools when learning anything is a drag.

After spending 2 hours helping someone get started on an STM32F4.

If they don't know how to code then I would suggest go Arduino.

i considered arduino just like anyone else starting out, and they look awesome just to play around with. But once you get out of their proprietary IDE, all you're left with is an 8 bit AVR. Then I would have to relearn a new architecture, toolchain, etc. I would rather pick something I can grow in to and master, not something to grow out of.

[ataradov]

Thanks for the reply. Would you recommend anything better that's not on the list?

I personally would go for STM32F4.

Btw, is configuring the bootloader and programming through a serial port easier/quicker than with the included stlink programmer that's on stm32 boards?

If you are serious about doing this for living, then get real tools. What's the point of learning the easy thing, when in real life you will have to use proper programmers?

how much easier PIC is compared to ARM - but those were over a year old and things change fast.

Again, easy does not mean useful. I would say it is easier to find employment with ARM experience. And if you know the "harder" thing, it is always easier to figure out the "easy" thing.

With of the chip vendors updating their toolchains constantly, is that still the case?

For ARM, ARM themselves provide a toolchain and it is as good as it gets.

since TI makes it, I expect the software, documentation, libraries, etc. to be top notch.

That's just not true. There is no good software stack from any manufacturer. They all have problems that you will have to deal with.

If the support isn't any good, then there is no way I would consider it.

Then you've picked the wrong area

I've read several other forum posts that NXP software is not the best. If that's the case, then it's a huge turn off. Having to deal with subpar tools when learning anything is a drag.

That's how it goes in this industry, so you will have to deal with that.

[HzMeister]

If you are serious about doing this for living, then get real tools. What's the point of learning the easy thing, when in real life you will have to use proper programmers?

I'm serious about learning MCUs. I want to get up and running asap with the big easy steps and work my way towards the complicated ones.

Again, easy does not mean useful. I would say it is easier to find employment with ARM experience. And if you know the "harder" thing, it is always easier to figure out the "easy" thing.

That's true. But if you don't know anything, then I think it would be more helpful to know the easy thing first, don't you?

For ARM, ARM themselves provide a toolchain and it is as good as it gets.

Isn't it prohibitively expensive though? What would you say is second best?

[ataradov]

That's true. But if you don't know anything, then I think it would be more helpful to know the easy thing first, don't you?

I typically go straight for what I think I need. This does not always work out as expected, but in many cases it does. But that's my personal preference.

In any case, I strongly recommend to not use manufacturer libraries. Especially if you are learning. MCUs are actually way easier to understand if you look at a low level.

Sure, you will get blinking light faster with demo examples, but that does not make you any closer to understanding or knowing anything.

Cortex-M processors are brilliantly designed so that you can do everything with C, including the startup code.

And if you don't know C, I would strongly recommend to postpone playing with MCUs and get up to speed with C on the PC.

[ebclr]

http://www.silabs.com/products/mcu/32-bit/Pages/efm32-g8xx-stk.aspx

[HzMeister]

I typically go straight for what I think I need. This does not always work out as expected, but in many cases it does. But that's my personal preference.

In any case, I strongly recommend to not use manufacturer libraries. Especially if you are learning. MCUs are actually way easier to understand if you look at a low level.

Sure, you will get blinking light faster with demo examples, but that does not make you any closer to understanding or knowing anything.

Cortex-M processors are brilliantly designed so that you can do everything with C, including the startup code.

And if you don't know C, I would strongly recommend to postpone playing with MCUs and get up to speed with C on the PC.

I just started learning C this past week and for someone with no programming experience, it's a steep learning curve...

The only reason I'm learning C in the first place is to be able to program MCUs and a lot of the info out their is geared towards coding for software(which is useful but extraneous) I want to at least pick up a dev board so that I can apply concepts I learn and look at example code of how others did it. The platform with the best software and support will significantly take the edge off the aforementioned learning curve.

I made this thread looking for advice from people who have dealt with various platforms and know the strengths and weaknesses of each and can recommend the right stepping stone for beginners. While learning from scratch can certainly make a determined person into an MCU master, there are certainly quicker and less painful ways of doing it.

http://www.silabs.com/products/mcu/32-bit/Pages/efm32-g8xx-stk.aspx

I looked into the EFM32 gecko line of MCUs and even installed their Simplicity Studio IDE to take a look at. While they look pretty cool(especially their bluetooth SOCs), there doesn't seem to be a lot of community support for them. How are they better than others like like the STM32?

[ataradov]

I just started learning C this past week and for someone with no programming experience, it's a steep learning curve...

I personally would not layer the need to learn MCUs on top of that.

(which is useful but extraneous)

Not really. Almost everything from "desktop" C can be applied for embedded systems. Some of the things may be a bit heavyweight out of the box (like file operations), but they still will work.

I do MCU support for a living, and it is my general observation that official support will help you with questions on the MCU itself, but knowledge of C will be assumed. Official support people give up trying to teach general programming pretty fast. Community support may be a bit more tolerant, but still, trying to explain intricacies of the hardware to a person struggling to understand the language can be very hard.

[rstofer]

Learning C and learning embedded programming all at the same time is going to be fairly difficult.

I would suggest you start with the Arduino because it will let you write C & C++ programs for a platform that is very well known.  There are a ton of sample programs that come with the IDE and even more projects on the Internet.  There's nothing like success to build confidence.  I don't personally use the C++ approach, I am more of a C kind of programmer.  This is the easiest platform for getting started.

Next up, I would consider the mbed (LPC1768 version).  The toolchain doesn't need to be installed, all programming is done through a web browser.  Very clever!  There are many examples and a lot of library code.  www.mbed.org

Moving up, I am now working with the STM32F4 series devices.  In may ways, they are a PITA but I'm learning my way around.  Consider buying "Mastering the STM32" book because it will show you exactly how to set up the toolchain and get everything working.  It's important that the tools match the book.

You will notice on the mbed.org site that MANY STM32F boards use exactly the same approach to programming as the original mbed board.  Playing with the mbed is a nice way to transition for the STM32F Nucleo boards.  Definitely put these boards on back burner until you have a whole lot of experience.

[forrestc]

If you were just starting out, without knowing a single line of code or anything about microcontrollers, what would you pick? STM32F/L0, PIC32mx, MSP432 or other?

I'm not sure if I was starting where you described that I would start with the question you're asking.

A better question would be:   What is the easiest/fastest way to get up to speed learning about microcontrollers?

Picking a microcontroller for learning is completely different than picking a microcontroller for a project.   I use PIC microcontrollers professionally every day, and am pretty partial to them.   The other microcontrollers also have plusses and minuses.

But if someone says 'I want to get started and have no background', I'm going to point them toward an Arduino or similar with good 'getting started' documentation.  The reason?  There are some basics one need to master, and an Arduino is a good way to get started learning the programming basics.   I may even go as far as to point them toward something like https://www.sparkfun.com/products/12060 or https://www.adafruit.com/products/170 .   The other path is to find a good lesson manual and buy whatever they recommend.

Once you master that basic skillset, then you can move onto something bigger and badder.   

[HzMeister]

Yeah that's why I mentioned getting a Raspberry Pi to learn basic programming in C, Python, Lua, C++.
Either your current PC or a Pi like LINUX SBC is best to learn C with because you don't have to learn MCU architecture on top of the C learning curve.  You can also freely use constructs like printf, fprintf, getenv, scanf, sprintf, sleep, getchar, putchar, allocate as much heap and stack memory as you can reasonably want, and you never have to worry whether you broke the hardware with your program or with your device programming manipulations.

#include <stdio.h>
#include <stdlib.h>

int main( int argc, char **argv ) {
   printf("Hello, World.\n");
}

Takes 60 seconds to experiment with a C program or new function call on a PC whereas there are several layers of library, device programming, I/O, and debugger / toolchain complexity with doing the same for a MCU.

Just follow through Kernighan & Ritchie and you'll be programming in C in a couple of months in your spare time no problem.

Maybe try Visual Studio community edition or something if you're bound to use MS Windows for an IDE with code completion and colorization and stuff though if you want to use MCU tools on MS Windows, use the free lite Keil MDK 5.

Thanks for your great replies, especially your previous post commenting on each platform. I didn't even consider cypress so I'll definitely check them out. While it would be great to buy several different dev boards and experiment with all of them(especially after I have some experience under my belt), my budget(both with time and money) is limited.

Btw, the raspberry pi looks really useful for learning C, albeit a little overkill and a little pricey. I'll check it out though.

Learning C and learning embedded programming all at the same time is going to be fairly difficult.

I would suggest you start with the Arduino because it will let you write C & C++ programs for a platform that is very well known.  There are a ton of sample programs that come with the IDE and even more projects on the Internet.  There's nothing like success to build confidence.  I don't personally use the C++ approach, I am more of a C kind of programmer.  This is the easiest platform for getting started.

Next up, I would consider the mbed (LPC1768 version).  The toolchain doesn't need to be installed, all programming is done through a web browser.  Very clever!  There are many examples and a lot of library code.  www.mbed.org

Moving up, I am now working with the STM32F4 series devices.  In may ways, they are a PITA but I'm learning my way around.  Consider buying "Mastering the STM32" book because it will show you exactly how to set up the toolchain and get everything working.  It's important that the tools match the book.

You will notice on the mbed.org site that MANY STM32F boards use exactly the same approach to programming as the original mbed board.  Playing with the mbed is a nice way to transition for the STM32F Nucleo boards.  Definitely put these boards on back burner until you have a whole lot of experience.

...
But if someone says 'I want to get started and have no background', I'm going to point them toward an Arduino or similar with good 'getting started' documentation.  The reason?  There are some basics one need to master, and an Arduino is a good way to get started learning the programming basics.   I may even go as far as to point them toward something like https://www.sparkfun.com/products/12060 or https://www.adafruit.com/products/170 .   The other path is to find a good lesson manual and buy whatever they recommend.

Once you master that basic skillset, then you can move onto something bigger and badder.   

Very good points. After thinking about it, Arduino may actually a good tool to get you feet wet in the beginning considering the complexity of the subject. I dismissed it because it's not ARM(or PIC) and I didn't want to waste time learning something I'll never put into use. Btw, which arduino version do you recommend?

mbed looks interesting. Lots of boards supported. How useful is it actually?

While I'll definitely be focusing most of my efforts into learning C, I wanted to have a 'real' mcu dev board or two on hand just try even the most basic of things - to the point where it wouldn't even matter what I'm using. However, as I gain more skill and slowly learn how to work with MCUs, that very platform I chose now will be increasingly more important since it's what I'll be investing the majority of my time in. So any and all opinions on why a platform is superior over another are welcome.

[jesuscf]

What a small world!  Recently I asked myself the same question.  I decided to answer it with a little experiment during my recent vacation:  buy a bare micro-controller from DigiKey and get running both a 'blinky' and 'hello world' using only free tools or other ICs that are easily obtainable by anyone.  I didn't want to buy any programmers, IDEs, debuggers, or any other pre-made hardware or software.   My first step was to build a simple USB to Serial adapter around the FT230XS IC from FTDI.  That little board turn out to be extremely useful as it allowed me to load program to to the micro-controllers I tried either using serial boot-loaders or in-system programming via the likes of SPI or JTAG.

My first pick was the LPC824 from NXP.  The chip is about $2 and comes with a serial boot-loader that was easy to activate.  The LPC824 is only available in surface mount packages, so I soldered it into an adapter to assemble the circuit in a breadboard.  The compiler I used is GCC for ARM.  I downloaded the latest version of GCC for ARM from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads.  The serial down-loader I use  was lpc21isp downloaded from https://sourceforge.net/projects/lpc21isp/.  There was a problem with the down-loader that prevented downloading to all the memory of the LPC824, but it was easy to fix (SectorTable_8xx[] had only 16 pages defined instead of 32). I found some examples around the net that helped me get started with both 'blinky' and 'hello world'.   In all, it took me about 2 days to get the LPC824 going.

My second pick was the STM32F051 from ST .  Also around $2 from DigiKey.  I soldered the LQFP32 package into an adapter for bread boarding. This processor comes also with a serial boot-loader that is easy to activate. The down-loader I used was FLASHER-STM32 available from http://www.st.com.  The compiler I used was also GCC for ARM that I have already installed for the LPC824.  Once again I found examples around the net that allowed me to quickly get 'blinky' and 'hello world' going.  This one took me less than a day.

My third pick was the ATmega328 from Atmel (yes the same one in the Arduino board).  Around $4 from DigiKey.  I used also GCC, which I downloaded from the Atmel page http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx.  For this one I wrote an ISP programmer using the FT230XS IC configured in bit-bang mode.  I got that going fairly quickly, although to be fare I should point out that I just adapted a programmer I wrote for the AT89LP family of micro-controllers from Atmel that have a very similar programing interface to the ATmega328.  For the ATmega328 I got both 'blinky' and 'hello world' going in about a day.

My fourth pick was the PIC32MX170F256B from Microchip.  Around $5 from Digi-Key.   This one was a nightmare!  First, there is no freely available GCC compiler you can download, except from Microchip.  So I decided to build the compiler from sources.  It took me about 3 days to build the compiler, but none of my compiled programs worked out.  Finally I gave up and downloaded the free-but-crippled XC32 compiler from Microchip.  For my initial tests I used a programmer built around an Arduino board: https://github.com/ppersia37/ardupic32.  The programmer is very slow but it got me started.  So after about week I got both 'blinky' and 'hello world' going.   I was not happy with the programmer, so I wrote a JTAG programmer around the FT230XS which is orders of magnitude faster than the one built around the Arduino.  I don't remember how long it took me to get the programmer done, but for sure it was at least a week (and several bricked PIC32s!).    At some point, after some discussions about XC32 in this forum, user 'Karel' posted instructions on how to un-cripple XC32 (https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099) which worked quite well.  After what seems a long time I ended up with a nice setup for the PIC32 which I quite like.

My fifth pick was the MSP430, but my vacation was over, so I didn't have time to try it out (reason: see paragraph above!).

So which one is my favorite?  All of them!  Once I got things going, they were very similar from the programmer's point of view.   I like the easiness of both the LPC824 and STM32F051, but the PIC32MX170F256 has a lot more memory and 'feels' powerful (may be I struggled so much with it that I 'appreciate' it more).  At some point trying to use printf() (via newlib nano) with the LPC824 I ran out of Flash memory.  There are many ways around this problem, so for me is not a deal breaker.  Even the Atmega328 felt right despite being an 8-bitter!  In the picture below are the bread boarded-micro-controllers, from left to right the AT89LP52 (which I use quite a bit, the Atmega324 programmer is based in the programmer I wrote for this one), LPC824, STM32F051 (with a pot attached, as I also tested the ADC), Atmega328, and PIC32MX170F256.

[JPortici]

I recommend NXP as a starter for ARM.

*audience hold their breath*

- Yes, their demoboard cost a bit more than ST
- Yes MOST LPCs are not as attractive as a stm core (though i am making experiments with the M4F / M0+ dual core. i plan to use the M0 to make up for the absence of some peripherals like the FSMC/tft controller)

but

- available also in smaller packages
- comparable parts with a lot more program/data memory on board
- documentation is far more readable (and solid. no info scattered around the datasheet(s)), example circuits in the actual datasheet.
- the hal is easier to understand, cleaner, and with a blink of an eye you can go bare metal.
- their code examples do work and they are written in bare metal style.
- probably the most important of all they actually give you an IDE, which is of course another modified eclipse, that actually works out of the box. if you are a beginner or you don't want to waste time installing this and that and troubleshoot the occasional bug you have the complete package ready for you, for windows linux and osx. The modified eclipse actually has a couple of neat addons like the peripheral view

[dannyf]

What are some negatives about PIC?

I assumed, maybe incorrectly, you wanted to learn this as a marketable skill. ARM is all the raged and few cares about your PIC skills.

I chose the F0/L0 MCUs because you get Keil MDK free with them - apparently it's very good.

It is very capable. But also quite challenging for a newcomer, especially v5.x.

I considered the MSP432 because it's ARM and and since TI makes it, I expect the software, documentation, libraries, etc. to be top notch.

No correlation there.

I've read several other forum posts that NXP software is not the best. If that's the case, then it's a huge turn off. Having to deal with subpar tools when learning anything is a drag.

if you with lpcxpresso, the compiler is top notch, being gcc. the ide is very good, being eclipse.

the issue is with the proprietary debugger and debugging interface, and the half baked mess called lpcopen.

chip-wise, the lpcs are some of the least featured but most robust chips. so a trade off there.

As to starting out with a simpler-featured chip, as a "development board", you want it to have the most feature so you can keep learning on it. so F3 or F4 Nucleos if you want to go with ST.

[tszaboo]

Yes. For a beginner, setting up the toolchain IS the biggest issue, after that, getting information on how to do things.
So where to begin... Arduino. Setting up the toolchain is simple. Getting information on how to do stuff is simple. Making prototypes is simple. You learn "kinda-sorta" C programming, you learn about peripherals, you learn about protocols. Start there. Engineers will avoid the topic, or discourage you that it is not real programming or real electronics, dont listen.

I have to agree, starting with PIC is simple, I did that myself, with ASM language and almost only the datasheet as information. You know what? I've learned a lot. But even now, when I have to set up a GCC toolchain for ARM, it is magic pain in the ass issues with make files, links missing, path not set up correctly, etc. Microchip PIC32 with works out of the box. MBED works almost out of the box. Arduino is excellent.
Setting up a toolchain for ST, NXP is horrible. Libraries are pain to track down manage, make them work.
So the only time I design with them, is when someone else writes the code, and I only design the PCB.

[westfw]

Quote

without knowing a single line of code or anything about microcontrollers

Knowing NOTHING?

Start on a desktop (with an actual "programming for CS majors" type of class search.  Python, Java, C, C++... doesn't matter), or with something Arduino-like.   A TI Tiva Launchpad will get you a modern ARM chip, let you use Energia ((very)Arduino-like IDE), and set you up to be in the UTexas online "Microcontroller" classes (after you know at least one language (and preferably some C.))

Somewhere in there you should learn some electronics basics, too.

(Hmm.  I've taken (parts of) online python classes from three different schools relatively recently, and they've all been pretty good.  (Rice, Michigan, and MIT.)  OTOH, Learning python will teach you some neat stuff that isn't available in C, or (in general) on microcontrollers.)
Sort of half of a university curriculum:  (the other half would be science and math)
1) Programming 101 (UMichL:python), Electronics 101 (?)
2) Algorithms (princeton), C programming (?)
3) Microcontrollers (UTexas), Digital logic (?)
4) operating systems (Utexas?), user interface design (?)
5) practice...

[hans]

http://www.silabs.com/products/mcu/32-bit/Pages/efm32-g8xx-stk.aspx

I looked into the EFM32 gecko line of MCUs and even installed their Simplicity Studio IDE to take a look at. While they look pretty cool(especially their bluetooth SOCs), there doesn't seem to be a lot of community support for them. How are they better than others like like the STM32?

I think the out-of-the-box experience is quite nice. The dev boards are competitively priced and versatile to use. The toolchain is all set up unlike most other vendors, which you must arrange all by yourself. This could be a massive winner.

However for the chips itself.. notice that the EFM32 are a niche MCU targeted for battery and IoT applications. This is reason why it doesn't win the pick for many community projects. If you find yourself needing ethernet connectivity, then EFM32 probably has little to offer with an integrated ethernet MAC. Or want to do some heavy number crunching? STM32 (but also NXP, TI, etc.) have CPU's that go up to 100 or 200MHz. These drop the requirement "low power"; so they can do that.

If I were you, I would go with the flow in order to get the most "community support" and find most info. And that is Arduino, then STM32.
That is if you really do know nothing indeed.

[newbrain]

Very good points. After thinking about it, Arduino may actually a good tool to get you feet wet in the beginning considering the complexity of the subject. I dismissed it because it's not ARM(or PIC) and I didn't want to waste time learning something I'll never put into use. Btw, which arduino version do you recommend?

Yes, as usual here, you have been provided with a lot of good advice: opinions differ of course but you have a lot of material to make up your mind.

My experience is from a hobbyist pow, I work in the SW field but not on embedded stuff.
I mostly use STM32Fxxx (depending on the specific needs) and a bit of ESP8266 (dirt cheap on "AliBay"), MSP432 and Atmega/tiny, coming all the way from 6502, 6809 and 68HC11.

My 2 cents:

• Focus on learning C: you state in your initial post "...without knowing a single line of code or anything about microcontrollers..." and going Arduino will not help much (it's actually C++, but one tends to just cobble together high(ish) level libraries...); try to learn good style in coding and work your way through a good book, keep you on ANSI standard C (no OS specific stuff) and you'll have a very portable set of C skills.
• To learn C, you don't really need a Raspberry Pi (though I love them, I have several): if you have a PC/MAC with Linux/Windows/OsX there plenty of free IDEs or command line compilers. I'm partial to Visual Studio (community edition is free and very complete) and now VS Code (that's even open source!), but that's just me, good alternatives abound.
• IMO, C++ is a different language that happens to use the same syntax: I would not try to learn both at the same time, lest you end up with some confusion.
• If you still want to program Arduino-style many ARM boards are supported by mbed (Nucleos are much cheaper than Arduinos!): same ease of use, but also more powerful if you use advanced stuff (I'm not a fan myself)
• Psoc is very interesting, but its programmable logic part will add another step to the learning process...
• Don't expect high quality and support in vendor provided libraries (see my ranting with Texas here), some are better, some are worse, none is stellar.
• Hardware-wise: In the STM32 field, if you want something more than a bare bone MCU (Nucleo style) there's a wide choice of Discovery boards, the mentioned F7 is very nice board, maybe a bit daunting for a newcomer (and very few I/Os are free for you to use). I'd settle on a cheap Disco F4 (MEMS accelaration sensor, audio DAC), or Disco F429 if you want a display.

[dannyf]

"when I have to set up a GCC toolchain for ARM, it is magic pain in the ass issues with make files, links missing, path not set up correctly, etc."

That's because you picked the difficult path.

For most ide, it is nothing more than downloading and installing the compiler and point your ide to it.

A 30 seconds job.

[nctnico]

"when I have to set up a GCC toolchain for ARM, it is magic pain in the ass issues with make files, links missing, path not set up correctly, etc."

Whatever you don't know how to do is hard. GCC is simple as soon as you know how the compilation process works under the hood. That isn't difficult but many IDEs like to hide that from the user and the compiler also seems to know things by magic. But like any magic trick: what really happens is simple.

[tszaboo]

"when I have to set up a GCC toolchain for ARM, it is magic pain in the ass issues with make files, links missing, path not set up correctly, etc."

Whatever you don't know how to do is hard. GCC is simple as soon as you know how the compilation process works under the hood. That isn't difficult but many IDEs like to hide that from the user and the compiler also seems to know things by magic. But like any magic trick: what really happens is simple.

I dont doubt that these skills are achievable. The issue is: When you need to download an IDE from one site, GCC from an other site and make them work together, it will be more difficult than something that works out of the box. If you are a programmer who likes running linux, posting questions on sourceforge, and debugging logfiles to fix makefiles, sure. It can be done. It is boring, and if you are a beginner, it will discourage you from continuing.
I'm not a programmer, I'm an engineer. You want a button, which you press. The black box uploads your code into the microcontroller, and then it starts running. It should be a black box. If you need a guide, how to install it, it is already too much. Some manufacturers got this right, some rely on IAR/Keil to do this for them, which make them too expensive, some hide their information on the deep web, where only sandal+socks wearing people go, who are too young to realize they should already shave.

[rstofer]

Very good points. After thinking about it, Arduino may actually a good tool to get you feet wet in the beginning considering the complexity of the subject. I dismissed it because it's not ARM(or PIC) and I didn't want to waste time learning something I'll never put into use. Btw, which arduino version do you recommend?

When I want to try something in a hurry, I reach for my Arduino Uno.  I have a BUNCH of boards (literally dozens) but if it's something fairly simple, the Arduino comes up first.

mbed looks interesting. Lots of boards supported. How useful is it actually?

Very useful!  I had an application where I was emulating the plotter output of an old computer.  It did step-by-step plotting with 0.01" steps - so a lot of steps to draw a graph...

I wanted to accumulate those commands as they came in over SPI and, if the pen was up, just accumulate until a pen down command came along, then move to the final location.  If the pen was down, accumulate until there was a change in direction, then draw the line.  In any event, these 6 bits words were eventually converted to HPGL command strings so I could draw the plot on a LaserJet.  The LaserJet could be reached by a TCP connection.

I wanted to use large circular buffers on input and output and the SPI rate was 6.25 MHz.

Yup!  The mbed is useful...  I used the LPC1768 mbed with a MagJack to implement the networking and a couple of pins for SPI and another pin for 'busy'.  Works well!

FWIW, all written in C, all through the online toolchain and the library provided all the necessary networking code.  All I had to do was write my application.

It's a great platform!

While I'll definitely be focusing most of my efforts into learning C, I wanted to have a 'real' mcu dev board or two on hand just try even the most basic of things - to the point where it wouldn't even matter what I'm using. However, as I gain more skill and slowly learn how to work with MCUs, that very platform I chose now will be increasingly more important since it's what I'll be investing the majority of my time in. So any and all opinions on why a platform is superior over another are welcome.

Arduino!  There are shields to plug into the Uno (and others) that implement just about everything.  Of course, at some point, you run out of pins.  But within that limitation, there is a ton of stuff out there for Arduino.

https://www.sparkfun.com/search/results?term=arduino

As to learning C, you can use Microsoft Visual Studio Community Edition for free.  If you use Linux, GCC is always available.  Microsoft added the Ubuntu bash shell to the latest Win 10 upgrade which gives you access to many command line tools from Linux.  The entire GNU Compiler Collection (includes Java, C, Fortran, Ada) is available.  You would be writing command line executables, not windowing applications.

[ebclr]

What  STM32, Silabs Geckos, NXP's, Nordic's, Nuvoton,Atmel have in common

A nice free development platform, that can be used apart from vendors tools

https://developer.mbed.org/platforms/

[newbrain]

Microsoft added the Ubuntu bash shell to the latest Win 10 upgrade which gives you access to many command line tools from Linux.  The entire GNU Compiler Collection (includes Java, C, Fortran, Ada) is available.  You would be writing command line executables, not windowing applications.

I can confirm that it works quite well, for this kind of stuff. I also cross compiled code for ARM without any problem, makefiles and arm-none-eabi-gcc. I had a largish Linux makefile, and was too lazy to go and do it on one of my Raspberries...if translate it to Windows.

[rstofer]

Microsoft added the Ubuntu bash shell to the latest Win 10 upgrade which gives you access to many command line tools from Linux.  The entire GNU Compiler Collection (includes Java, C, Fortran, Ada) is available.  You would be writing command line executables, not windowing applications.

I can confirm that it works quite well, for this kind of stuff. I also cross compiled code for ARM without any problem, makefiles and arm-none-eabi-gcc. I had a largish Linux makefile, and was too lazy to go and do it on one of my Raspberries...if translate it to Windows.

I have 3 Linux boxes along with 3 Windows machines but since I bought my Surface Book, they remain idle.  Adding the bash shell makes command line development a reality under Win 10.

I'm one of the 'geezer geeks' and I like messing around with FORTRAN and the GNU version works quite well in supporting the newer standards.  I'm enjoying old school programming again.

I recommended above the "Mastering The STM32" book and I'll do it again.  Follow the instructions for installing the toolchain and everything works well.  I installed it on my Book and programming STM32F4 projects works well.  Not that I have a handle on the STM32F4, that's going to take a while.  The number of included HAL and CMSIS files is staggering.  Over 3700 bytes of code (Release Mode) to blink an LED.  There's a lot to learn and this isn't the way to start!  But it's a nice platform and integrates well with the ST supplied tools.

I would still start with the Arduino.  There's a lot to offer in that platform.  And I would skip the C++ thing.

[nctnico]

The C++ versus C is the C versus assembler discussion all over again  . I can guess the outcome though.

[HzMeister]

First of all I would like to thank everyone for all the replies. I watch a lot of Dave Jones's videos on youtube so I figured this would be a great place to start, and I wasn't wrong. I would have replied sooner but my right hand has been swollen stiff for the past couple days after injuring it while working on a project. Nevertheless, after reading every comment, I have a much better understanding of the various mcu platforms and I have no doubt it will help countless others in the future.

Anyway, I picked up Arduino uno at microcenter yesterday at the suggestion of HackedFridgeMagnet, wilfred, rstofer, forrestc, NANDBlog, ect. - hard not to at least try it with so many recommendations - and after tinkering with it from a couple hours I have to admit it's a pretty cool little board. Due to how overly simplified everything is and the incredible amount of material and community support around it, Arduino really makes it easy for a beginner to pick up. Plus there is a huge community over at avrfreaks which provide further support outside arduino. I'll definitely be spending a good amount of time with it.

The C++ versus C is the C versus assembler discussion all over again  . I can guess the outcome though.

As a beginner, you have this exact question - C or C++(but not assembly obviously). I have no idea why people lump C and C++ into one group. While they are somewhat related, knowing one doesn't necessarily mean you know the other and they are for the most part entirely different languages. The one thing I don't like about the Arduino(and mbed) is that everything is based around C++, and while it's really easy to understand and follow, it's also extremely inefficient. For example, the blinky demo that everyone starts out with is 928 bytes when compiled, whereas the same exact program when written in C is 176. The C++ compiled code is over 5x bigger but with nearly the same number of lines of source code  . I'd rather master C and have a fast and efficient mcu...

Btw, thanks for your replies nctnico, not just in this thread but in many others. When I'm searching for an answer, you always seem to have a lot of great info to share, so much appreciated.

I have 3 Linux boxes along with 3 Windows machines but since I bought my Surface Book, they remain idle.  Adding the bash shell makes command line development a reality under Win 10.

I'm one of the 'geezer geeks' and I like messing around with FORTRAN and the GNU version works quite well in supporting the newer standards.  I'm enjoying old school programming again.

I recommended above the "Mastering The STM32" book and I'll do it again.  Follow the instructions for installing the toolchain and everything works well.  I installed it on my Book and programming STM32F4 projects works well.  Not that I have a handle on the STM32F4, that's going to take a while.  The number of included HAL and CMSIS files is staggering.  Over 3700 bytes of code (Release Mode) to blink an LED.  There's a lot to learn and this isn't the way to start!  But it's a nice platform and integrates well with the ST supplied tools.

I would still start with the Arduino.  There's a lot to offer in that platform.  And I would skip the C++ thing.

Thanks for the suggestion. I dl a preview of Mastering the STM32. Really handy book, albeit for someone slightly for advanced than I am. I'll probably buy it if I end up going with STM32.

The one thing I didn't account for was the insane level of complexity some MCUs have for even most trivial tasks - ie your 3700 bytes if code for an led? It's basically the reason I started this thread - to find the platform that can get the most done with the least amount of effort and hair pulling.

When I want to try something in a hurry, I reach for my Arduino Uno.  I have a BUNCH of boards (literally dozens) but if it's something fairly simple, the Arduino comes up first.

Very useful!  I had an application where I was emulating the plotter output of an old computer.  It did step-by-step plotting with 0.01" steps - so a lot of steps to draw a graph...

I wanted to accumulate those commands as they came in over SPI and, if the pen was up, just accumulate until a pen down command came along, then move to the final location.  If the pen was down, accumulate until there was a change in direction, then draw the line.  In any event, these 6 bits words were eventually converted to HPGL command strings so I could draw the plot on a LaserJet.  The LaserJet could be reached by a TCP connection.

I wanted to use large circular buffers on input and output and the SPI rate was 6.25 MHz.

Yup!  The mbed is useful...  I used the LPC1768 mbed with a MagJack to implement the networking and a couple of pins for SPI and another pin for 'busy'.  Works well!

FWIW, all written in C, all through the online toolchain and the library provided all the necessary networking code.  All I had to do was write my application.

Great to hear how mbed can be implemented in the real world. I think it would be the natural transition from arduino and I'll probably go that route. Quick question though, I thought most, if not all, of the mbed libraries were written in C++; how were you able to implement the C code in your application?

Arduino!  There are shields to plug into the Uno (and others) that implement just about everything.  Of course, at some point, you run out of pins.  But within that limitation, there is a ton of stuff out there for Arduino.

https://www.sparkfun.com/search/results?term=arduino

As to learning C, you can use Microsoft Visual Studio Community Edition for free.  If you use Linux, GCC is always available.  Microsoft added the Ubuntu bash shell to the latest Win 10 upgrade which gives you access to many command line tools from Linux.  The entire GNU Compiler Collection (includes Java, C, Fortran, Ada) is available.  You would be writing command line executables, not windowing applications.

Since I'll mostly be working on PC, Microsoft visual studio is certainly a nice tool. A cool thing I found out is that Atmel studio is based on Microsoft visual studio and with a quick instructables tutorial I'm able to compile and send code directly to the ATmega328p just like with Arduino. If I could familiarize myself with Atmel studio well enough, it could potentially make the transition to their 32 bit ARM based SAM series of MCUs significantly easier. Btw, what is the general consensus of Atmel ARMs?

"when I have to set up a GCC toolchain for ARM, it is magic pain in the ass issues with make files, links missing, path not set up correctly, etc."

Whatever you don't know how to do is hard. GCC is simple as soon as you know how the compilation process works under the hood. That isn't difficult but many IDEs like to hide that from the user and the compiler also seems to know things by magic. But like any magic trick: what really happens is simple.

I dont doubt that these skills are achievable. The issue is: When you need to download an IDE from one site, GCC from an other site and make them work together, it will be more difficult than something that works out of the box. If you are a programmer who likes running linux, posting questions on sourceforge, and debugging logfiles to fix makefiles, sure. It can be done. It is boring, and if you are a beginner, it will discourage you from continuing.
I'm not a programmer, I'm an engineer. You want a button, which you press. The black box uploads your code into the microcontroller, and then it starts running. It should be a black box. If you need a guide, how to install it, it is already too much. Some manufacturers got this right, some rely on IAR/Keil to do this for them, which make them too expensive, some hide their information on the deep web, where only sandal+socks wearing people go, who are too young to realize they should already shave.

I'm more of an engineer than a programmer as well so while I don't mind setting something up, I'd rather avoid hunting down a bug that could have been avoided on a different platform. Could you elaborate on which manufactures got it right, or at least rank the top ones from best to worst? Your experiences and opinion of the various manufactures would be very helpful.

My experience is from a hobbyist pow, I work in the SW field but not on embedded stuff.
I mostly use STM32Fxxx (depending on the specific needs) and a bit of ESP8266 (dirt cheap on "AliBay"), MSP432 and Atmega/tiny, coming all the way from 6502, 6809 and 68HC11.

My 2 cents:

• Focus on learning C: you state in your initial post "...without knowing a single line of code or anything about microcontrollers..." and going Arduino will not help much (it's actually C++, but one tends to just cobble together high(ish) level libraries...); try to learn good style in coding and work your way through a good book, keep you on ANSI standard C (no OS specific stuff) and you'll have a very portable set of C skills.
• To learn C, you don't really need a Raspberry Pi (though I love them, I have several): if you have a PC/MAC with Linux/Windows/OsX there plenty of free IDEs or command line compilers. I'm partial to Visual Studio (community edition is free and very complete) and now VS Code (that's even open source!), but that's just me, good alternatives abound.
• IMO, C++ is a different language that happens to use the same syntax: I would not try to learn both at the same time, lest you end up with some confusion.
• If you still want to program Arduino-style many ARM boards are supported by mbed (Nucleos are much cheaper than Arduinos!): same ease of use, but also more powerful if you use advanced stuff (I'm not a fan myself)
• Psoc is very interesting, but its programmable logic part will add another step to the learning process...
• Don't expect high quality and support in vendor provided libraries (see my ranting with Texas here), some are better, some are worse, none is stellar.
• Hardware-wise: In the STM32 field, if you want something more than a bare bone MCU (Nucleo style) there's a wide choice of Discovery boards, the mentioned F7 is very nice board, maybe a bit daunting for a newcomer (and very few I/Os are free for you to use). I'd settle on a cheap Disco F4 (MEMS accelaration sensor, audio DAC), or Disco F429 if you want a display.

• Good advice. I've been putting every spare minute I have into learning C. While the arduino community may not be the best help in learning C, I do like the fact that I can find an answer to any question I have. That way I can see how someone solved a problem in C++ and try to figure out a way to do it in C. I'm seriously trying to avoid the copy/paste technique that seems to be so popular...
• I actually picked up a raspberry pi zero for $1 when I was at microcenter. After trying it out, it's a very cool idea, but it's not what I'm looking for. If I were learning OS's then yes it could be useful, but it's a far cry from learning embedded systems.
  
• I would prefer it if everything was in C, but it seems that a good chunk of the info on embedded systems geared towards beginners is in C++. So it's a bit hard not learning both. Which platform would you say is best for a beginner learning C without having to deal with C++?
• mbed is certainly very appealing. Right now I'm trying to decide whether to go with nxp or stm32. I am leaning towards stm32 because of the cheap nucleo boards, cube mx, and the free Keil support for F0/L0.
• Which are better, which are worse?
• I looked at the discovery boards and do like the extra features they bring for the price; I will certainly consider getting one but I also like the flexibility of nucleo boards, especially the 32 pin ones with a really small footprint that I can easily throw into a project

Yes. For a beginner, setting up the toolchain IS the biggest issue, after that, getting information on how to do things.
So where to begin... Arduino. Setting up the toolchain is simple. Getting information on how to do stuff is simple. Making prototypes is simple. You learn "kinda-sorta" C programming, you learn about peripherals, you learn about protocols. Start there. Engineers will avoid the topic, or discourage you that it is not real programming or real electronics, dont listen.

I have to agree, starting with PIC is simple, I did that myself, with ASM language and almost only the datasheet as information. You know what? I've learned a lot. But even now, when I have to set up a GCC toolchain for ARM, it is magic pain in the ass issues with make files, links missing, path not set up correctly, etc. Microchip PIC32 with works out of the box. MBED works almost out of the box. Arduino is excellent.
Setting up a toolchain for ST, NXP is horrible. Libraries are pain to track down manage, make them work.
So the only time I design with them, is when someone else writes the code, and I only design the PCB.

What a great post. You basically summed up the concerns of a beginner looking to getting into more advanced MCUs. Arduino is definitely a good place to start - at least at the beginning when everything seems complicated. I have no regrets buying the UNO.

While ARM is dominating the market among 32 bit MCUs in the commercial world, the PIC32mx series has a lot to bring to the table, which is why I included it in the OP - and posts like yours make me question whether to go with ARM or PIC. When I started this thread, my goal was to find a microcontroller platform that offered tools easy enough for a beginner to learn while offering flexibility for more advanced engineers.

I have read countless other posts from people complaining about how complicated 32 bit ARM based MCUs are and how much more they like PIC32. I really want to like the PIC32 too, but there seems to be no love for it when compared to ARM. Which raises the question - If ARM didn't have such ubiquity in the market, would PIC32 be the better platform?

All I'm interested in is results. Whatever platform is most comprehensive, easiest, and conducive to learning is the one I want to go with - regardless of market share or what it looks like on a resume. I want something that "just works". Is there an ARM product that fits this criteria?

The only real negative of PIC32 that I can find is that their pro compiler is somewhat expensive. I have to admit that it's pretty retarded for a hardware company to sell software that is designed to optimize code only for their hardware... Nevertheless, it is cheaper than other compilers and they offer monthly payment options which takes the edge off the cost.

Not considering the job/market and/or some heavy computing, what are some real world applications someone would go with ARM over PIC32 even if the support is somewhat fragmented?

[JPortici]

no need to pay for the compiler. it's GCC, you can download the source from microchip and re-compile it without the licence check part (there is a tutorial somewhere for doing that)
the problems with pic32 are others - like severe bugs in certain parts, some which will never be corrected (the NONE workaround in the errata) -

if you just need to switch on an LED get a pic10. it will be the smallest footprint, cheapest, least memory and peripherals so you don't waste a single byte or silicon gate!
sorry for the sarcasm but use whatever you use. i use a lot of pic16 because i know those well enough, simpler to protorype on the fly.. and a lot of dspic for the same reason.. and when i need more speed.. and basically handle 16/32 bit without getting crazy. i also dabble with ARM chips because even though i don't have anything crazy to do with them i have to be ready for the time i have to

for example, sillabs has launched a line of MCUs with sub-ghz transceivers with interesting specs. one has an 8051 core, the other has a cortex M0+. i am going to work with the M0+ even though it only has to shuffle bytes around, that figured out will be a lot less of head scratching in the next project

[dannyf]

Whatever platform is most comprehensive, easiest, and conducive to learning is the one I want to go with - regardless of market share or what it looks like on a resume. I want something that "just works". Is there an ARM product that fits this criteria?

what's comprehensive, easy and conducive to learning to one person may not be for another. I have on my blog a series of posts on "getting started on ..." that talks about getting it going on many of the typical platforms / IDEs and they are largely the same.

One thing that beginners endlessly and needlessly dwell on is the choice of the mcu / core, when that should have been the least of their concerns: as long as you program in a high level language like C, the core is transparent to you for the most part. What makes the difference is the peripherals and your intended application.

The ARM chips have generally more complex peripherals - configuring more than a handful of registers to get it going and sometimes 20 - 30 registers is not uncommon. They are exceptions to that: the LPCs for example are generally quite simple in that department.

The PICs have very simple to configure peripherals in general. But you don't have much of a community to lean on. and monetizing your skills there can be disappointing - which may not be your goal.

the MSP432 is more like a MSP430 powered by a ARM core: it  uses mostly (but not all) MSP430 peripherals. Very little support and very limited community / code base.

The IDEs are different but they follow the general pattern to the end user.

[Sal Ammoniac]

As others have already said, ARM is probably the way to go since it's very popular and well-supported by numerous vendors. The CPU core is the same for all vendors, although the peripherals vary widely in capabilities and complexity. The best balance in the flexibility/complexity trade-off that I've found is the NXP LPC series.

As fas as development tools go, I have two recommendations:

1) If you're the DIY type, then I recommend putting together an Eclipse-based system from the free components available (Eclipse, GCC, CDT, EmbSysRegView). There are guides available for doing this (including one I wrote) and the whole process takes about 30 minutes.

2) If you're not the DIY type, then I recommend getting Segger Embedded Studio from segger.com. This is a turn-key IDE based on Rowley CrossWorks. It's a complete IDE bundled with GCC and Clang and a custom C library. I've used CrossWorks for years and the Segger product is the same thing with a different name (and support for only the Segger J-Link JTAG debugger). Embedded Studio is available free with a non-commercial license and is not crippled--there are no time or code size limitations. You must use it with a Segger J-Link debugger, however (this is not a big deal--see paragraph below).

For a hardware debugger I strongly recommend a Segger J-Link. This is a professional tool and is very robust and fast. I've also used these for years without any problems. Segger keeps their support software up to date and quickly supports new ARM Cortex parts when they become available. If you're a hobbyist, you can get the J-Link EDU from Segger for about USD$60. This is a very good deal for a truly professional piece of kit. If you're doing commercial work, then you'll need to fork out USD$350 or so for the non-EDU version of the J-Link. All J-Links work very well with either of the two options I mentioned above.

If you do choose an NXP LPC ARM Cortex part, you can buy the LPC-Link2 from NXP for about USD$20 rather than a Segger J-Link. Segger has (legal) firmware that you can download into the LPC-Link2 that makes it behave just like a J-Link. The only limitation is that you can only use it with NXP parts.

[rstofer]

Using the mbed and the Arduino doesn't require a single line of C++ AFAICT.  I have always used plain vanilla C and everything seems to come together.  To be honest, I haven't tracked down how that works.  Yes, the libraries are written in C++ but somehow the magic computing machine accepts plain old C.  There is probably some magic in the header files but I haven't looked.

When you look at the ARM Cortex chips, there may be a small bit of setup code written in assembly language ('crt0.S' or something like that) and from there on, everything is written in C.  If you start with a fairly simple chip, like the LPC1768 of the mbed, you can write everything in C including the interrupt handlers.  There is no requirement to use any of the mbed libraries.  If the application doesn't need any of that code (like networking), you can write every line of the application.  With no toolchain to install!

Once you get to the bigger chips like the STM32F4, there is a tendency to just incorporate the factory provided CSMIS library and the HAL library and call it good.  Those libraries are huge!  I want to see projects where the author DOESN'T use these libraries.  Sure, you wind up having to write drivers for all of the peripherals but at least you understand how the code works.  Not so with the factory libraries.  I'm not sure I have ever seen decent documentation for the libraries.

The only thing harder than starting with the STM32F4 is starting with the STM32F4 with Ada!  It works but it's a nightmare working through hundreds of files of HAL and lower level code.

Don't overlook the Raspberry PI for some 'embedded' applications.  There are a bunch of user IO and peripherals available and there is sample Python code for driving them.  And the entire development environment is part of the end application.  That's pretty cool.

In my view, the order of experience would be:

Arduino
mbed
do {
  <anything except STM32F>
} until everything on the planet has been evaluated
STM32F

I'll eventually catch on to the STM32F but, honestly, it's a lot of work and I don't really have a project to provide motivation.

[westfw]

Using the mbed and the Arduino doesn't require a single line of C++ AFAICT.  I have always used plain vanilla C and everything seems to come together.  To be honest, I haven't tracked down how that works.  Yes, the libraries are written in C++ but somehow the magic computing machine accepts plain old C.

C++ is pretty much a proper superset of C.  Given any C++ compiler, you can feed it generic C and it won't complain.  There are a couple of corner cases where C++ doesn't allow some common-but-known-dangerous C casts/implicit cases, and a line like "Serial.write()" is technically C++ because "Serial" is a C++ class and not a C structure.  In fact, with Arduino at least, some of the things that "real C++ programmers" swear by won't work, because there is no run-time support for exceptions, and the dynamically-allocateable RAM is small and rather dangerous to use, rendering much of the C++ "Standard Template Library" and 3rd party C++ libraries irrelevant.  (Not to mention that they tend to be very large, since, you know, gotta make all those data structures dynamically expandable...)

[rstofer]

Using the mbed and the Arduino doesn't require a single line of C++ AFAICT.  I have always used plain vanilla C and everything seems to come together.  To be honest, I haven't tracked down how that works.  Yes, the libraries are written in C++ but somehow the magic computing machine accepts plain old C.

C++ is pretty much a proper superset of C.  Given any C++ compiler, you can feed it generic C and it won't complain.  There are a couple of corner cases where C++ doesn't allow some common-but-known-dangerous C casts/implicit cases, and a line like "Serial.write()" is technically C++ because "Serial" is a C++ class and not a C structure.  In fact, with Arduino at least, some of the things that "real C++ programmers" swear by won't work, because there is no run-time support for exceptions, and the dynamically-allocateable RAM is small and rather dangerous to use, rendering much of the C++ "Standard Template Library" and 3rd party C++ libraries irrelevant.  (Not to mention that they tend to be very large, since, you know, gotta make all those data structures dynamically expandable...)

I had completely forgotten about Serial.println().  Definitely not a C 'thing'.  Yes, it is a C++ construct but it's pretty easy to work with.  I would prefer printf() but I can get along with Serial.print...

Heaps are a terrible idea for embedded systems.  The usual heap manager just expands the block, it does no garbage collection.  Sooner than later, the stack will run into the heap and the real fun begins!

[ez24]

I would still start with the Arduino.  There's a lot to offer in that platform.  And I would skip the C++ thing.

Can you explain how to skip the C++ thing.
thank you

[westfw]

[Serial.print] is a C++ construct but it's pretty easy to work with.

Yes; a lot of the C++ that has been "snuck" into Arduino is like this.  Relatively subtle and "easy to work with."   As a long-time C programmer, I haven't had any problems with it, and some of the features it gives you are pretty nice (like being able to use Serial.print() with multiple data types.)
I would have liked printf() better too, but since it doesn't see argument types till runtime, it VERY big compared to Serial.print() that only add code for the types you actually print.   If your chip is big enough, printf() is easy enough to add.

I had an interesting realization recently:  operators (+-/*) in MANY languages have been polymorphic (behave differently for different argument types) since the beginning of high level languages (1954 Fortran), but it is comparatively recently that it's been allowed in user-defined functions and subroutines.

[rstofer]

I would still start with the Arduino.  There's a lot to offer in that platform.  And I would skip the C++ thing.

Can you explain how to skip the C++ thing.
thank you

You can't avoid using some of the provided constructs, no question about it.  Unless you want to write your own low level code and, for my own projects, I tend to do just that.  Unless it is a network stack...

I don't see how polymorphism helps me with a timer interrupt.  I have yet to figure out why I want constructors and destructors with a serial port.  Not that I couldn't write the code that way but it seems to me that the serial port exists for the entire lifetime of the code.  I create it in C at startup and I leave it alone.  Same with timers, GPIO, PWM, SPI, I2C, etc.  If I use the Arduino library there is a pretty straight forward interface.  If I write my own code there isn't any need to use C++.

I haven't kept up to date but I believe Linux is written in C.  I know that Unix is written in C.  Somehow they were able to build these OS's without C++.

[Karel]

If you were just starting out, without knowing a single line of code or anything about microcontrollers, what would you pick? STM32F/L0, PIC32mx, MSP432 or other?

None! First learn to program in plain C on a normal pc using GCC.
Once you feel confident, pick whatever MCU that is supported by GCC.

Personaly, I find the PIC32MX series very easy to program (avoid the harmony framework!).
Also, the datasheets are easy to read and understand.

[nctnico]

I haven't kept up to date but I believe Linux is written in C.  I know that Unix is written in C.  Somehow they were able to build these OS's without C++.

Unfortunately Linux is still written in C and it is a huge mess. The Linux kernel is entirely object oriented but without a language that actively supports OO it is hard to maintain. I'm pretty sure that if they rewrite Linux in C++ the number of lines will be half or even less, it will reveal tons of potential problems, the kernel will be easier to maintain and the end result will be faster due to optimisations only the C++ compiler can see.

[tszaboo]

[Serial.print] is a C++ construct but it's pretty easy to work with.

Yes; a lot of the C++ that has been "snuck" into Arduino is like this.  Relatively subtle and "easy to work with."   As a long-time C programmer, I haven't had any problems with it, and some of the features it gives you are pretty nice (like being able to use Serial.print() with multiple data types.)
I would have liked printf() better too, but since it doesn't see argument types till runtime, it VERY big compared to Serial.print() that only add code for the types you actually print.   If your chip is big enough, printf() is easy enough to add.

I had an interesting realization recently:  operators (+-/*) in MANY languages have been polymorphic (behave differently for different argument types) since the beginning of high level languages (1954 Fortran), but it is comparatively recently that it's been allowed in user-defined functions and subroutines.

Any time when I see Arduino code, and coders do Serial.print(a); Serial.print(" "); Serial.print(b) for ethernity, it is just raising my blood pressure. Usually when I need to modify the code, I just end up being sprintf(buf,%d %d,a,b) serial...
The code is just soo much cleaner. I dont even know, who thought it is a good idea to exclude serial.printf().

Could you elaborate on which manufactures got it right, or at least rank the top ones from best to worst? Your experiences and opinion of the various manufactures would be very helpful.

It is in my other post, you even quoted it.

Other manufacturers can solve this. All they need: Download this free, all in one package install it, and start working. No code size limit. And BTW, we support it with our other tools (not only IAR and Keil).

[dannyf]

I want to see projects where the author DOESN'T use these libraries.

Fairly easy.

1) there are tons of older ARM chips that were introduced before CMSIS and they don't follow CMSIS at all, and often with their own vendor-specific start-up files;

2) CMSIS is not a must, either to get the chip started or access the peripherals / minimalist functions, even on the newer chips. So yes, you can program them without CMSIS. All CMSIS does is to provide a uniform framework to those chips, a nice-to-have and not a must-have.

[Karel]

I haven't kept up to date but I believe Linux is written in C.  I know that Unix is written in C.  Somehow they were able to build these OS's without C++.

Unfortunately Linux is still written in C and it is a huge mess. The Linux kernel is entirely object oriented but without a language that actively supports OO it is hard to maintain. I'm pretty sure that if they rewrite Linux in C++ the number of lines will be half or even less, it will reveal tons of potential problems, the kernel will be easier to maintain and the end result will be faster due to optimisations only the C++ compiler can see.

Correction: they were able to build OS's thanks to not not using C++!

Linux isn't a big mess. It's not perfect but nothing is.
By the way, from the bigger projects (I'm not talking about small hobby projects here), opensource projects are usually coded better and contain less bugs than closedsource projects.
Anyway, C++ is a horrible language. They keep on changing the language and adding features to the point that the language itself becomes unreadable and unmanagable.

"Based upon the sample of active projects in Coverity Scan, we found the quality of open source software is above average."

http://www.coverity.com/library/pdf/coverity-scan-2011-open-source-integrity-report.pdf

"Linux remains a benchmark for quality."

http://www.coverity.com/press-releases/annual-coverity-scan-report-finds-open-source-and-proprietary-software-quality-better-than-industry-average-for-second-consecutive-year/

[rstofer]

I want to see projects where the author DOESN'T use these libraries.

Fairly easy.

1) there are tons of older ARM chips that were introduced before CMSIS and they don't follow CMSIS at all, and often with their own vendor-specific start-up files;

I have a ton of experience with the LPC2106 and LPC2148 writing code from scratch.  It wasn't that tough because the peripherals were pretty straightforward and the documentation was sufficient.  The startup code (assembly language) took a little thought.  The more modern chips are orders of magnitude more complex.  Just look at the clocks of the STM32F4.  It's going to take a while to understand what's going on in that block.

2) CMSIS is not a must, either to get the chip started or access the peripherals / minimalist functions, even on the newer chips. So yes, you can program them without CMSIS. All CMSIS does is to provide a uniform framework to those chips, a nice-to-have and not a must-have.

I think I like the idea of CMSIS but I must admit to being overwhelmed by thousands of lines of code I didn't write.  A concise definition of the library functions would be nice.  In many ways, using CMSIS is a lot like using the Arduino.  All of the intricate stuff is being handled behind the scenes, by others.  I'm still thinking about that...

STM32CubeMX makes a valiant attempt to write much of the hardware specific code.  All I have to do is fill in the details.  If I do it correctly, then when revisions are made by CubeMX, my additions are carried forward.  So it says...  As long as I put my code in the proper location...

As to learning to  code in C, there are any number of tutorials around.  Books are all over the place and there are millions of lines of code to look at.  In the end, it gets down to actually writing code and the hard part is coming up with a project worth coding.  As to a book, "The C Programming Language" by Kernighan and Ritchie is the place to start.  Among other things, they show code for a lot of conversion routines like itoa() {integer to ascii conversion} that don't use the heap.  I use their code in nearly every project I create.

I have a very old version of "The C Programming Language" but I see the new version complies with ANSI C and somebody else wrote a book with the answers to the exercises.  As a pair from Amazon:

https://www.amazon.com/Answer-Book-Solutions-Exercises-Programming/dp/0131096532/ref=sr_1_9?s=books&ie=UTF8&qid=1475158685&sr=1-9&keywords=the+c+programming+language

Maybe actually coding the exercises is a great learning opportunity.

[Karel]

A book that every serious C-programmer should have at hand: C in a nutshell

https://www.amazon.com/Nutshell-Definitive-Reference-Peter-Prinz/dp/1491904755/

[rstofer]

As to learning to  code in C, there are any number of tutorials around.  Books are all over the place and there are millions of lines of code to look at.  In the end, it gets down to actually writing code and the hard part is coming up with a project worth coding.  As to a book, "The C Programming Language" by Kernighan and Ritchie is the place to start.  Among other things, they show code for a lot of conversion routines like itoa() {integer to ascii conversion} that don't use the heap.  I use their code in nearly every project I create.

I have a very old version of "The C Programming Language" but I see the new version complies with ANSI C and somebody else wrote a book with the answers to the exercises.  As a pair from Amazon:

https://www.amazon.com/Answer-Book-Solutions-Exercises-Programming/dp/0131096532/ref=sr_1_9?s=books&ie=UTF8&qid=1475158685&sr=1-9&keywords=the+c+programming+language

Maybe actually coding the exercises is a great learning opportunity.

I just picked up the pair of books from Alibris for $22 including shipping.  Both are new...

My 1978 version doesn't agree with the ANSI standard hence the 2d edition coming out in '88.  This C thing has been around a long time.  Not as long as FORTRAN but, still, a very long time.  Things that are useful tend to survive.  Anybody writing in BASIC, COBOL, RPG, PL/I, ALGOL, Pascal?  Yes, I know that Modula 2 and Oberon are offshoots of Pascal.  Pascal has always been my favorite language.  Right after FORTRAN...

[dannyf]

"wasn't that tough because the peripherals were pretty straightforward and the documentation was sufficient.  The startup code (assembly language) took a little thought.  The more modern chips are orders of magnitude more complex"

I think there may be some confusion here. Cmsis has nothing to do with the non core related peripherals (like gpio, timers, usarts, etc.). The only "peripherals" covered by cmsis is systixk and nvic, to the extent they are implemented on your chip.

A typical arm has a few software layers, the start up, cmsis, and then vendor library that drives the peripherals

I think your views here seem to be more aligned with vendor library rather than cmsis.

[rstofer]

"wasn't that tough because the peripherals were pretty straightforward and the documentation was sufficient.  The startup code (assembly language) took a little thought.  The more modern chips are orders of magnitude more complex"

I think there may be some confusion here. Cmsis has nothing to do with the non core related peripherals (like gpio, timers, usarts, etc.). The only "peripherals" covered by cmsis is systixk and nvic, to the extent they are implemented on your chip.

A typical arm has a few software layers, the start up, cmsis, and then vendor library that drives the peripherals

I think your views here seem to be more aligned with vendor library rather than cmsis.

That may well be true.  I could easily be confused by the layers and who is responsible for them.  It takes a good deal of messing around with library code to figure out what it does and how it does it.

In some ways the code, like that supplied with the Arduino, is a help in getting an application built.  Really, it's the application that's important.

For decades we have been using an onion model for software.  Layers upon layers upon layers.  There is good reason for that but it can take a lot of effort to dig down through the layers to figure out what is happening or, more likely, what is not happening.

If the hardware is simple enough, I prefer to write all of the code (other than the C library, of course).  There are clearly cases where that simply isn't feasible.

[dannyf]

"There are clearly cases where that simply isn't feasible."

It is always feasible. Just not always desirable, wise, efficient or effective.

A few factors drive layering, in my view.

1. Device and application complexity.

2. Cost and time to mkt pressure: reusing code is critical.

3. Competitive pressure and prioritization: related to 2 above but shops in s high cost area have to figure out what they want to compete on.

Layering should be all natural to a C programmer because that's what C is about: a black box with well defined inputs and outputs.

The way to understand layering is to focus on it's functionality not it's implementation.

[westfw]

I have yet to figure out why I want constructors and destructors with a serial port.

The Serial "objects" in the arduino library are statically allocated, not "constructed" (causing some concern on chips with several serial ports but not much RAM.)  AFAIK, nearly all of the arduino libraries (even from 3rd parties) follow the same model, avoid dynamic allocation, and are based on static creation and "begin" methods rather than constructors.  They seem to take the "don't use malloc on embedded systems" thing petty seriously, AND there's a big problem with using even static constructors of any complexity on AVR, because the constructor code gets called before peripheral initialization.  (when I say they don't use constructors, I mean that they don't use constructors that generate actual code.)

(Sigh.  Except for Strings.  Which are widely avoided due to problems, and/or perceived problems.)

[dannyf]

one interesting thing about the msp432 is its use of msp430 peripherals.

The timers (TIMER A) on msp430 are well thought out and well thought of. You can construct those things so that each compare channel can act as a (largely independent) timer. In the case of a msp432, there are 4 Timer As, each with 6 compare channels. So you get 24 (largely independent) timers out of that thing.

Wish others, especially ST, had modelled their timers after the TI's.

[newbrain]

The timers (TIMER A) on msp430 are well thought out and well thought of.
[...8<...]
Wish others, especially ST, had modelled their timers after the TI's.

Though I tend to prefer STM32s to the MSP432 (maybe due to some sort of imprinting), I have to agree here.
HAL or not HAL it's an arcane art to master STM32 Timers while the TimerA model is clean, simple and effective enough.
Not so much the bug (or "unspecified features") ridden DriverLib...

[Psi]

If you've never touched a line of code Arduino is a very good place to learn the basics.
But once you understand how to structure what you want into lines of code you need to move away from arduino asap. The only reason to stay with Arduino is if you need mcu hardware to do stuff but its only a small part of your hobby.
e.g.  You don't considering yourself a programmer but still need to get some lights to flash and some sounds to play when a button is pressed on your project.

Arduino is too simplistic to really understand whats going on behind the scenes.
I'm reluctant to recommend STM32 but only because its so much more complicated and the standard peripheral library is a bit of a mess.
AVR is really nice. The hardware is solid and it's easy to learn. However the platform is pretty dead for commercial applications. Everyone is going ARM because its cheaper and much faster.
PIC is ok, but watch out for silicon bugs.

[dannyf]

You can construct those things so that each compare channel can act as a (largely independent) timer.

using that approach, I used a Timer B on a msp430f to create a few hardware timers. The same approach works for other MCUs, and here is an example of getting it done on a PIC16F1936 - using Timer 1 as time base, and CCPR1..5 as independent timers: https://wordpress.com/read/feeds/36364175/posts/1173968882

so next time when you are running out of timers, think about this approach.

[snarkysparky]

Hey all first post here.

I chose Atmel SAMD because of the free IDE.  I don't even mind the 5 min startup time of this program as long as it generates good code, and it does seem to do that. 
I started a project to set up a SAM D10 from bare metal writing registers only.  I have the digital IO working and a 1 ms interrupt routine going for timing.  Next step is  A/D channels and UART.
I agree with those who say that fighting through the datasheet to learn the setup directly is the best and simplist route in the long run to learning a CPU.

I noticed the Atmel ARM series doesn't get much love on forums.  So I would like to know if there are any serious downside to these relative to the other ARM offerings before I invest too much time on the wrong part.

My goal is to have a powerful processor that I am fully familiar with and my own hand written libraries to do basic things WRT peripherals.  I will layout boards complete with my favorite support chips and use these as my general embedded control board.

My only complaint is that the datasheets are sub par.  My main experience comes from PIC24.  Microchip has good datasheets.

[skytoastar]

one interesting thing about the msp432 is its use of msp430 peripherals.

The timers (TIMER A) on msp430 are well thought out and well thought of. You can construct those things so that each compare channel can act as a (largely independent) timer. In the case of a msp432, there are 4 Timer As, each with 6 compare channels. So you get 24 (largely independent) timers out of that thing.

Wish others, especially ST, had modelled their timers after the TI's.

For those wanting more info on this, TI wrote up Application Report SLAA513 on this topic. www.ti.com/lit/pdf/slaa513

[dannyf]

"For those wanting more info on this, TI wrote up Application Report SLAA513 on this topic. www.ti.com/lit/pdf/slaa513"

Precisely what I was trying to do. Nice find.

[dannyf]

Using the same approach, I implemented 4 times using 1 timer (16-bit timer b1) on LPC1114. User code is almost identical to those used in the PIC16F1936 case:

Code: [Select]

tmr16b1_init(1000); //set prescaler to 1000:1
tmr16b1_setpr0(LED_DLY); //set time base -> force roll-over on match
tmr16b1_act0(led_flp);
tmr16b1_setpr1(LED_DLY * 1.01); //set duty cycle
tmr16b1_act1(led_flp);

In this case, timer b1 runs in 16-bit, periodic mode, with a prescaler of 1000:1. the first timer has an interval of LED_DLY and its interrupt handler installed by tmr16b1_act0(); the 2nd timer has an interval of LED_DLY * 1.01, with its own interrupt handler installed by tmr16b1_act1().

In this case, both ISRs run led_flp(), so the visual effective is an led blinking at variable duty cycle.

[dannyf]

Got the code moved to 32-bit timer b1:

Code: [Select]

tmr32b1_init(1000); //set prescaler to 1000:1
tmr32b1_setpr0(LED_DLY); //set time base -> force roll-over on match
tmr32b1_act0(led_flp);
tmr32b1_setpr1(LED_DLY * 1.01); //set duty cycle
tmr32b1_act1(led_flp);

It does the same thing,

[dannyf]

Running two time bases:

Code: [Select]

tmr32b1_init(1000); //set prescaler to 1000:1
tmr32b1_setpr0(LED_DLY); //set time base -> force roll-over on match
tmr32b1_act0(led_flp);

tmr32b0_init(1000);
tmr32b0_setpr1(LED_DLY * 1.01); //set duty cycle
tmr32b0_act1(led_flp);

The same effect. Unnecessarily complex,

[Franc]

I started some weeks ago with Atmel ARM SamD21 and I liked.
I can recommend  you and the XplainedPro board are not expensive.

Until moment I did some programs and my knowledge improving day by day. I study 3 hours in the night in my home as I job with another thing in daytime.

Today I am studing how to configure the Analo Compators. Sinceraly they are fantastic, I did not imagine the AC can be configured as Window mode and others directly in register. Also Single Shot, 3 or 5 SHots etc...

I don't reccomend the ASF Atmel, It was very confuse to me. 

Best Regards!!

[ali_asadzadeh]

Go for ARM,it's really the best for now that you can get, I would go for STM32 or NXP LPC series , buy a j-link and shoot for the Keil MDK as the tool and choose the altium designer as the PCB package! future awaits you.
Note you can use Keil for free up too 32KB of code and you can use circuit maker as a free version for altium.

[HzMeister]

Go for ARM,it's really the best for now that you can get, I would go for STM32 or NXP LPC series , buy a j-link and shoot for the Keil MDK as the tool and choose the altium designer as the PCB package! future awaits you.
Note you can use Keil for free up too 32KB of code and you can use circuit maker as a free version for altium.

Thanks for the suggestion. That's exactly what I'm doing. I got an arduino uno for learning the basics and a nucleo 446re for ARM. Both platforms are great because the give you access to noob tools(arduino/mbed) as well as more advanced tools (atmel/keil) plus they both have a huge user base. It's really great being able to find several answers for any question you might have.

I've also dabbled in circuit maker and I definitely like it the most out of all the free options I've tried.






     

[dannyf]

many of the "portability" is created by users / programmers.

yes, peripherals vary widely and generally there is no "portability" from one family of mcu's peripherals to another family's peripherals. with that said, however, a great deal of portability can be achieved by the programmer.

Take timers for example. most of the times,  they are set to run periodically. So a typical set of timer routines should allow you to set its timing (period, prescaler, source, etc.) and another set to install a user routine that you want to run periodically. that user routine can be as simple as set or clear a flag, or perform some small actions, like triggering adc, read a set of pins, etc.

If you build your user code on those sets of routines, and develop those routines for different targets, your code can port seamlessly from one family to another, without much / any changes.

kind like low-power consumption coding is more of a software issue than a hardware issue, portability is far more in the hands of the programmer than in the device manufacturers.

[Bruce Abbott]

many of the "portability" is created by users / programmers... portability is far more in the hands of the programmer than in the device manufacturers.

This would be true, except that manufacturers try to be programmers as well. Much of the incompatibility comes from vendors supplying device-specific software frameworks and expecting us to use them rather than produce our own interfaces. So people think they are 'programmers' when in fact they are just stringing together bits of vendor-supplied code. Then they try to port their application to a different device, and discover that their code is incompatible with its framework...

Perhaps that's why everyone is going Arduino now. It may be crappy and inefficient, but at least it works (pretty much) the same no matter what the underlying hardware.

[dannyf]

Take timers for example. most of the times,  they are set to run periodically. So a typical set of timer routines should allow you to set its timing (period, prescaler, source, etc.) and another set to install a user routine that you want to run periodically. that user routine can be as simple as set or clear a flag, or perform some small actions, like triggering adc, read a set of pins, etc.

Here is a live example:

Code: [Select]

//set up timer 0a
tmr0a_init(100); //set up tmr0a - with prescaler
tmr0a_setpr(LED_DLY); //set up tmr0a period
tmr0a_act(led_flp); //install tmr0a handler

//set up timer 4b
tmr4b_init(100); //set up tmr4b - with prescaler
tmr4b_setpr(LED_DLY*1.01); //set up tmr4b period
tmr4b_act(led_flp); //install tmr4b handler

the above code runs on a LM4F120, utilizing two match channels (timer0_a and timer4_b) to control the execution of led_flp(). The very code that I copied those lines from is done via direct register access, and I have the same modules done via Tiva C / driverlib / Stellarisware, from good old LM3S chips to TM4C chips. Depending on the particular implementation, I can link in the right modules and my user code is ready to go, without any understanding of how those routines are actually implemented.

To make matters better, the same implementation has been done on chips from lowly PIC12 to bigger STM32F7 chips.

So, yes, peripherals aren't compatible (other than in rare cases, GD32 vs. STM32 for example). But with a high level language like C and a good programming habit, you can achieve a lot in terms of portability.

[nctnico]

The timers (TIMER A) on msp430 are well thought out and well thought of.
[...8<...]
Wish others, especially ST, had modelled their timers after the TI's.

Though I tend to prefer STM32s to the MSP432 (maybe due to some sort of imprinting), I have to agree here.
HAL or not HAL it's an arcane art to master STM32 Timers while the TimerA model is clean, simple and effective enough.

May like NXP's timers in their LPC ARM chips over the ones in the MSP430/MSP432 ? 

[senseless]

I think there may be some confusion here. Cmsis has nothing to do with the non core related peripherals (like gpio, timers, usarts, etc.). The only "peripherals" covered by cmsis is systixk and nvic, to the extent they are implemented on your chip.

That is not correct. Speaking of CMSIS Core http://www.keil.com/pack/doc/CMSIS/Core/html/index.html it is, but speaking of CMSIS in general, there is a lot more than the core component. For peripherals there is something called CMSIS Driver http://www.keil.com/pack/doc/CMSIS/Driver/html/index.html. Besides that, there is a DSP library and an RTOS included in the more general term CMSIS. I wonder why this is so widely unknown, because the Keil-RTX-based RTOS has a nice BSD license and could be used in commercial products.

[dannyf]

any incredibly wasteful implementation:

Code: [Select]

//set up timer 0a
 tmr0a_init(100);        //set up tmr0a - with prescaler
 tmr0a_setpr(LED_DLY);       //set up tmr0a period
 tmr0a_act(led_flp);        //install tmr0a handler

 //set up timer 4b
 wtmr4b_init(101);        //set up tmr4b - with prescaler
 wtmr4b_setpr(LED_DLY);      //set up tmr4b period
 wtmr4b_act(led_flp);        //install tmr4b handler

It does the same thing as the piece posted earlier. Rather than using the 16-bit timer 4b, it is using the 32-bit wtimer 4b, with a different prescaler but the same period.

if you go back to similar pieces, you will see that if you separate the logic of your code from the implementation of your code, you can write things that can be ported to pretty much any platform: for a long time, most of my mcu code, including my Luminary code, was written on turbo C and Keil C51.

[westfw]

For peripherals there is something called CMSIS Driver

Ah.  New in CMSIS version 4.  the tutorials I've seen only went up the v3, and included the removal of the HAL Peripheral Access Layer.  No one implemented it.  No one seems to have implemented CMSIS-driver, either (except perhaps Keil), and ... it looks sort of gross.  It might be something you could put underneath an OS or "real" filesystem, but pretty far from the sort of APIs I'm used to seeing on deeply embedded systems.  I'm sure people who try to use it will have lots of fun shifting hardware bits into abstracted data structure bits, checking whether the library implements the capabilities they need, and has the right version.  I'm just sorta looking at it thinking: "so what do I need to do to implement the basic getc/putc functions?" and shaking my head :-(

(also, the uart seems to be about the simplest peripheral they bother defining a driver for.  No GPIO. no Timers...)

[dannyf]

I'm reluctant to recommend STM32 but only because its so much more complicated

That's because it is feature rich. Complexity is the price you pay for that.

I can easily replicate what I'm trying to do here with all register ops on TIM1, the most complicated timer on STM32.

and the standard peripheral library is a bit of a mess.

that statement would have a lot more credibility if it is backed up by facts.

[dannyf]

to just show how not-difficult it is to replicate the same on TIM1 (advanced timer) on a STM32 (STM32F100RB in this particular case), here is the user code that does the same thing: blinking an led with variable duty cycle, from 0% to 100%:

Code: [Select]

//initialize the timer
tmr1_init(1000/2); //with a prescaler

//initialize oc1 to call a user handler
tmr1_setpr1(1000); //specify period
tmr1_act1(led_flp); //install user handler

//initialize oc2 to call a user handler
tmr1_setpr4(1000 * 1.01); //specify period
tmr1_act4(led_flp); //install user handler

it looks remarkably similar to the ones posted earlier.

The initialization code, implemented without any use of the ST standard peripheral library, is this:

Code: [Select]

//initialize tmr1 to use compare channels as timers
//16-bit prescaler. 32-bit used for compatability
void tmr1_init(uint32_t ps) {
//route the clock to timer
RCC->APB2ENR |= RCC_APB2ENR_TIMxEN;

//source from internal clock -> disable slave mode
TIMx->SMCR &=~TIM_SMCR_SMS; //clear sms->use internal clock

//stop the timer to configure it
TIMx->CR1 &=~TIM_CR1_CEN; //clear cen. 0=disable the timer, 1=enable the timer
TIMx->CR1 &=~TIM_CR1_CKD; //clear CKD0..1. 0b00->1x clock; 0b01->2:1 clock, 0b10->4:1 clk; 0b11->reserved
TIMx->CR1 &=~TIM_CR1_DIR; //clear DIR bit. 0=upcounter, 1=downcounter
TIMx->CR1 &=~TIM_CR1_OPM; //clear opm bit. 0=periodic timer, 1=one-shot timer
//or to simply zero the register
//TIMx->CR1 = 0; //much easier

//clear the status register bits for capture / compare flags
TIMx->SR &=~(TIM_SR_CC1IF | TIM_SR_CC2IF | TIM_SR_CC3IF | TIM_SR_CC4IF);
//disable the interrupt by clearing the enable bits
TIMx->DIER &=~(TIM_DIER_CC1IE | TIM_DIER_CC2IE | TIM_DIER_CC3IE | TIM_DIER_CC4IE);

//set the prescaler
TIMx->PSC = ps - 1; //set the prescaler
TIMx->RCR = 0; //repetition counter = 0 (=no repetition)
TIMx->ARR = -1; //auto reload register / period = 0; - need to change for downcounters
TIMx->CNT = 0; //reset the counter

//enable the timer.
TIMx->CR1 |= TIM_CR1_CEN; //enable the timer
}

the code to set the period:

Code: [Select]

//set tmr1_oc1 period
//pr is 16-bit. 32-bit used for compatability;
void tmr1_setpr1(uint32_t pr) {
//save the period value
_tmr_oc1 = pr - 1;
TIMx->CCR1 = _tmr_oc1;

//clear the flag
//TIMx->SR &=~TIM_SR_CC1IF; //clear the interrupt flag
//TIMx->DIER &=~TIM_DIER_CC1IE; //disable the isr
}


All the code requires is the standard header file, stm32f10x.h. you can make your life easier with CMSIS' NVIC management functions that even that can be optional.

The code can be easily replicated to cover TIM2/3/4/5, and with minor changes, other simpler timers as well.

As you can see, the code is only marginally more complicated than that for an AVR or a PIC.

[dannyf]

The code can be easily replicated to cover TIM2/3/4/5

Save you some trouble: with no change, the code compiles for TIM2 and runs flawlessly. So it should work also for TIM3/4/5 - that means you can make 4 "timers" out of each of those timers.

[dannyf]

In case someone is interested, I took the approach to a lpc2106 -> the superstar from 10+ years ago,

Code: [Select]

tmr0_init(0x12); //initialize the timer with a prescaler
tmr0_setpr0(0x5678); //set the prescaler
tmr0_act0(led_flp); //install user handler
ei(); //global interrupt enable

it runs TIMER0 at 0x12 prescaler, and then MR0 channel at a 0x5678 increment. The isr calls led_flp().

tmr0_init() initializes the module:

Code: [Select]

//reset tmr with a prescaler
void tmr0_init(uint32_t ps) {
//stop tmr0
CTx->TCR &=~(1<<0); //0=disable timer, 1=enable timer

//reset timer
CTx->TCR |= (1<<1); //1=reset timer on next pusitive edge of pclk, 0=timer can be started

CTx->CTCR &=~(0x03); //0b00->timer mode
CTx->TC = 0; //reset tc -> not needed if TCR is reset first
CTx->PR = ps - 1; //set prescaler

//enable timer
CTx->TCR &=~(1<<1); //1=reset timer on next pusitive edge of pclk, 0=timer can be started
CTx->TCR |= (1<<0); //0=disable timer, 1=enable timer

//now timer is running
}

tmr_setpr() sets the prescaler:

Code: [Select]

//set period register
void tmr0_setpr0(uint32_t pr) {
CTx->MR0 = _tmr_pr0 = pr - 1; //set pr

CTx->IR &=~(1<<0); //clear the flag
CTx->MCR = (CTx->MCR & ~(0x07 << (3*0))) | //clear the mcr bits
(0x00 << (3*0)); //interrupt not yet enabled
}

The whole thing was compiled on Keil uv3 / ADS compiler (really really old). No CMSIS, but the code was adopted from one that I wrote for LPC11xx so you can see the struct approach I took there - the stock lpc210x.h is not used.

As such, the code can be easily modified to run on newer LPC chips which has similar timer peripherals (CT16B0/1 and CT32B0/1).

[dannyf]

Often times people ask "why do you use a commercial IDE?".

to me, it is service and reliability. here, i will show two pictures that I think make a great case for convenience.

The above code was debugged using uv3 - a great little ide - plus an old copy of ADS.

The first picture shows a screen shot when the user handler of led_flp() is being executed for the first time. Compare that vs. the code, and you will be surprised how much information can be captured with just a few numbers.

The 2nd one shows a virtual "logic analyzer" on the IOPIN register -> it reflects the status of the pins.

Once you have used a good IDE, it is hard to go back.

[nctnico]

As an IDE for typing & managing code Keil's uV 3&4 absolutely suck compared to Eclipse. The debugging seems nice to get a quick view of what peripherals do. Then again... how much time does the debugger take from the CPU? IOW how realtime is your software running?

[ataradov]

IOW how realtime is your software running?

Debuggers on ARM are mostly non-intrusive, but they still do affect performance of the system a bit, especially if you use all those rich features like live variable tracking. But if this level of intrusion affects your system, then you probably have a bigger problem in the future anyway.

Debuggers can also cause a bit of havoc when you do live update of peripheral registers - some registers (like flags) are cleared on read, and if debugger get there first, your software will never know that flag was ever set.

[nctnico]

IOW how realtime is your software running?

Debuggers on ARM are mostly non-intrusive, but they still do affect performance of the system a bit, especially if you use all those rich features like live variable tracking. But if this level of intrusion affects your system, then you probably have a bigger problem in the future anyway.

Not necessarily. In several of my projects I'm doing signal processing which can take 80% to 90% of the CPU time but that is all very well defined.

[ataradov]

Not necessarily. In several of my projects I'm doing signal processing which can take 80% to 90% of the CPU time but that is all very well defined.

Debuggers don't take CPU time. They do issue bus transactions, and whether this will be a problem depends on the bus architecture. Most high performance systems will have multilayer bus, so it would not be as big of a problem.

And if you don't use live watch of variables or registers and only use breakpoints, then debugger is completely transparent.

[technix]

I have yet to figure out why I want constructors and destructors with a serial port.

The Serial "objects" in the arduino library are statically allocated, not "constructed" (causing some concern on chips with several serial ports but not much RAM.)  AFAIK, nearly all of the arduino libraries (even from 3rd parties) follow the same model, avoid dynamic allocation, and are based on static creation and "begin" methods rather than constructors.  They seem to take the "don't use malloc on embedded systems" thing petty seriously, AND there's a big problem with using even static constructors of any complexity on AVR, because the constructor code gets called before peripheral initialization.  (when I say they don't use constructors, I mean that they don't use constructors that generate actual code.)

(Sigh.  Except for Strings.  Which are widely avoided due to problems, and/or perceived problems.)

Arduino relied on compiler optimization to remove unused static allocations, so if you only used 1 out of 4 instances of the UART object, only one of them will be present in the final compiled code.

[dannyf]

simulating the use of the PWM0 module on a lpc2148 as 7 independent timers: all done in software, without any actual hardware.

the idea is like from 10 years ago.

can your command line do this?

[nctnico]

Why would you want to do that? Also there are some less well documented features (like setting or resetting the match pins from software IIRC) in those timers so I wonder how the simulator handles those.

[ebclr]

Keil is really much better than those eclipse shit, people that like eclipse are mac users windows user didn't

[ataradov]

Keil is really much better than those eclipse shit

It is also ~$5000  more expensive.

[dannyf]

Keil is really much better than those eclipse shit,

I think so too.

however, the later versions (4.x) got a little too fancy - but still usable. I tried to like 5.x multiple times and never succeeded in convincing myself to use it. the concept of RTE is good and even noble. but not sure if it is practical.

on the plus side, IAR still remains utilitarian. But a little bloated.

[newbrain]

The timers (TIMER A) on msp430 are well thought out and well thought of.
[...8<...]
Wish others, especially ST, had modelled their timers after the TI's.

Though I tend to prefer STM32s to the MSP432 (maybe due to some sort of imprinting), I have to agree here.
HAL or not HAL it's an arcane art to master STM32 Timers while the TimerA model is clean, simple and effective enough.

May like NXP's timers in their LPC ARM chips over the ones in the MSP430/MSP432 ? 

Totally missed this post...or we can pretend to live 6-7 light-days apart!
The answer is: I don't know yet.
Together with a PSoC kit, I also got a 43S67 LPCxpresso board (some people here like to collect DMM or scopes, I go for cheap development kits... ) and I just started the bedtime reading of datasheets.
At first glance, they seem to be easy to use, clearly described and all 32bits to boost!
PWM peripheral does not look much simpler than ST's, though.

[dannyf]

I just started the bedtime reading of datasheets.

Pay very close attention to if the peripherals can be halted in debug.

You will thank me for  that.

[BurnedResistor]

Having started programming on 8bit pics, 32 bit pics and 32bit arm cores (stm nearly exclusively) I would recommend the STM line as a starting point.

The simplisity of setup of PICs MPLAB is very nearly approached by the free version of Keil. If one should outgrow KEIL, the free gcc toolchain is available.

But the main advantage of programming for arm is that there are many more exmaples and explainations. This is only logical as there aer many more arm cores in use, and they share stricking similarities. I personally struggeled with Microchip documentation a lot!

[ez24]

Pay very close attention to if the peripherals can be halted in debug.

You will thank me for  that.

What do you mean?