ARM Cortex for hobbyists - Atmel or STM? Which IDE and tools?

[ebastler]

For my next microcontroller-based hobby project, I would like to try a Cortex-M0 processor. The AVR chips I have relied on for many years feel a bit stale now, so I would like to get some experience with a more modern platform -- even though an AVR would probably be adequate for the task at hand.

From a hobbyist's perspective, which processor family would you recommend: Atmel SAM or STM32? I am mainly after

• a short (ha ha...) learning curve, i.e. IDE and libraries which are "ready to go" and easily set up, and well-structured documentation which allows me to get an overview and get started quickly, then dig deeper where needed; and
• a free IDE and low-cost hardware tools (programmer/debugger).

In contrast, parts cost, a wide selection of chips in the family, or active (first person) support from the manufacturer, all of which may be important for professional use, are less relevant for me.

I appreciate your guidance and comments! Which processor family do you consider "friendlier", and which tools (IDE and hardware) do you use?

(I am aware of the ongoing discussion in this thread, and have found it useful -- but feel that the focus on professional use leads to different conclusions there: https://www.eevblog.com/forum/microcontrollers/atmel-microchip-arm-development/)

[garethw]

I’m in the same position as you. I’m a PIC fanboy so I chose to go down the STM32 route. The ST-Link V3 debugger/ICSP is pretty affordable for a genuine tool (Mine is in the post as I type!).
The only issue I have found is the IC packages available. So far I’ve used DIP packages and the majority of STM32 ICs come in LQFP or TQFP. My solution is to order some breakout PCBs and solder them on. I’ve yet to solder SMD packages so I’m keeping my fingers crossed!

I’ve installed the STM32 CubeIDE. I’ve not used it yet so cannot comment on it but it looks quite straight forward, feels a bit like MPLAB MCC.

Gareth


Sent from my iPhone using Tapatalk

[ebastler]

I have (re-)discovered Jay Carlson's survey of low-cost microcontrollers, their IDEs and development tools. With hindsight, a search shows that this has already been mentioned a few times on this forum, but it bears re-posting:
https://jaycarlson.net/microcontrollers/


I don't put too much weight on the "less than 1$" selection criterion, but most of what Jay says about the development toolchain etc. applies to the whole processor family. I think he did a great job to give an idea of the processor families and development environments.

I need to do some more reading, but at the moment am leaning towards the STM32. My familiarity with Atmel Studio (from earlier AVR projects) would favor Atmel's SAM line, but I am concerned about the ongoing transition from Atmel Studio to MPLAB X. Don't want to start with a proprietary tool which will become obsolete next year...

[Boscoe]

I use STM for all of my projects and it's the only MCU series I've used in anger. I learnt backwards: I used the libraries then worked out what registers they were poking. The documentation for the HAL library is zero. All you get is a PDF with all the functions and a function description which is basically the function name with the words in a different order. But, between the source and some documentation that tells you what registers to poke, you can get an understanding of the drivers and how to use them. It's taken me a good 6 months to become highly proficient with them.

PS. I'm curious as to other's experience with UART reception. In the STM MCU and drivers, you pretty much have to know the length of the data that will be arriving to get fast comms. Anyone have any other experiences?

[Harjit]

I don't have experience with Atmel parts, so this is not a disrecommendation of them.

I have used the STM32 part and it is nice. Yesterday, they released the STM32G4 series and it looks like an amazing part. Super low power, five ADCs, multiple DACs, opamps, comparators, 512k flash, 128k RAM, etc.

[ebclr]

Give a try on mbed https://www.mbed.com/en/

[ebastler]

Give a try on mbed https://www.mbed.com/en/

Interesting, thanks -- I must admit that I had not come across mbed at all. It looks quite impressive, going by the website. What have you used it for, and how did you like it?

mbed seems geared towards specific development boards as the target, rather than the MCU on its own. While the selection of dev boards is large (> 100), it seems limited to boards provided by the MCU manufacturers themselves, and it can't possibly cover all Cortex MCU variants. Is that a real restriction, or can users define their own targets, starting from the MCU alone?

[AloyseTech]

I know you ask between Atmel and STM, but you might want to try Silicon Labs EFM32. Their free IDE works like a charm, their documentation is great and the provided HAL is really good. I’ve tried STM and Atmel before, and I still use them, but I prefer to go the EFM32/EFR32 way when I can.

[Kjelt]

PS. I'm curious as to other's experience with UART reception. In the STM MCU and drivers, you pretty much have to know the length of the data that will be arriving to get fast comms. Anyone have any other experiences?

Yes I ran into that one, the API only works with fixed expected lenths received, if you receive less nothing happens.
So what I did is set length to 1 and on the interrupt only move that byte to my own dedicated uart_x softwarequeue and return.
In the main or other protocol handler module you need it, you check that dedicated queue on lenghth or contents. Problem solved. Just create a queue for every uart, plenty of ram enough.

[techman-001]

PS. I'm curious as to other's experience with UART reception. In the STM MCU and drivers, you pretty much have to know the length of the data that will be arriving to get fast comms. Anyone have any other experiences?

I'm not sure if this is relevant as it doesn't use any STM drivers, but I use a simple assembly coded polled STM32fF051 USART with autobaud and hardware handshaking which works fine up to 460800 Baud (as high as I need).

[ttt]

• a short (ha ha...) learning curve, i.e. IDE and libraries which are "ready to go" and easily set up, and well-structured documentation which allows me to get an overview and get started quickly, then dig deeper where needed; and
• a free IDE and low-cost hardware tools (programmer/debugger).

I've used NXPs (LPC82x, LPC1100 etc.),  Atmel (SAM D21, D51) and ST (STM32F0) parts.

- I find the NXP parts easiest to deal with on a general basis. The pre-programmed boot loader is especially useful if you want to go low cost, i.e. you just need a cheapo UART adapter (with RTS and DTR lines) to program them. There is Flash Magic as a 3rd party programming tool which is super useful for initial setup+debugging. I also find their documentation the best of the three. YMMV.

- The best IDE is provided by Atmel IMHO, you can't beat a Visual Studio (Windows only) based IDE. But you need their proprietary JTAG programmer (Atmel-ICE, $100). Atmel parts usually don't have a default boot loader, JTAG only for programming by default.

- ST parts are somewhat in between convenience wise. Big advantage are the cheaply available boards, especially the Blue Pill boards. And that one is a Cortex-M3 part, so a little better than a Cortex-M0(+). There is also tons of sample code on Github to rely on.

You will find quickly that moving in between Cortex-M0(+), M3 and M4F parts is pretty easy as software wise they are very similar.
 

[HB9EVI]

After using Atmegas for a long time, I plunged into the 32bit mcu world 2 years ago with a Blue Pill; I went down the hard 'bare metal' way, so from beginning folding the datasheets and reference manuals up and down and studying sample codes on the web. In the meantime I'm quite familiar with the whole STM32 family and I like working with then, although for very simple projects I still like using an Atmega8 or Atmega16. SMD is no limitation for me, I even like it cause of the small footprint of the ready circuit, I'm mostly working with the island-cutout technique and dead bug style, but I still use the Atmel as DIPs as well.

It's not an 'either or' question, it fully depends on the needs of the project.

[Siwastaja]

Another thing worth mentioning, if you invest a little bit of extra time and learn the basic toolset (arm-gcc-none-eabi, etc. - you can work with makefiles and any editor, or install & configure a more complex IDE if you really need to, without using the prepackaged stuff from the chip manufacturer), you can shuffle between STM32, Atmel SAM, NXP, and any other modern ARM Cortex MCU's with fairly little pain.

This can be a huge advantage if you have some specific needs w.r.t. peripherals - or may have in the future. I chose STM32 for my "main" family due to a large portfolio of different kinds of parts and fairly low cost, but I found out that the different STM32 sub-families differ so much in their peripherals - even basic things such as UART, I2C, ADC - that I can't fully reuse code and knowledge, and could just as well just have used a NXP or Atmel part whenever necessary!

Physical programming interfaces are different. Being able to reflash through UART without any custom programming tools is a huge benefit IMHO.

[thinkfat]

With nearly all of the STM controllers you can use eclipse together with the 'GNU MCU Eclipse' plugin. Just install through the Eclipse Marketplace.

Might require separate install of openocd.

Or, if you are more a text editor guy, libopencm3 supports a lot of controllers and provides for a much nicer experience than the STM Hal.

Gesendet von meinem Nokia 6.1 mit Tapatalk

[SiliconWizard]

Just an added thought - unless you have very specific reasons to go for Cortex-M0 MCUs (such as unit cost) , I'd favor going for Cortex-M4 ones. These days, if power consumption is another of your reasons, there are many ultra-low power, Cortex-M4-based MCUs that actually draw the same or even less than the M0-based. The M4 have  usually more RAM, an FPU and can run faster... (so yeah, at this point, the main and maybe only reason I would go for M0 is cost only.)

[Just_Understand_It]

Which system did the OP eventually decide on?

[ebastler]

Which system did the OP eventually decide on?

Thanks for asking -- yes, I should have followed up here. I settled on ST Micro for now. For starters, I bought one of the kock-off ST-Link V2 adapters and a little no-name STM32F030F4P6 (Cortex M0) board off ebay, which covers everything I need in my project-at-hand.

I was a bit reluctant to try the new STM32CubeIDE, since it is just out at version 1.0.0, but have found it to be quite manageable. Compared to my earlier AVR experience, the debugger integration via the ST-Link is very nice indeed!

For the last few weeks, I had to put my current project on the back burner -- the weather was too good, and too many things needed attention in the house and garden... So I have just scratched the surface of this new (to me) platform. But I am happy with the first steps so far. Many thanks to all who have contributed their advice and experience here!

[noname4me]

In case this is a factor at all:

I've found the stm32f103 micro easiest to work with simply because of the bluepill boards that you can find floating around on Ebay or Ali Express.

They are cheap enough that you don't mind destroying them with a bad design when you want to iterate; powerful enough that you can do most things,  integrate a couple of ADCs; has the standard UART, SPI, I2C hardware, can do PWM and GPIO stuff without too much headache and has a USB COM port.

If it had a DAC integrated on those boards they would be perfect, but you don't always need that functionality.

I am considering making my own dev board using a different version of the stm32f103 micro which also includes the DAC just to use for quick prototyping,  because of the easy route I had to learning the bluepill with the stm32f103c8t6.

EDIT: forgot to add that the cheap programmer also had an impact on why I chose to start with the STM line
Sent from my SM-N960F using Tapatalk

[techman-001]

In case this is a factor at all:

I've found the stm32f103 micro easiest to work with simply because of the bluepill boards that you can find floating around on Ebay or Ali Express.

They are cheap enough that you don't mind destroying them with a bad design when you want to iterate; powerful enough that you can do most things,  integrate a couple of ADCs; has the standard UART, SPI, I2C hardware, can do PWM and GPIO stuff without too much headache and has a USB COM port.

If it had a DAC integrated on those boards they would be perfect, but you don't always need that functionality.

I am considering making my own dev board using a different version of the stm32f103 micro which also includes the DAC just to use for quick prototyping,  because of the easy route I had to learning the bluepill with the stm32f103c8t6.

EDIT: forgot to add that the cheap programmer also had an impact on why I chose to start with the STM line
Sent from my SM-N960F using Tapatalk

Your post reads like a sales advert!

The STM32F103 isn't really a modern candidate for someone getting into STM Micros because it's a OLD chip, in fact the first 32 bit ARM by STM in 2011.

This chip  lacks more than a DAC:-

Some STM32F103 Limitations
CAN Bus  Shares memory with the USB hardware, which means that USB and CAN cannot be enabled at the same time
Serial Comms  No Autobaud

The famous $3 'Blue Pill' was indeed a great way for the Chinese sellers to get the MCU for almost nothing, even if it was scraped from a e-waste by some guy with a blowtorch. The quality sucks, some don't even have the original STM32F103 but come with the GigaDevices Cortex M3 “GD32F130xx” (64KB Flash MAX) clone.

You get what you pay for.

Then you have 'cheap programmers' some of which that don't implement  ST-Link properly.

I say cut the pain, make your time count and buy a new STM Nucleo or discovery board with the latest feature packed STM32L073 chip, a programmer is included for free, they aren't expensive, I paid $20 AUD for mine. That way you will be learning the latest tech, not old tech.

And it's guaranteed to work, unlike that $3 'Blue Pill'.

[noname4me]

It's all application dependant of course...

For me the most important thing is that I can iterate my designs or ideas quickly...I'm no software/firmware engineer, so will probably never use most of what you said.

Of course the best way is to get the real deal and use that for playing with, but when I dealt with this question I was still a student, so every penny counted.

If I was scared to play with the board in case I broke it it stops me from learning through my mistakes.

I can probably get 10 bluepills for the price of 1 nucleo - if I break one of them, I don't feel as bad

Btw...no affiliation to ST

I have also used good dev boards by Renesas and NXP - both are great, and have ample peripherals.

There are probably other vendors out there that give away free dev boards if you can get to their booth at some convention or expo

Sent from my SM-N960F using Tapatalk

[rstofer]

Give a try on mbed https://www.mbed.com/en/

Interesting, thanks -- I must admit that I had not come across mbed at all. It looks quite impressive, going by the website. What have you used it for, and how did you like it?

mbed seems geared towards specific development boards as the target, rather than the MCU on its own. While the selection of dev boards is large (> 100), it seems limited to boards provided by the MCU manufacturers themselves, and it can't possibly cover all Cortex MCU variants. Is that a real restriction, or can users define their own targets, starting from the MCU alone?

You probably should look a little closer at what 'mbed' means.  Most important is the web based toolchain.  You can work on your code anywhere in the world with just a browser.  Next up, device programming is 'drag and drop'.  This implies that the board have a place to drop stuff so there is a second uC with a bit of memory for holding executable(s).  You might have enough storage for a couple of variants of executables.  Somewhere in the documentation it mentions what to do with this.  The board itself shows up as a mass storage device on your computer.

Many STM boards are compatible but the only device I have used is based on the older LPC1768 and I have several...
https://os.mbed.com/platforms/mbed-LPC1768/

The STM offerings:
https://os.mbed.com/platforms/?q=&Target+vendor=STMicroelectronics

Side issue:  There is no interactive debugger.  You have to use printf() and whatever LEDs the board may have.  Not a big problem, single stepping is a gigantic waste of time.  If you don't put bugs in your code, you won't have to drag them out of your code.

[westfw]

The STM32F103 isn't really a modern candidate for someone getting into STM Micros because it's a OLD chip
[no DAC, CAN/USB issues, no Autobaud]
  :
I say cut the pain, make your time count and buy a new STM Nucleo or discovery board with the latest feature packed STM32L073

Meh.  Unless you specifically need the features provided by the "new" chips, I'll take a 72MHz CM3 over a 32MHz CM0+ any day.

I can probably get 10 bluepills for the price of 1 nucleo

OTOH...  Most Nucleo boards are less than $15 (complete with on-chip debug), so they're pretty good deals.(but ... wow - you really can get a Blue Pill for about $1.50 these days...  I feel so ripped off at the nearly $5 each I paid for some Maple Mini clones back int 2014...)

[ebastler]

You probably should look a little closer at what 'mbed' means. 
[...]
Next up, device programming is 'drag and drop'.  This implies that the board have a place to drop stuff so there is a second uC with a bit of memory for holding executable(s).  You might have enough storage for a couple of variants of executables.  Somewhere in the documentation it mentions what to do with this.  The board itself shows up as a mass storage device on your computer.

Thanks for the additional background! I had figured out that specific development boards are needed as targets, but not what specific technical requirements were driving that.

Anyway, the limitation alone was enough to deter me from trying mbed, as I want a development environment that works for "deployed", simple microcontroller boards as well.  As stated in my most recent post, I am using STM32CubeIDE and an ST-Link V2 clone now.

[rstofer]

You probably should look a little closer at what 'mbed' means. 
[...]
Next up, device programming is 'drag and drop'.  This implies that the board have a place to drop stuff so there is a second uC with a bit of memory for holding executable(s).  You might have enough storage for a couple of variants of executables.  Somewhere in the documentation it mentions what to do with this.  The board itself shows up as a mass storage device on your computer.

Anyway, the limitation alone was enough to deter me from trying mbed, as I want a development environment that works for "deployed", simple microcontroller boards as well.  As stated in my most recent post, I am using STM32CubeIDE and an ST-Link V2 clone now.

Well, the deployed MCU has to plug into something in order to be reprogrammed.  There's nothing wrong with ST-Link V2 (and it comes as a break-off chunk of many development boards) but, in the end, it requires a USB cable to <somewhere>, probably a laptop.  So does the mbed...

Nothing wrong with ST-Link and I'm not selling mbed but I do find it especially convenient when I use a stamp form factor like the LPC1768 version. I simply solder the module down to a daughter card.  All the complicated design is on the module.  All I have to do is deal with the peripherals, power and ground.

Were I doing production, I probably wouldn't use mbed...  But I would still have to deal with reprogramming.

[thinkfat]

If you're looking for an MCU that is  really easy to integrate, check out the STM32F042 series or STM32F072. You basically only need to hook up a power supply and put a USB receptacle and you're all set. The thing has a USB function for DFU protocol integrated into the mask ROM, you just need to pull the BOOT0 pin high and reset it, and it will show up on your PC ready to accept the program binary. No crystal needed, no other components, no programming adapter. It almost makes no sense to use a breakout board with this controller if you make a PCB anyway.

Of course you can still break out SWD and RESET signals to a programming header if you want to do inline debugging, but just for software uploads it's not required. Really convenient in production, too.