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