I've been designing boards with STM32 chips for the last couple of years and my curiosity keeps saying that I should try something in the Atmel SAM line of chips.

Most of the time, when someone asks about these chips the response seems to be "go with what you already know" or "neither one is better, depends on what you want to do." I'm not looking for which chip is better, but looking for people's specific experience working with the SAM line. Bonus points for comparisons to STM32 (or other chips).

Questions that stand out to me

  1. Compatibility between chips? - As I've grown with STM32 it's been really nice that when I switch between chips (STM32L0, STM32F4, etc), the pinout and code need very few modifications.
  2. Toolchain - I'm comfortable with C/C++. The dev environment & debugging setup took some time with STM32 since I did not want to use Eclipse. I prefer simple/portable makefiles and such, and I work on a Mac.
  3. SDK - I've gotten used to CubeMX/HAL -- it's not great when things break, but at least I can step through the code to figure out what it's doing. How's the library with SAM? Is the code portable between chips in the SAM line?
  4. PCB Space - The STM32 chip needs a good deal of PCB space (with 0603 parts) as the default configuration requires ~8 decoupling caps + crystal + optional bead. From what I can tell SAM chips need fewer external components to get going.
  5. ??? - What else should I be asking about? What are your favorite & least favorite parts of these chips?

My background

I'm a software engineer by trade and work with electronics as a hobby. This means that often when I'm exploring a new chip, I'm not entirely sure what questions I should be asking or what to look for in the datasheet -- besides the rough features. I usually figure these things out as I go, which can be time-consuming. But I'm getting better.

My uses

Most of my work involves battery-powered wearable electronics with LEDs. The basic sensor input is good and ample PWM outputs (I usually populate 4 dedicated PWM outs per board). These days a USB bootloader is a must over a programming cable. I'm building these in small quantities of 10-20 per batch.


I've noticed that Adafruit seems to really like ATSAMD21G18 for many of their boards. Any guesses as to why?

  • \$\begingroup\$ I'm no expert in samd, but... They have nice peripherals, timers etc, analog has higher resolution ADCs with gain stages, and the data sheets are far more friendly than the st ones. \$\endgroup\$ Commented Oct 22, 2020 at 22:20
  • \$\begingroup\$ The st chips don't really need that many ancillary parts. Most of them (f4 upwards excluded which need an extra cap for the core voltage) can be run with just one decoupling capacitor and the internal oscillator. I've done it many times. They seen to pepper them with decoupling capacitors even though in reality the chips are only 7mm across (32 or 48 pin lqfp) so the length from leg to cap is tiny once surface mounted. \$\endgroup\$ Commented Oct 22, 2020 at 22:27
  • 1
    \$\begingroup\$ That said, I always end up back at st after deviations to atmel, infineon xmc (amazing timers and the best eclipse environment) ESP 32 and a failed attempt at nxp. Check out jaycarlson.net/microcontrollers for a really good write up on all the options. \$\endgroup\$ Commented Oct 22, 2020 at 22:32
  • \$\begingroup\$ ATSAMD21G18 is used by Arduino, so Adafruit chose that to leverage the Arduino core, libraries, community and so on. AFAIK they have moved on to SAMD51 and are focusing a bit more on MicroPython and so on now. (It seems there are SAMD51 options pin compatible with SAMD21) \$\endgroup\$
    – Wesley Lee
    Commented Oct 22, 2020 at 22:50
  • \$\begingroup\$ Questions here must be specific... \$\endgroup\$ Commented Oct 23, 2020 at 1:24

1 Answer 1


I keep asking myself the same question, except from the other direction. I keep hoping I will find someone who made identical designs using the two for a comparison. There is only so much that can be gleaned from a datasheet. It’s hard to fully know what your current draw will be as it is so dependent on the usage or exactly how the DMA will handle certain events. Sometimes it will look good from the datasheet, but then after the boards come in you find out that you have to use an interrupt to do something that appeared to be supported in hardware or cover up for some lost character on the DMA when disabling it. Guess someday that will be me that does a replicated design with the two MCUs.

