Do you using Atmel(Microchip) SAM C,D controllers? Have they any problems?

[Miyuki]

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?

[woofy]

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.

[westfw]

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

[ajb]

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.