Next step from AVR

[Deku Tree]

I'm graduating in a few months and have spent about a year working with the Atemga128 in various classes. My latest projects have mostly been with the Attiny85 but these chips are pretty expensive compared to some of the STM32 variants that offer way more functionality. With this in mind, what would you all suggest as a next family of microcontrollers? What would be good for both my own personal development as an (aspiring) embedded guy and for my wallet?


A note I'd like to add: all my work with these boards has been with the linux toolchain rather than an Arduino IDE

[technix]

STM32 and ARM in general is a good direction to take. ARM has an fully free and open source development environment (Eclipse CDT + GNU MCU Eclipse + GCC ARM Embedded toolchain, GDB + OpenOCD + CMSIS-DAP programming and debugging tools, all of which are open source and support Linux, Windows and macOS)

[HB9EVI]

+1 for above statement

[Mr. Scram]

STM32 and ARM in general is a good direction to take. ARM has an fully free and open source development environment (Eclipse CDT + GNU MCU Eclipse + GCC ARM Embedded toolchain, GDB + OpenOCD + CMSIS-DAP programming and debugging tools, all of which are open source and support Linux, Windows and macOS)

I'd say that long list of applications and not having a proper manufacturer supplied IDE is a strike against STM. That toolchain seems to have the typical open source issue of being fragmented all over the place.

[brucehoult]

STM32 and ARM in general is a good direction to take. ARM has an fully free and open source development environment (Eclipse CDT + GNU MCU Eclipse + GCC ARM Embedded toolchain, GDB + OpenOCD + CMSIS-DAP programming and debugging tools, all of which are open source and support Linux, Windows and macOS)

I'd say that long list of applications and not having a proper manufacturer supplied IDE is a strike against STM. That toolchain seems to have the typical open source issue of being fragmented all over the place.

I don't want some opaque manufacturer-supplied IDE .. ugh!

The only essential parts are

1) a C compiler and/or assembler for the CPU. That's gcc and binutils and glibc/newlib.

2) a way to get the compiled binary onto the board/chip. That's avdude or gcc+OpenOCD and maybe some JTAG or FDTI hardware

Each piece exists because it has a limited and well defined job to do, and can be swapped out for something else doing an equivalent job depending on the situation.

Eclipse is just for text editing and project build. That's absolutely independent of the CPU or board you're targeting. I prefer to use the text editor of my choice and gmake or cmake/ninja.

It's pretty easy to understand what is going on with your set of specialised tools, and they can be adapted to many purposes. It's just awful to try to figure out why some all-in-one vendor IDE isn't working.

[rstofer]

The next step is ARM <something or other>, no question about it.  There is a question whether STM32 is the way to go but there is a book, "Mastering STM32" that will hold your hand starting with installing Eclipse and GCC and working up.

https://leanpub.com/mastering-stm32

Any time you can get a book, it's a good place to start.

Another way to go:  Look at mbed.org and, specifically, the original mbed (LPC1768).  I use these all the time and I really like the online toolchain.  I don't have to install anything, the binary is 'drag and drop' onto the device and I can work on my code from any PC in the world that has a web browser.  Yes, there are detractors, but ask if they ever did a sizable project actually using the tools.  Mostly it's opinion "I don't like online...".

You will also notice that some STM32 boards are also 'mbed compatible' and you will find them listed on the mbed.org site.  I'm not sure how well supported they are but the 'drag and drop' will work and that's the important bit.

The mbed infrastructure does not include a hardware debugger.  Fine!  Just use printf().  I have never found single stepping to be all that productive anyway and I've been doing it for almost 50 years (started in '70).

For a first attempt, I think the "Mastering STM32" is the way to start.

Completely different:  Cypress PSOC 6 (or PSOC 4 and PSOC 5).  There are terrific videos on how to use the boards and the toolchain creates a lot of the underlying code.  There is also a graphical component where you lay down the peripherals you will use and interconnect them as necessary.  When you build the configuration, all the support code is generated.  This is a VERY nice development environment.  The PSOC 6 has two ARM cores, an M0 and an M4.  One can be used to support tasks with high compute needs and the other might support IO.  But both devices have access to all peripherals and memory.

