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

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