What is the next step from 8bit Arduino?

[honeybadger]

Hi,
I would say I have a decent amount of experience with Arduino and AVR in general but my projects are hitting the limits of 328 and I don't want to make so many compromises and use external ICs. What is the next step from 328? (I would like to stay away from Mega2560, AVR32, not sure about Xmega)

I aim for more features, 12bit ADC, more external interrupts, DAC would be nice and some kind of at least basic debugging. I/O count and computational power is not a problem for me even with 328.

From what I see STM32 is dirt cheap but has rather poor documentation.
ATSAMD looks promising and Atmel Studio looks also good.

I love Arduino for not messing with registers all the time. It just works. Maybe it is not the best and fastest approach from hardware point of view but it is easy and fast to make ideas into prototypes - this is important for me.
Is there something similar for STM32 or ATSAMD?
What about libraries? I guess I won't be able to use the huge support Arduino has.

What is better (more user friendly, more "future proof") for ATSAMD/Atmel Studio?
ATATMEL-ICE-BASIC or Segger J-LINK EDU?
Or is there any other cheaper alternative just for Cortex-M0 (with debugging)?

[ataradov]

How exactly is STM32 documentation poor? Are you sure you are not making a common mistake of mixing the datasheet and a reference manual? They are two different documents and the datasheet is very brief, and all the useful information is in the reference manual.

In general things are pretty cheap. Try both and see which one you like more.

If you will decide to stick with SAM D, then getting Atmel/Microchip tools is the way to go. AS does not have the best support for the third party tools.

[ogden]

I love Arduino for not messing with registers all the time.

You may feel at home: https://www.instructables.com/id/Small-But-Powerful-STM32/ Note that "blue pill" board is even better choice for stm32duino experiments because when you are done, you have "upgrade path" to native stm32 development - because of SWD debug connector.

[newbrain]

There are many choices when going from Arduino to something more powerful and closer to the metal.

• Some ports of Arduino to other MCU exist, e.g. Energia os as odgen says stm32duino (but the site has gone).
• You might try mbed, the platform runs (with some difference in support) on many MCUs and (cheap) development boards.
  It's also remotely similar to Arduino in the level of abstraction.
• You could go to low level programming, using a vendor provided library to initially simplify the development.
• Or you could go commando, with direct register manipulation and write your own library and drivers. 