[Mr. Scram]

I don't want some opaque manufacturer-supplied IDE .. ugh!

The only essential parts are

1) a C compiler and/or assembler for the CPU. That's gcc and binutils and glibc/newlib.

2) a way to get the compiled binary onto the board/chip. That's avdude or gcc+OpenOCD and maybe some JTAG or FDTI hardware

Each piece exists because it has a limited and well defined job to do, and can be swapped out for something else doing an equivalent job depending on the situation.

Eclipse is just for text editing and project build. That's absolutely independent of the CPU or board you're targeting. I prefer to use the text editor of my choice and gmake or cmake/ninja.

It's pretty easy to understand what is going on with your set of specialised tools, and they can be adapted to many purposes. It's just awful to try to figure out why some all-in-one vendor IDE isn't working.

Needing to piece together a toolchain is what I was talking about. Open-source is great, but unfortunately often leads to fragmentation and having many alternatives that are both functional and broken in very similar but slightly different ways. Finding out what is misbehaving can be a pain and people always seem to be using different tools when you look for guidance or help.

I'm not saying vendor IDEs are ideal or perfect, mind. I think few would want to argue that.

[FERCSA]

OP. Did you use arduino with atmega/attiny? Probably, so give a spin for the ESP32 platform, but if you really into electronics not just programming, PSoC is a great platform with a ton of doc, tutorial, etc.

One thing for sure, next step should be a ARM based uC.

[Deku Tree]

Looks like ARM is the general consensus then? One thing I do like is the opensource toolchain you guys mentioned.

I actually purchased that Mastering STM32 book, and began reading it about 6 months ago. I ended up just giving up on it because the whole development environment seemed so fragmented. I still have a Nucleo board and a copy of the book, maybe I'll try and take another stab at it. One thing I've really liked about working with AVR has been that I know exactly what's happening from when I write the code, to compilation, and then onto the board. With the STM32 is seems like in an effort to make it easier, many of the available tools hide a lot, making it difficult to debug anything.

If I do decide to start with ARM, what would you all suggest as an inexpensive development board to get started? I'm checking out that mbed board now, looks promising.

edit; Just a quick clarification; it's my understanding that at their core the STM32 series contain an arm processor along with additional functionality, is this correct? If so, it seems like the best choice to ease into the STM32 world would be to start with a simple ARM MCU and then transition to the STM32 once I'm comfortable?

[brucehoult]

I don't want some opaque manufacturer-supplied IDE .. ugh!

The only essential parts are

1) a C compiler and/or assembler for the CPU. That's gcc and binutils and glibc/newlib.

2) a way to get the compiled binary onto the board/chip. That's avdude or gcc+OpenOCD and maybe some JTAG or FDTI hardware

Each piece exists because it has a limited and well defined job to do, and can be swapped out for something else doing an equivalent job depending on the situation.

Eclipse is just for text editing and project build. That's absolutely independent of the CPU or board you're targeting. I prefer to use the text editor of my choice and gmake or cmake/ninja.

It's pretty easy to understand what is going on with your set of specialised tools, and they can be adapted to many purposes. It's just awful to try to figure out why some all-in-one vendor IDE isn't working.

Needing to piece together a toolchain is what I was talking about. Open-source is great, but unfortunately often leads to fragmentation and having many alternatives that are both functional and broken in very similar but slightly different ways. Finding out what is misbehaving can be a pain and people always seem to be using different tools when you look for guidance or help.

I'm not saying vendor IDEs are ideal or perfect, mind. I think few would want to argue that.

OK, I'll admit I don't know exactly what typical ARM vendors do.

With our $59 HiFive1 Uno-compatible 320 MHz RISC-V board ...

https://www.crowdsupply.com/sifive/hifive1
https://nz.mouser.com/ProductDetail/Crowd-Supply/cs-hifive1-01?qs=wd5RIQLrsJiLD253rjAssQ%3D%3D

... here's what you do to get a functioning command line toolchain and run your first program:

git clone --recursive https://github.com/sifive/freedom-e-sdk.git
cd freedom-e-sdk
make tools