So I decided to provide some aspects from the Atmel (Microchip) side. Unfortunately, I have only used the higher end STM32H chips for GUI designs. So take this for what it is worth. And of course, this has some opinion basis as you can't enter a discussion like this without it mingling in.

Compatibility between chips – If you are using Microchip’s SDK, then yes, they are fairly compatible. Now that said, given how they structure their projects you basically would need to start with a new project and add your code back in. Pinouts are somewhat similar across the chips, but there always seems to be a pin or two that needs special consideration. I would say overall the STM32 have SAM parts beat in this aspect, but not by much.

Toolchain - If you are using makefiles, then it’s pretty much a wash. SAM chips use pretty much the same GCC compilers, only difference is the chip specific libraries.

For those using an IDE, I would say ST has the hand up since they have acquired Atollic. SAM parts have two options. Atmel Studio (Visual Studio based) or Microchip MPLAB X (NetBeans based).

Microchip’s stance is that Atmel Studio is still supported and will be for the foreseeable future, but I highly doubt they will provide any updates other than adding support for a few chips. It has some weird issues with projects and internal threads that seem to get stuck which drives your CPU usage through the roof until it is closed.

MPLAB X has gotten much better in the recent years (they actually put effort into updating it) and I am just as happy to use it as anything else (didn’t start that way), but Atollic TrueSTUDIO seems more refined. I think my biggest complaint for MPLAB X is now long it takes to startup a debug session and sometimes it is hard to get the debugger to show variables in the correct format (typically when dealing with pointers).

SDK – This is the area that keeps me asking if STM32 is better. If I was sure their SDK solved all my issues, I would have started using more STM parts years ago. But searching for issues on the STM SDK results in about the same number of complaints as about any other vendor’s SDK, excluding Harmony. In the end the best experience I have has always been a result of writing my own drivers, regardless of the chip vendor, but that takes time that I don’t have anymore.

Back on the topic, I can’t count how many hours I have spent debugging Microchip’s SDK code. SAM chips currently have 4 (yes 4!) different options, all half-baked as per typical in the industry. Atmel Studio ASF3, Atmel Start (ASF4), Microchip Harmony, and Plib.

ASF3 – It works, but I wouldn’t say it is great. Newer chips are not supported as they are phasing this out for Atmel Start (even if the FAE says otherwise). Libraries are not fully tested and when you submit corrections they never get implemented.

Atmel Start – Has better (maybe newer would be a better word) support than ASF3. Its web based which makes it easy for them to update, but then they can update it on a whim. It allows easy configuration of clocks, which helps as the SAM clocking area has many options, but the tool misses things like automatically adjusting the flash wait states based on clock speed entered in the tool. As with CubeMX, you can step into the functions during debug, but the abstraction is a little crazy. I often find I have to step into 4-5 functions to see them set a single register. I can’t say they thoroughly test the SDK either as I have found bugs that could have been caught by simply testing every function provided. One nice thing it it produces a project with all the needed files included which makes for easy archival of the complete code base. I tend not to love the abstraction in the chip configuration that Atmel Start produces, so I typically wipe some of that out after getting started.

Harmony – If a plane crashed into a train, this would be the result. I shouldn’t be so mean, and it is getting better. It works, but it’s defiantly YMMV. If you are wanting some of the more advanced items like TCP/IP, encryption, or GUIs on a SAM/PIC part, this is the way to go. In the long run I expect the ASF3/4 to be replaced by this, but currently there would be too many riots if they cut the Atmel tools now.

Plib – Is a no frills driver library. I haven’t gotten the chance to use it, but it’s on my list to try out. Overall I think it would solve several of the things I dislike about ASF4. Previously it has been somewhat hidden, the FAE talks about it but it is hard to find info on it. Supposedly they are adding support into MPLAB X which should make it easy to drop into a project.

PCB Space – This is pretty similar between the two. SAM devices have all the same bypass caps + crystal + they want a handful of ferrite beads. I have done enough designs that I am starting to ignore some of the vendor’s recommendations, especially the ones about ferrite beads. Ferrite beads in your power path can wreak havoc on emissions in certain situations. If you have access to some of the PDN tools, defiantly simulate those before use. Given most people don’t have those due to cost, we end up doing the typical datasheet copy. Another one I see in datasheets that can bite you is using two different values of bypass caps right next to each other. I fully believe that the dev boards for these parts are done by interns/recent grads who don’t know better and they do not read the research and white papers that talk about some of the common power issues in MCU designs. Typically a good 4 layer stack up and a good power path + 1 bypass per pin is sufficient (excluding the high power processors of course). I typically implement the core bypass as indicated though.

