ATSAM vs. STM32 - are they worth the low unit price? - Page 1
Forum section: electronics / general

author: TinkeringSteve
author_rank: Frequent Contributor
timestamp: March 11, 2020, 09:45:25 am
content: Howdy.I have been developing with several STM32 lines of ARM Cortex M0,3,4 MCUs, and am familiar with their tool chain / IDE offerings which has improved in recent years.The place I'm at now needs some Cortex M0 or M3 with a bit more flash (for that line), e.g. 256KB.I suggested a STM32. But the HW designer saw that you get comparable ATSAM, formerly Atmel, now Microchip, for ~ half the price.We are talking not super high volume products, rahter, industrial, some thousand a year or so. (I know ST is cheap at super high volume)(I'm not too fond of Microchip's PIC IDE MPLAB X, and the "pay if you want optimization" compilers, but I guess this is still totally separate from their aquired Atmel stuff?)So, those of you who know both - how does developing firmware on the ATSAM compare to using an STM32 with CubeMX and their Atollic TrueStudio based IDE?And of course, if there are any hardware (quality) related issues compared to ST, I'd also like to know.Is the lower price worth it, or is there a reason why the ATSAMs apparently aren't going over the counter like sliced bread? (I was told by an EE who works at a bigger place that he's never heard of anyone using ATSAM when ARM Cortex M stuff was called for.)

author: Siwastaja
author_rank: Super Contributor
timestamp: March 11, 2020, 12:19:18 pm
content: If you are the software developer for the project, and you feel comfortable with the STM32 part, and there are no other compelling technical reasons to go for the ATSAM part than cost, definitely say no.Getting out of your comfort zone is a good learning event, but itwillcost at least a hundred hours, easily. Worst case, it can be 1000 hours, you never know. The risk is huge. Multiply this with your hourly rate, and add the sales losses (or losing the competitive edge) from the lost calendar time (at least a week, but can be a few months), then you can start comparing the actual price of the choice. I'm sure it won't break even at qty=1000.OTOH, if the purpose is to make you learn so you can take advantage of both STM32 and ATSAM product ranges in the future, then it can be a good idea. But the bottom line is, this choice will very likely make this particular project costmore, not less.

author: snarkysparky
author_rank: Frequent Contributor
timestamp: March 11, 2020, 12:23:10 pm
content: I like the SAM parts because you can get a good free IDE compiler with no limits. Atmel Studio.

author: brucehoult
author_rank: Super Contributor
timestamp: March 11, 2020, 01:20:01 pm
content: Quote from: Siwastaja on March 11, 2020, 12:19:18 pmWhile that could happen it's unlikely to be *that* bad.I'd say grab a cheap dev board and try doing something simple using the peripherals you'll actually need and set a firm upper limit on how much time you spend on it. Maybe do it in your own time in a weekend.

author: kamtar
author_rank: Regular Contributor
timestamp: March 11, 2020, 01:33:11 pm
content: I dislike Atmel studio and I always use eclipse with my atsam projects but ASF framework is miles away from that buggy mess that ST HAL is, so I woudnt be that much afraid of it.

author: ajb
author_rank: Super Contributor
timestamp: March 11, 2020, 03:08:54 pm
content: It depends a lot on what you're looking to do, what sort of peripherals you need, etc, but in the absence of that information here are some very scattershot thoughts:I basically only use either ATSAM or STM32, in fact I just finished revising a SAM based design and have now started work on a new STM32 design. I don't use ASF or HAL or Cube so can't comment on their relative merits. I *DO* use Atmel Studio and Atollic because I like a real IDE and I've never bothered to setup a consistent cross platform environment. I like both well enough although in different ways, even if switching between them makes me trip over small differences (different shortcuts for debugging, different column select modes, silly things like that). Both are REAL, fully featured IDEs based on GCC toolchain with all of the niceties you'd expect, and both can be skinned fully dark.On the SAM side I mostly use the SAM D series because I really like the peripherals. Having one peripheral (SERCOM) that can do UART, USART, SPI, or I2C, and having a BUNCH of them is brilliant and I wish other manufacturers took that approach. Those and the Generic Clock system (especially if you have lots of timers in use) give you a much more flexible platform in terms of how you allocate and use peripherals. I haven't looked much at the other SAM series, I think the SAM L is very similar. Contrast that with STM32 parts which are awful to deal with on peripheral-dense applications because of how ridiculous their pin assignments are, and their clock trees tend to be bizarrely complicated with weird limitations. I like the SAMD series enough that it's my default choice for anything in the M0 space unless I need specific peripherals it doesn't have. I think the ATSAM documentation is sliiiiightly better than STM32, but no on really rights GOOD documentation these days.In terms of hardware quality, I can say that I was bit by an extremely nasty undocumented defect in STM32F7, but as awful as that was I tend to consider it an outlier

author: mark03
author_rank: Frequent Contributor
timestamp: March 11, 2020, 03:16:09 pm
content: Quote from: ajb on March 11, 2020, 03:08:54 pmYou don't say...(sorry, couldn't resist)

author: ajb
author_rank: Super Contributor
timestamp: March 11, 2020, 03:39:12 pm
content: Quote from: mark03 on March 11, 2020, 03:16:09 pmI'm glad you appreciated my joke that was definitely deliberate and not at all the horrifyingly embarrassing result of trying to write coherently before the coffee kicked in.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 11, 2020, 03:50:27 pm
content: People want to pay you to figure out how a new MCU works. I don't see any reason to refuse. It might help you in the future as well.