That checks out and builds binutils, gcc, newlib, gdb, openocd. Everything you need. Takes about 20 minutes on my NUC, or 3 minutes on a big i9 or ThreadRipper.

make software PROGRAM=hello
make upload PROGRAM=hello

That's *it*.

OR, you can use a pre-built version of the toolchain. OR and Eclipse-based IDE. OR the standard Arduino IDE you already have (pasting our tools URL into a dialog box in the IDE).

Plenty of choices for everyone, and they all work.

It's all in the "Getting Started" document https://static.dev.sifive.com/dev-kits/hifive1/hifive1-getting-started-v1.0.2.pdf

[Mr. Scram]

Looks like ARM is the general consensus then? One thing I do like is the opensource toolchain you guys mentioned.

I actually purchased that Mastering STM32 book, and began reading it about 6 months ago. I ended up just giving up on it because the whole development environment seemed so fragmented. I still have a Nucleo board and a copy of the book, maybe I'll try and take another stab at it. One thing I've really liked about working with AVR has been that I know exactly what's happening from when I write the code, to compilation, and then onto the board. With the STM32 is seems like in an effort to make it easier, many of the available tools hide a lot, making it difficult to debug anything.

If I do decide to start with ARM, what would you all suggest as an inexpensive development board to get started? I'm checking out that mbed board now, looks promising.

edit; Just a quick clarification; it's my understanding that at their core the STM32 series contain an arm processor along with additional functionality, is this correct? If so, it seems like the best choice to ease into the STM32 world would be to start with a simple ARM MCU and then transition to the STM32 once I'm comfortable?

Maybe the aforementioned PSoC family is worth a shot. It provides a fairly decent experience and information and is quite versatile. They have various cheap and less cheap development boards.

[Deku Tree]

Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

[ataradov]

Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

Don't look at RISC-V if you want practical knowledge usable right now, not in 5-10 years, if ever.

There are plenty of cheap ARM boards from manufacturer supplied with integrated debuggers and all the bells and whistles to some very cheap eBay stuff from China. But you need to pick a chip vendor first, otherwise there are just way too many options.

Boards with integrated debuggers are a bit more expensive, but they are all you need to start. Cheaper boards will require external debugger to program them. Some chips will have bootloaders, but spare yourself some pain and get a real debugger, they are not that expensive.

[Mr. Scram]

Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

What did you find? Basic PSoC 4 and PSoC 5 boards go for under or around to 10 bucks. These are breadboardable and come with a snap off programmer. A PSoC 4 board used in many of their videos is about $25. They have both simple and fancy boards for pretty much any budget, but most won't break the bank.

I personally feel the FPGA-like fabric in many models is a pretty neat party trick. No need for many variants, you just configure the hardware as you please. If you know your way around Verilog you can even write your own components.

[NorthGuy]

I'd say start from real project - something you want to create. Then select an MCU which will do the job for you, other parts, prototype it, design a board, build it, use it.

If you march on "mastering" all the MCUs one by one, it will not do you any good, and without real projects it will be all boring and useless anyway.

[Deku Tree]

Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

Don't look at RISC-V if you want practical knowledge usable right now, not in 5-10 years, if ever.

There are plenty of cheap ARM boards from manufacturer supplied with integrated debuggers and all the bells and whistles to some very cheap eBay stuff from China. But you need to pick a chip vendor first, otherwise there are just way too many options.

Boards with integrated debuggers are a bit more expensive, but they are all you need to start. Cheaper boards will require external debugger to program them. Some chips will have bootloaders, but spare yourself some pain and get a real debugger, they are not that expensive.

Do you suggest against RISC-V because it's too new? I'm not really familiar with it.

As for those cheap ARM boards, I'm getting overwhelmed by all the options! Are there any that you have used successfully in the past that might help guide my search?

Thank you all for being so patient with me, this is a bit leap for me!

[ataradov]

Do you suggest against RISC-V because it's too new? I'm not really familiar with it.

Not only it is new, there are no good MCU-class devices on the market. FE310 is an engineering prototype for sale at best. 

As for those cheap ARM boards, I'm getting overwhelmed by all the options! Are there any that you have used successfully in the past that might help guide my search?