What else

  1. Always read the errata. Twice. Once before use and once after the circuit is designed but before boards are produced. And make sure to get the latest copy both times. Also can't count the times erratas have changed after making a board to find out something I counted on doesn't work.
  2. Look at the software libraries to see if they provide the feature you are looking for. I am finding that those items are becoming more defining than the chips themselves (as far as saving you the hassle of developing it yourself).
  3. As for datasheets the two are fairly equal. The biggest challenge is to figure out how they structure the documents and where to look. SAM typically are all in one, so it makes it easier to use the search tool. But some intricate things are only found in peripheral specific documents that cover a broad base of chips. In the end, STM and SAM chips have most of the info out there, just have to find where to look.
  4. Bootloaders - The older SAM parts had built in ROM bootloaders, but those are missing from the newer parts. Atmel does provide bootloader projects to start from, but you would still need a programmer to get the loader on. If this is important to you (and it sounds like it is), STM is the way to go.

I have a new series of designs coming up and have spent countless hours reading datasheets between the two for low power to mid rage parts and would love to settle on the one “best” chip family. So far I haven’t found it.

Here is my generalization so far based on what I have researched and experienced:

If you need more than a few serial units – SAMx5x. I would say generally speaking the SAM parts typically have equal or more serial units than the STM parts. I should mention that the NXP i.MX RT chips have lots of those too, but it’s not really what I would classify as a midrange chip.

If you want the lowest power with a lower clock rate – SAML10/11.

If you want the lowest power with a high clock rate – STM32U5. Potentially this might also be pretty low power if clocked slowly too, but power usage isn’t linear as clock rates go down and I haven’t ran the numbers.

If you want a GUI – STM32F/H (pick one of the chips with the LCD controller). On top of great hardware acceleration, their GUI development tools are sweet (and kick the pants off of anything Microchip offers).

If you want a crystal less design but need something accurate enough to use for a UART over the temp range – SAMD21. I believe this is another reason it has become so popular as it provides a low part count design. For every other chip, unless its room temp only, use a crystal. This even applies to close relatives of the SAMD21. You would think that if they could do it in the D21, it would also be in the others, but no… The SAMD21 also does a good job with crystal less USB. I believe there are a couple of STM parts that can do USB without a crystal, but you have to check the datasheet to be sure.

As comparison to other chips:

I haven’t found a compelling reason to use a TI MSP chip in years. They make decent stuff, but it tends to cost more. Nothing really compelling over the STM or SAM parts. Unless you need something special like FRAM.

If you want the best Bluetooth/BLE, Nordic Semiconductor hands down (which soon could change as the market is heating up in that area).

ESP32 for Wi-Fi. Mostly because of cost and they provide certified modules for about everything. They have their issues and there is nothing like reading one of their datasheets. There newer stuff is becoming better on power usage. I often find that I use them as a co-processor for Wi-Fi only though.

I don’t know if someone could talk me into using another PIC32 chip, they have fundamental issues that they seem to never fix on the newer parts.

As for Adafruit, like others have mentioned, it stems mostly from Arduino + low part count as referenced above. Arduino started by providing a bootloader and a simple GUI with a GCC compiler for the Atmel AVR chips. Given all of the background libraries and code for those, it’s a natural progression to stick with Atmel as they move up. ARM is just the core, each vendor implements their own peripherals. While there are some changes to the peripherals from AVR to SAM chips, what does change uses similar concepts. All of this makes it easier to roll a new design out.

Conclusion So in the end, I keep looking for that compelling reason to ditch SAM for STM, but so far I haven’t found it. Excluding switching for the learning experience, small differences get washed away when you compare it to the time taken to switch parts/tools. I say this, fully knowing I will search the topic again in another 6 months wondering if there is now a compelling reason… Pardon the book.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.