EEVblog Electronics Community Forum

Electronics => Microcontrollers => Topic started by: Miyuki on April 16, 2021, 08:37:28 am

Title: Do you using Atmel(Microchip) SAM C,D controllers? Have they any problems?
Post by: Miyuki on April 16, 2021, 08:37:28 am
Hi, folks.
Just wanna ask about your experience with those smaller arm mcus. I am planning to migrate from avr to those. They have even 5V variant to keep working with the old 5V world.
Have they any quirks or problems when used?
Title: Re: Do you using Atmel(Microchip) SAM C,D controllers? Have they any problems?
Post by: woofy on April 16, 2021, 08:57:59 am
At the risk of stating the obvious, do make sure you read the errata sheet for the chip. Microchip are usually quite good at reporting known issues and which revision fixes them.
Title: Re: Do you using Atmel(Microchip) SAM C,D controllers? Have they any problems?
Post by: westfw on April 16, 2021, 09:23:56 am
The "clock synchronization" thing that they do between CPU and peripherals is annoying and relatively incomprehensible.
Aside from that, they seem to have "typical" annoyances.
SAMD20 lacks USB, and SAMD21 has it.  I was expecting the same thing to happen with SAMC (the 5V parts.)  But NO, SAMC21 doesn't have USB either (it has CAN, though.)


There are some annoying in peripherals between families.  The SerCOM peripherals on SAMD51 is not quite the same as the SerCOM on SAMD21 :-(


SAMD21 see extensive use in ARM Arduino-like boards from Arduino, Sparkfun, Adafruit, and others.  So I feel like they're pretty well "known devices."


You can see some thoughts based on my experiments with SAMD10 here: https://github.com/WestfW/SAMD10-experiments

Title: Re: Do you using Atmel(Microchip) SAM C,D controllers? Have they any problems?
Post by: ajb on April 16, 2021, 09:04:18 pm
The SAM D series is usually my go-to for small Cortex-M0 parts, I like the peripheral assortment they offer and they're usually pretty easy to lay out thanks to the peripheral assignments.  I particularly like the SERCOMs, since they make the parts very flexible in terms of talking to external peripherals or the outside world, and there's usually a good number of them per part.  They also help significantly with layout, since you can swap I2C/SPI/UART interfaces around at will (although there are specific pins that are dedicated to I2C, but there are usually enough of those per part that it's not a big deal). 

The GCLK system seems unnecessarily cumbersome at first, but gives more flexibility in clocking peripherals than a lot of other parts have.  Just watch out for the fact that some peripherals share GCLK lines and so must be clocked at the same frequency. 

The way the headers define peripheral register data types are a little annoying.  Using the bitfields is convenient, but a bit more verbose and may not get optimized into a single write to the register.  I prefer to use the defined masks and offsets which means a lot of remembering to tack `.reg` onto the end of the peripheral register name.

I do wish there were more CC channels per timer; most timers have only two which is annoying when you have RGB LEDs or something. 

Other than that, no major complaints versus other families.  If they fit your needs in terms of peripherals/performance I think they're pretty decent.

And as always, you should check the errata as woofy points out; this goes for any part.