Not really. I work for Microchip, so I have easy access to Microchip development kits. Other than that, I just make my own boards with the peripherals I need for a project.

But they all work the same. It is just a board. What really matters is the used MCU. Once you decide that, you can pick any board you like that fits into your price range. But don't go too cheap for a first board. You don't need extra problems just because the board required extra fiddling.

It is also important to figure out what IDE/Toolchain you want to use, since this will define compatible debuggers/programmers.

[SiliconWizard]

Of course looking at ARM is a wise direction and you should certainly do that to complement your technical culture and help your short-term employability.

That said, looking at other architectures (even though there are not many anymore) will also expand your horizons. So a look at the Microchip products (8, 16 and 32-bit) would be valuable as well.
You can take advantage of this questioning of yours to start an habit of continuous watch for new technology and products. This will prove very useful for the rest of your career.

[brucehoult]

Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

Don't look at RISC-V if you want practical knowledge usable right now, not in 5-10 years, if ever.

Oh, come on. That's purest FUD.

If you said 1-2 years for hobbyists or small scale board manufacture using off the shelf MCU chips I'd agree with you.

People who are serious about manufacturing in volume want custom SoCs with everything they need already on them, not piece it together from a board full of chips. RISC-V is already in those markets with half a dozen companies having announced things like SSD/flash controllers and wearables/IoT chips, and a long funnel of other products in development.

Obviously, the volumes are small compared to ARM right now, but claiming it's not viable or relevant is ridiculous.

[ataradov]

Oh, come on. That's purest FUD.

It is not. I want RISC-V to succeed. But the reality is that if you go and look for a job right now, you will find plenty of ARM jobs and next to none of RISC-V.

There are no good general purpose RISC-V devices on the market. And I would let consumers decide what they want on their boards. Not everyone can afford an ASIC. And it is good that RISC-V finds its use in ASICs, but this is not applicable to this thread.

If you said 1-2 years for hobbyists or small scale board manufacture using off the shelf MCU chips I'd agree with you.

Do you think OP is a WD-scale enterprise that will roll an ASIC?  I don't think so. And otherwise the only useful RISC-V hardware at the moment is FE310, which is super weak as far as MCUs go.

There is a long road ahead for RISC-V before it will get into common MCUs.

[brucehoult]

Oh, come on. That's purest FUD.

It is not. I want RISC-V to succeed. But the reality is that if you go and look for a job right now, you will find plenty of ARM jobs and next to none of RISC-V.

Ah, that takes me back!

"The reality is that if you go and look for a job right now, you will find plenty of PDP11 and VAX jobs and next to none of 8086 or 68000".

And it's true, for two years my first job was on Data General Eclipse MV/10000. But then we got 80386 and 68020 and SPARC and pretty soon those things were stone dead.

[ataradov]

OP needs to learn something now. And "now" ARM is the best option, like it or not. Jumping from ARM to RISC-V takes minutes, so it is not a big deal. Hopefully by the time there is a need to jump, there is a RISC-V MCU with more than 4 basic peripherals.

[Mr. Scram]

Ah, that takes me back!

"The reality is that if you go and look for a job right now, you will find plenty of PDP11 and VAX jobs and next to none of 8086 or 68000".

And it's true, for two years my first job was on Data General Eclipse MV/10000. But then we got 80386 and 68020 and SPARC and pretty soon those things were stone dead.

I think the point was that "pretty soon" is not now. ARM is a thing now and will be in the foreseeable future.

[donotdespisethesnake]

OK, I'll admit I don't know exactly what typical ARM vendors do.

With our $59 HiFive1 Uno-compatible 320 MHz RISC-V board ...

You seem very desperate to flog your RISC-V stuff, spamming any thread you can. Are sales slow?

I was sort of interested in RISC-V, but now it's on my "don't use, don't recommend" list. If an organization needs to spam everywhere to flog it's product, it's not worth using.

OP: forget about RISC-V, it's a dead end. Buy a $2 STM32 board. As far as ARM goes, they are as simple as they go, and a good entry point.

[brucehoult]

Jumping from ARM to RISC-V takes minutes, so it is not a big deal.

And vice versa.