author: TinkeringSteve
author_rank: Frequent Contributor
timestamp: March 11, 2020, 04:43:55 pm
content: Quote from: kamtar on March 11, 2020, 01:33:11 pmYeah, someone designing that "HAL" confused abstraction with "onion". A lot of wraps around stuff that are not necessary or all that well thought out.But you can now basically select to generate the "LL" variant for everything instead of HAL, just need to select it for every single component you add, as HAL is the default... LL is much thinner a layer.Since this is available for all the STM32 lines (I'M aware of) now, and the unified stuff a bit, it helps, to some degree, to not duplicate work each time you use a different MCU in the stm32 realm.I outed myself as the software guy here, but rest assured I'm not "afraid" of registers.But I hate & think it dumb to repeat gruntwork that's been done a million times over in pretty much the exact same way.So I do welcome libraries for that stuff.If and when a certain portion of peripheral-fiddling code needs to be faster than the library implementation offers, one can still optimize for such rare cases - everything else looks like premature optimization to me. (assuming the libraries are at least not bug ridden - the parts I used of ST were not that, even though not exactly beautifully implemented, or always feature complete)So for now it's going to be a M0, but not necessarily on the future. For M4, the CubeMX is definitely very helpful in setting up all the clocks correctly.And I don't mind the visual pin configurator etc.While I appreciate this "broaden your horizon" sentiment, familiarizing myself with another vendor "just because" does not currently make a lot of sense.MCU firmware is only the smaller part of what I do a my current place.Btw, I have worked with Kinetis and NXP cortexes before, if ever so briefly. But that must be 3 years in the past, things can change a lot in that timeMy gut feeling about this apparently not top priority Atmel branch of Microchip (apparently they had laid off a lot of staff from the Atmel team after acquisition) about longevity isn't too great, either. But that's a bit of crystal ball reading I guess.QuoteOne preliminary early specimen of a new STM chip 8 years ago or so we got at a place I worked, had a malfunctioning cache.But that's about the only HW error from their stuff that caught us before it was a known part in the errata sheet.QuoteIt's not in some corporation, it's a small team, and everyone contributes to try to not make this a failure. Nice luxury excursions are not such a good idea

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: March 11, 2020, 07:48:32 pm
content: Quote from: TinkeringSteve on March 11, 2020, 09:45:25 amI would be surprised if there was one literally half the price, for the same features, and not an old rev. Are we sure HW designer is right?Otherwise, price is usually a terrible way to select an MCU, especially if we are talking low end. Every project I have worked on, and I mean 100%, time to market is the most important factor. OTOH, I have never worked on a project where it turned out the BOM is $2 too expensive.If you are familiar with a chip ecosystem, that should be the guide. It's really not a question of which vendor has the best features, the question is with which vendor's chip are you familiar with the gotchas? They all have them.

author: thm_w
author_rank: Super Contributor
timestamp: March 11, 2020, 10:50:11 pm
content: Quote from: donotdespisethesnake on March 11, 2020, 07:48:32 pmWho knows what chip OP is using though, it could be a specialty part which justifies a high cost.OP: which STM32 are you talking about?

author: westfw
author_rank: Super Contributor
timestamp: March 12, 2020, 06:53:45 am
content: The Atmel SAM chips have a confusing thing going on WRT clock synchronization between the CPU and peripherals that you should watch out for. I don't know if the STM32s have the same thing. (I mean, some clock synchronization is necessary, but the Atmel chip seem to take up to 6x the slower clock, which is Fing forever if you're talking RTC or WDT running at 1kHz...)

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: March 12, 2020, 03:21:29 pm
content: The ST range is so big it would seem to overlap just about every other offering, but I guess there are security, touch peripherals that are less common.It would be nice to know the actual part numbers in consideration, but I guess the OP will not provide that.The last time I got shot in the foot by a HW designer, he chose a 32KB part which was way too small - they only reason he chose that size is because he had an ambition to write SW and was using a particular limited free trial software and didn't want spend any moneyI had to beg to get a 64KB part specified, even though it was $1.50 more on a BOM of $100... There was an insinuation that I must be a lousy programmer, even though the HW designer failed to produce working software and I had to take over! I basically had to rewrite 95% of what he had done, then add all the missing features including the bootloader.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 12, 2020, 04:12:01 pm
content: Quote from: TinkeringSteve on March 11, 2020, 09:45:25 amAsk the "HW designer" how they compared them. Figure out their definition of "comparable". You may be in for a surprise.

author: Scrts
author_rank: Frequent Contributor
timestamp: March 13, 2020, 07:07:04 pm
content: Quote from: donotdespisethesnake on March 11, 2020, 07:48:32 pmTry some high-volume markets where the BOM is $20. In that case $2 is 10% of the BOM... I've seen some companies where they squeeze every penny of the component, e.g. buy without certain HW peripherals and push software engineers to implement them in software...

author: Harjit
author_rank: Regular Contributor
timestamp: March 14, 2020, 01:08:24 am
content: Quote from: westfw on March 12, 2020, 06:53:45 amThis varies. Some STM32 parts have busses that run at CPU core clock, some at a ratio of CPU core clock. The STM32G4, for example, runs all busses at the CPU core clock.