Each one of these alternative has advantages and drawbacks, my choice has been number 3, trending to 4 - but I skipped Arduino altogether (don't like Wiring, hate the IDE).

What follows holds for ST's STM32, but very similar consideration are valid for other vendors and MCUs (e.g. NXP and Kinetis/LPC)
Getting started with a Nucleo or Discovery board is very cheap and the debugger is integrated (ST-Link V2.1).
A code generator to create the skeleton of an application (CubeMX) is available, as is a free IDE (Eclipse based - as most are, unfortunately).
Though the HAL library can be criticized under many aspects it's an easy way to start.

As for all the libraries available for Arduino, they can often be easily ported: if you are communicating with an I2C sensor or an SPI LCD display, the value added added part is the specific protocol implementation, not the primitives used to read from or write to the interface.

If you are specifically after Cortex-M0 IDE, consider that for STM32F0 and L0 Keil MDK is free.

From what I see STM32 is dirt cheap but has rather poor documentation.

Really? I find it one of the best. Don't be scared, it's usually huge but decently organized.

[jonroger]

Both teensy and mbed have worked well for me.

[JustMeHere]

ESP32

[Psi]

From what I see STM32 is dirt cheap but has rather poor documentation.

How exactly is STM32 documentation poor? Are you sure you are not making a common mistake of mixing the datasheet and a reference manual? They are two different documents and the datasheet is very brief, and all the useful information is in the reference manual.

Na i agree with him. 
STM32 documentation is quite annoying compared with AVR.  AVR documentation is right up near the top when it comes to well written documentation, it's very readable. So if you're use to AVR's then moving to other platforms can be a shock.

I wouldn't say STM32 documentation is bad, but it's harder to find anything in the datasheets. 
You kinda have to take screenshots of all the important info and past that into another document because it's hard to quickly find it again when you need it.
Also having multiple datasheets makes this even more annoying as you don't even know which datasheet contains what you want.

I think some of the issues stem from STM32 having more complicated peripherals which makes them more complex to use.
Also with AVR the hardware registers were designed to be human readable and human usable.
With STM32 (and many other 32bit MCUs) they expected a HAL layer to talk to the registers and not the programmer directly.  So you see bits/flags thrown in random register locations that was easier to do on the silicon but make little sense otherwise.

[honeybadger]

ataradov: Maybe I am biased against ST documentation because I am used to Atmel datasheets. I will see the reference manual.

ogden: Oh, I almost forgot about blue pill boards. I will have a look.

newbrain: The thing is I don't want to go "closer to the metal". I don't need to efficiently use every clock cycle for my projects. I just want to get the job done. The easier it will be the better. Programming is necessary evil for me I do it for the product itself not to spend hours and hours programming.

I must say HAL for STM32 looks promissing.

So I guess it is between:
ATSAMD + ICE + Atmel Studio
and
STM32 + ST-LINK + STM32CubeIDE

Do I understand correctly that with ST-LINK I also can use breakpoints, view registers and read selected variables real-time?

[nctnico]

IMHO the LPC ARM microcontroller series from NXP is worth a look. They are easy to program using a serial bootloader and the documentation is simple to follow.

[ataradov]

Hard to find things is a function of a device complexity. AVRs are trivially primitive by modern standards, so yes, the documentation is easier to read. But if you want more power, you will have to deal with more complexity. In the ARM world, ST documentation is quite good. There are always things to be improved, but not using them because of the documentation is a wrong move.

[Psi]

For me, the number 1 worst thing with STM32 is the different versions of the standard peripheral library because it makes it hard to use example code.
Googling for code usually comes up with examples you can't use because they are for a different version of the library.
However there is no way to know you can't use it until you try it and get an error that some library call does not exist for you.
IMHO they should have included the version number in all the call names.  So it's obvious when looking at code what library its using.  3 extra char in each name is a small price to pay in extra typing if it makes it super easy to find example code using your library version.

Don't get me wrong, i'm not say STM32 is bad, i use STM32 a lot.

[nctnico]

For me, the number 1 worst thing with STM32 is the different versions of the standard peripheral library because it makes i hard to use example code.

Don't get me wrong, i'm not say STM32 is bad, i use STM32 a lot.

The wide variety of peripherals with the same function has always kept me from using the STM32. I know I sound like a broken record but the LPC series from NXP uses the same peripherals across the entire range of the devices. Code written for one device can be taken to the next device without needing a massive rewrite.

[mariush]

The Silicon Labs microcontrollers based on ARM Cortex M0 , M3 and M4 cores seem interesting to me: https://www.digikey.com/short/p0793v
You may want to check documentation and if they're something you may be interested in.

What you learn using ARM M0 and M4 should be in most part reusable with other microcontrollers with ARM cores.

The 16 bit TI MSP430 could be fun to learn and play with, as something between 8bit and 32bit that's also available cheaply.  See https://www.digikey.com/short/p079hz
Also, it uses FRAM instead of flash, which makes it possible to use that memory for various things you may be reluctant to use flash memory for.

RISC-V microcontrollers would be fun to play with, new architecture, open source
GigaDevice seems to be the first to make a microcontroller, GD32V, using this RISC-V stuff : This page has more info: https://www.gigadevice.com/products/microcontrollers/gd32/risc-v/
Here's a manual for the GD32V103 from their site (it loads slowly but it loads) : http://gd32mcu.21ic.com/data/documents/shujushouce/GD32VF103_User_Manual_EN_V1.2.pdf

[EverydayMuffin]

For getting started with Arm M0 micros, I'd look Cypress PSoC 4. The documentation is great and it's very easy to get started with.

[floobydust]

STM32 lineup has no EEPROM??  I know the Bluepill is missing it and you always have to add one.

[ataradov]

None of the ARM chips will have on-die true EEPROM. It is not compatible with modern manufacturing processes. Some vendors use flash and add software or hardware emulation.
But given how easy it is typically to write the flash from the running application on ARMs, lack of EEPROM is not such a huge deal.

[westfw]

Is there something similar for STM32 or ATSAMD?
What about libraries? I guess I won't be able to use the huge support Arduino has.

What is better (more user friendly, more "future proof") for ATSAMD/Atmel Studio?
ATATMEL-ICE-BASIC or Segger J-LINK EDU?
Or is there any other cheaper alternative just for Cortex-M0 (with debugging)?

Well, SAMD has quite a bit of Arduino support.   The "pro" non-Arduino libraries include Atmel's ASF and Atmel Start, but they both suck.There are other programming environments that may or may not work.
I'd rate "Atmel Studio" as somewhat NOT future-proof now that Microchip owns it (and has a competing development environment: MPLABX, which currently has "some" ARM support.)  For example, they drastically changed all the CMSIS definitions (register-level access to peripherals) to have better compatibility between ARM and PIC32 (or something.)
The Microchip SNAP is a current low-end programmer (currently on sale for about $8.  Normally $16.)  I'm not sure about how well it works with ARM, but it is a do-almost-everything programmer/debugger (PIC, PIC32, AVR, ARM...)

[jhpadjustable]

I love Arduino for not messing with registers all the time. It just works. Maybe it is not the best and fastest approach from hardware point of view but it is easy and fast to make ideas into prototypes - this is important for me.

If you're not wedded to having a comprehensive collection of pre-made libraries of varying quality, and you're not particularly interested in a professional workflow, you might enjoy a switch to an interactive paradigm, such as an eLua-based thing like NodeMCU for the ESP chips, or one of the Forths or microPythons for whatever chip. The best part is that you don't really need to worry about host software or IDEs very much or at all. You construct a standard image with whatever builtins you desire and load it into a blank chip via the appropriate flashing tool. Hyperterm is usually enough from there on out. Compiling just gets in the way of getting stuff done.

[e100]

I'm going down the same path as you and I'm about to start using the Cypress PSOC CY8CKIT-059.
I chose it not because of price, or because it has lots of modern features (although the programmable hardware does seem interesting) , but because it has a hardware debugger and there were so few complaints about the documentation, IDE and support materials. I think of it as the "if people say it isn't terrible then it must be OK, right?" method of choosing a platform.

It's not cheap by Arduino standards and library support is a fraction of what you'll find in the Arduino community. I guess it'll be awhile before I find out if I've made the right choice.

In the professional world volume pricing is usually everything and as a consequence developers are prepared to put up with truly awful tools and documentation in exchange for shaving a few cents of the cost of a production run where thousands or millions of devices are being purchased. None of this applies in the hobby world which is why many professionals struggle to comprehend why the Arduino or Micropython platforms even exist.

[nctnico]

In the professional world volume pricing is usually everything and as a consequence developers are prepared to put up with truly awful tools and documentation in exchange for shaving a few cents of the cost of a production run where thousands or millions of devices are being purchased. None of this applies in the hobby world which is why many professionals struggle to comprehend why the Arduino or Micropython platforms even exist.

Pricing isn't everything in the professional world. Actually only a handful of people out of thousands work in projects with enough volume to start looking at the price of a device. Engineering costs dominate the rest but that is often overlooked and people still go chasing cheap devices which in the end cost more due to higher engineering costs.

[Psi]

STM32 lineup has no EEPROM??  I know the Bluepill is missing it and you always have to add one.

None of the ARM chips will have on-die true EEPROM. It is not compatible with modern manufacturing processes.

The STM32F series has no EEPROM.
However the entire STM32L0 and STM32L1 series do.  They have true EEPROM built in, not emulated with flash.

[Ed.Kloonk]

ataradov: Maybe I am biased against ST documentation because I am used to Atmel datasheets. I will see the reference manual.

ogden: Oh, I almost forgot about blue pill boards. I will have a look.

newbrain: The thing is I don't want to go "closer to the metal". I don't need to efficiently use every clock cycle for my projects. I just want to get the job done. The easier it will be the better. Programming is necessary evil for me I do it for the product itself not to spend hours and hours programming.

I must say HAL for STM32 looks promissing.

So I guess it is between:
ATSAMD + ICE + Atmel Studio
and
STM32 + ST-LINK + STM32CubeIDE

Do I understand correctly that with ST-LINK I also can use breakpoints, view registers and read selected variables real-time?

Raspberry Pi any use to you?

[honeybadger]

Thank you all. I am 90% decided to go the STM32 + ST-LINK + STM32CubeIDE way.

The missing EEPROM makes me sad but the FLASH should have 10k write cycles, that should be enough for me. SAMD does not have EEPROM either.

As I found out when the ST bought Atolic they made the PRO version free and it allows live variables watch with standard ST-LINK.

[ataradov]

However the entire STM32L0 and STM32L1 series do.  They have true EEPROM built in, not emulated with flash.

Application note AN4808 suggests otherwise:

When designing an application that utilizes the EEPROM data memory on single bank
device, it is necessary to clearly identify the timing constraints and requirements.
There are basically two options:
1. Have the code necessary for any action that may occur during the write operation in the
volatile memory (RAM)
2. Postpone the writing to a quieter moment, when no immediate action is necessary.
In this application note we assume that the second option is not applicable, hence the first
one must be implemented.
It is necessary to initiate the data EEPROM writing from the RAM as well. When the
execution is stalled due to fetch attempt from the busy NVM, neither events or interrupts are
processed until the BSY flag is released. Having the interrupt code in RAM is not enough to
wake the MCU.

This clearly indicates that EEPROM is emulated and is contained in the same bank of the flash memory.

Some SAM devices have a smaller additional flash bank specifically for that reason.

[newbrain]

Thank you all. I am 90% decided to go the STM32 + ST-LINK + STM32CubeIDE way.

Good!
It is a safe (and fun) choice, and if in the end you discover the HAL is not to your taste, given the wide support STM32 has, you can find many alternatives!

I'm going down the same path as you and I'm about to start using the Cypress PSOC CY8CKIT-059.
I chose it not because of price, or because it has lots of modern features (although the programmable hardware does seem interesting) , but because it has a hardware debugger and there were so few complaints about the documentation, IDE and support materials. I think of it as the "if people say it isn't terrible then it must be OK, right?" method of choosing a platform.

It's not cheap by Arduino standards and library support is a fraction of what you'll find in the Arduino community. I guess it'll be awhile before I find out if I've made the right choice.

PSoC 5 is an incredibly fun platform, and still my go-to one when I need some sparse logic or a bit of analogue/mixed HW*. Verilog programming is an added bonus!
The libraries are IMO quite decently written and feel natural to program in. The IDE is unfortunately Windows only, somewhat old-style (looks a bit like an ancient version of Visual Studio) and with a clunky schematic editor, but workable - luckily, as there are no alternatives for the programmable HW design!
Though the chip themselves are high priced the PSoC5-on-a-stick kit is still very cheap!

*I did not think of suggesting it, as it is a bit "different", and the learning curve from Arduino is already steep enough...

[techman-001]

However the entire STM32L0 and STM32L1 series do.  They have true EEPROM built in, not emulated with flash.

Application note AN4808 suggests otherwise:

When designing an application that utilizes the EEPROM data memory on single bank
device, it is necessary to clearly identify the timing constraints and requirements.
There are basically two options:
1. Have the code necessary for any action that may occur during the write operation in the
volatile memory (RAM)
2. Postpone the writing to a quieter moment, when no immediate action is necessary.
In this application note we assume that the second option is not applicable, hence the first
one must be implemented.
It is necessary to initiate the data EEPROM writing from the RAM as well. When the
execution is stalled due to fetch attempt from the busy NVM, neither events or interrupts are
processed until the BSY flag is released. Having the interrupt code in RAM is not enough to
wake the MCU.

This clearly indicates that EEPROM is emulated and is contained in the same bank of the flash memory.

Some SAM devices have a smaller additional flash bank specifically for that reason.

I believe that there may be other reasons for  AN4808.

The EEPROM data memory is in the same functional area as the rest of the NVM as can be seen from the attached pic but that doesn't have to mean it is also Flash does it ? Just being on the same bus as the Flash could explain AN4808 ?

Besides,  STM clearly state "­ 12 Kbytes of true EEPROM with ECC" in October 2017  DocID022268 Rev 10. There are no reasons for them to lie so blatantly and many legal reasons not to.

[usagi]

for pure arduino IDE development, samd21 "M0+" based boards is the way to go. arduino support is quite mature for this cpu. i'm a fan of the adafruit M0 feathers. you can dive right in with your traditional libraries, sketches, and pinouts.

[westfw]

Hmm.  The "next step up" from 8bit Arduino depends on which directions you consider "up."

• Performance-wise, you have the 32bit Arduinos.  The same basics you're used to, with increased speed, more memory, and additional feature (USB Host, wireless modules, Audio libraries...)
• User-environment-wise, there are a bunch of more advanced IDEs that will support Arduino 8bit hardware (as well as other choices.)  Eclipse, XCode, Atmel Studio, Visual Studio Code, ...  (you may need additional hardware and/or modifications to use debugging, but that'd be true for other directions as well.)
• "programming"-wise, you can write more advance code even for the 8bit Arduino.  How about some non-blocking Serial code that understands more than single characters?  Fiddle with the internal libraries.  Explore some area that you haven't yet (networking?  Sensors? Power saving?)
• There are the non-arduino chips/boards and environments.  Sort of like doing 1-3 all at the same time.  Which might be fine, or it might be a bit much.

[rstofer]

The Teensy 4.0 is an interesting and FAST board.  One of the neat things is TeensyDuino which is a library replicating the functions in the Arduino library.  To a large extent, Arduino programs are easy to port.  This is a great hand up when starting with the ARM processor

https://www.pjrc.com/store/teensy40.html

[usagi]

The Teensy 4.0 is an interesting and FAST board.  One of the neat things is TeensyDuino which is a library replicating the functions in the Arduino library.  To a large extent, Arduino programs are easy to port.  This is a great hand up when starting with the ARM processor

https://www.pjrc.com/store/teensy40.html

the pogo pin pads on the bottom of teensy boards are obnoxious and I wish pjrc would stop doing that.

[maginnovision]

Instead of 4.0 I'd recommend 3.5 or 3.6 since they have the SD card slot and more easily available io. Both fast and huge upgrades.

[NorthGuy]

There's no next step. There's no steps at all. There's no ladder to climb. You need the device which is suitable for your next project. That's it.

It's the same as everywhere else. If you have a job that requires nails, you use nails. If you need screws, you use screws. And you need a little bit of experience and little bit of brains to tell these situations apart.

Other people will recommend what they have used (and liked) in the past, whether this is suitable for your project or not. These people have completely different skill sets and levels, which are very different from yours. What is good for them may be different from what is good for you.

When doing microcontroller projects, 80% of skills is the ability to select a device which will help you to do the job the best. Note that this depends on many factors including your skills and habits. The device which I would select may be totally inappropriate for you. It takes time to figure this out. You need to try things, make mistakes, and the more mistakes you make the more you learn.

So, go ahead. Make your first mistake. That will be a good start.

[SiliconWizard]

So, go ahead. Make your first mistake. That will be a good start.

Best piece of reasonable advice I've seen here.

If by "next step", the OP means "being able to work with non-Arduino-compatible MCUs", so they get a lot more choice (so they could potentially select something a lot more appriopriate for a given task), then any current and not too obscure MCU will do. Try, learn how to develop for one without the Arduino environment, and you'll have made a big step towards just having a lot more CHOICE. Just my 2 cents.