First steps in ARM, Atmel/Microchip SAMC series

First steps in ARM, Atmel/Microchip SAMC series
Posted by Simon on 05 Jul, 2019 14:33
I was looking to see if MCP had come out with a bigger AVR than the megaxx09 as I need more than the 48 pins. But I then happened across a newish looking series of entry level ARM's that run on 5V, the SAM C series.

So in going from the 0-series AVR to the SAM C series is there anything that will come and bite me? MPLAB only offers MCP's free or pay fol C compiler, are there any others I should use? is GCC supported?

#1 Reply
Posted by JPortici on 05 Jul, 2019 14:56
the compiler _IS_ gcc.
You don't need to use XC32 and/or MPLABX if you prefer to use atmel studio (or IAR? XC32 V2.20 says that IAR workbench is supported for some ATSAM targets but i haven't looked into that)
The "license check" for XC16/XC32 can be circumvented anyway, there are a couple of excellent threads here which i should have saved :/

I evaluated the C21 a while ago. I liked the fact that it was 5V because it would have simplified many things but there wasn't anything beside that that stood out so i kept using a dsPIC33EV, more flexible and tons of code i had already written.
I remember the datasheet was a bit ambiguous on some things: They did the effort on saying which VDD/VSS pair powered which sections and IOs, but you can't use it at your advantage AKA power some things from 3V3 or lower so you don't have to use voltage translators. (or power off specific areas). I mean, i appreciated it but why bother including info nobody would probably ever need?

#2 Reply
Posted by Simon on 05 Jul, 2019 16:37
I did not quite get your last comments about multiple supplies. From what i can see there is one main supply and one per ADC. Really i just want the higher pin count and for something that is not too complex or expensive this looks good with 5V support.

Yes I could use other IDE's and compilers. The idea of setup wizards is always nice but invariably they spit out a load of covoluted code ond don't tell you what to do with it.

#3 Reply
Posted by ataradov on 05 Jul, 2019 17:47
Some devices support powering different power domains with different voltages. This would let you have one bank of pins powered by 3.3 V and another bank with 5.0 V, for example. C21 is not one of those devices.

The reason they are still shown is that there are limits to load currents on each pin, but also for a pin cluster. And total sum of currents for pins in the cluster may be bigger than the power for the whole cluster. So you can draw a lot of current from the pin, but not from all the pins at once.

As usual, simple bare-metal projects could be found here https://github.com/ataradov/mcu-starter-projects

I would stick with plain GCC and any IDE/text editor of your choice.

#4 Reply
Posted by cv007 on 05 Jul, 2019 17:48
You can also grab the Arm gcc download, install (Windows I assume) or extract (Linux) somewhere. Then you point mplabx to that bin folder as another build tool. But whether you use xc32 or arm gcc, you may have to fiddle around a little to make it work right. Then you have to deal with programmer/debugger, which may or may not work yet.

I have a samd10 xplained mini, and although mplabx has to show me a picture of the mini board every time I plug it in, I could not get programming to work so just went old school command line only with the arm gcc compiler, my own build script and AlexT's little programmer app.

I'll also add I had less problems with the samd and 1 led for debugging than I do a mega4809 nano with its debugger. I was mainly interested in the tiny416 for its price and c++ ability, got a 4809 nano just to see how much code would transfer to other 0/1-series (most). Somewhere along the line from tiny0/1 to mega0/1 it seems to make more sense to switch to 32bit, although a case could be made either way.

> threads here which i should have saved :/
https://github.com/cv007/XC3216

#5 Reply
Posted by Simon on 05 Jul, 2019 21:30
So why will i have to fiddle to get the compiler to work? if the compiler works for the chip and the IDE uses it what is the problem?

Yes the 8 bit stuff is looking less attractive with the new 8 bitters so similar to the low end 32 bitters it's becoming a no brainer if they are easy enough to bare metal. What i like is that for each periphery it lists all the other affected stuff, nice touch and they are as little as only twice the price of a 0-series mega.

#6 Reply
Posted by ataradov on 05 Jul, 2019 21:36
XC32 is a paid product, but that's what MPLAB wants you to use by default. But you can configure MPLAB to use any toolchain, but you have to download that separately. The offical comiler maintained by ARM is located here https://developer.arm.com/open-source/gnu-toolchain/gnu-rm .

MPLAB support for ARM is relatively new, so there may be some issues you have to works through, especially if you don't use XC32.

Atmel Studio is still supported and may be a better option. There is no harm trying them all.

#7 Reply
Posted by Simon on 05 Jul, 2019 21:40
Well i normally use AS but thought maybe I should move when I move chip. How long will AS run for? I bet they hate paying microsoft for the visual studio licence that is now "locked down" in later versions unlike the old one that basically gave you VS with AS to use as you pleased.

#8 Reply
Posted by ataradov on 05 Jul, 2019 21:41
I have no idea how long it will be supported. I don't use either and pretty happy about it.

#9 Reply
Posted by westfw on 06 Jul, 2019 05:57
Quote
to the SAM C series is there anything that will come and bite me?
No on-chip USB. Doesn't sound like it will bother you, but I was hoping that SAMC21 was a 5V drop-in replacement for the SAMD21, and I was wrong :-(
Other than that, it should be VERY similar to the SAMD chips (which are widely used in Arduino and Circuit Python boards.)Peripherals are similarly complex to the mega-0/xmega AVR peripherals, but not otherwise similar (for example, on SAM chips, SPI, I2C, and USART are all subsets of a generalized "SERCOM" peripheral, rather than separate modules.)

#10 Reply
Posted by Simon on 06 Jul, 2019 10:32
Yes the lack of USB is a bit annoying but then I have little desire to write programs for windows so the lack of it is perhaps best. I am currently working on something that needs to datalog but how to get that information out? most assume via USB download but I would either have an SD card to remove or design another device that dumps the data into another card whilst writing it as CSV data.

#11 Reply
Posted by JPortici on 06 Jul, 2019 11:20
Quote from: ataradov on 05 Jul, 2019 17:47
Some devices support powering different power domains with different voltages. This would let you have one bank of pins powered by 3.3 V and another bank with 5.0 V, for example. C21 is not one of those devices.

can you post some part numbers, please ?

#12 Reply
Posted by Simon on 06 Jul, 2019 11:28
I think this is the wider ARM family and all datasheets are in the same style/template so even though the SAMC series does not have mixed supply voltages it got the same treatment.

#13 Reply
Posted by ataradov on 06 Jul, 2019 18:07
Quote from: JPortici on 06 Jul, 2019 11:20
can you post some part numbers, please ?
Well, actually C21 is the part I was thinking about. There are no banks, but you can apply different voltage to VDDIO and VDDIN/VDDANA. This gives you some flexibility, since there are groups of ping spread between those two domains. The limitation is that VDDIO must be less than or equal to VDDIN/VDDANA.

Why the tables are there I already explained. There is no hidden meaning. According to Table 45-12. "I/O Pins Maximum Output Current", the maximum sink current per I/O pin is 20 mA, but if you look in the Table 45-1. "Absolute maximum ratings", maximum current out of a GND pin is 130 mA, which means that only 6 pins connected to the same ground pin can sink full 20 mA. And you need to know what pins connected where to do this calculation.

Also, Simon, if you are moving things, why not move to 3.3 V and have a huge variety of parts available to you?

#14 Reply
Posted by Simon on 07 Jul, 2019 11:41
Well I want a simple device. I am also looking to drive a LCD with the hitachi type controller that tend to be 5V. Various sensors are also 5V but if SAM C is a drop in replacement for SAM D presumably the architectures are much the same which starts to lead into other stuff later?

#15 Reply
Posted by JPortici on 07 Jul, 2019 12:32
Quote from: ataradov on 06 Jul, 2019 18:07
Well, actually C21 is the part I was thinking about.

really? because i remember reading i couldn't do that. I'll study the datasheet again

also you wrote before
Quote from: ataradov on 05 Jul, 2019 17:47
Some devices support powering different power domains with different voltages. This would let you have one bank of pins powered by 3.3 V and another bank with 5.0 V, for example. C21 is not one of those devices.

#16 Reply
Posted by ataradov on 07 Jul, 2019 17:57
Quote from: JPortici on 07 Jul, 2019 12:32
really? because i remember reading i couldn't do that. I'll study the datasheet again

You don't have full banks, just the separation between VDDIO and VDDIN/VDDANA domains. And also read the part about analog peripherals when using mixed supplies. There are some conflicts possible.

Quote from: JPortici on 07 Jul, 2019 12:32
also you wrote before
I did not remember which part is was (C21 or L21/L22), and I assumed you were right about C21. But is is the only part that can do anything remotely resembling power supply banks.

#17 Reply
Posted by ataradov on 07 Jul, 2019 18:01
Quote from: Simon on 07 Jul, 2019 11:41
Well I want a simple device. I am also looking to drive a LCD with the hitachi type controller that tend to be 5V. Various sensors are also 5V but if SAM C is a drop in replacement for SAM D presumably the architectures are much the same which starts to lead into other stuff later?
Moving between the MCUs is relatively easy, the hard part about the transition from 5 V to 3.3 V is finding all the peripherals.

There are plenty of 3.3 V Hitachi displays. I'm actually not sure how do you still manage to find 5 V stuff. Arduino suppliers obviously make sure that their stuff is 5 V compliant, but often it is because they use level shifters. Most of the stuff today is 3.3 V. So it makes sense to simply move to 3.3 V and adapt 5 V-only things.

Even with your example of SD-card, you would have to put some level shifters.

#18 Reply
Posted by Simon on 07 Jul, 2019 18:18
Yes true, everything else supports 3.3V i think. I will have to go through all my bits but I think it's all 3.3V compatible if i find the right display. But wat do other chips have that the SAM C does not from the perspective of a micro controller that is a gruntier than an 8 bit with more and better peripherals.

#19 Reply
Posted by ataradov on 07 Jul, 2019 18:20
Quote from: Simon on 07 Jul, 2019 18:18
But wat do other chips have that the SAM C does not from the perspective of a micro controller that is a gruntier than an 8 bit with more and better peripherals.
Not much in general. I was just making a point that if you are moving to the new architecture, you might as well move to the "native" voltage for that architecture, so you don't have to feel the pain of moving twice.

#20 Reply
Posted by Simon on 07 Jul, 2019 18:24
Well i have one incompatible "thing", a bloody green LED, 3.3-3.9V

#21 Reply
Posted by ataradov on 07 Jul, 2019 18:29
Have you tried it at 3.3 V? If it is just an indicator LED, it might work fine. Those things are super bright at their full ratings.

And if anything, it is probably easier to use voltage shifters for LEDs than everything else around. In case of an LED a simple transistor will do just fine.

#22 Reply
Posted by Simon on 07 Jul, 2019 20:09
Well SAM C seems to be more performing that D (D don't have CAN, C have 2 CAN channels), from the little i can see all others are significantly more complex.

Yes if the PSoc does all you suggest like Arduino it's nice but last time I looked they were pricy at nearly $10 for a chip with 2 CAN channels but the SAM C is less than $2 with 2 CAN channels and manageable as a bare bones code write.

#23 Reply
Posted by ataradov on 07 Jul, 2019 20:14
There is no "performance" difference. The series have different target markets, so they have different peripheral sets. C is automotive, so CAN is necessary, but USB is not. D is general purpose, so it has USB, I2S and other stuff like that. L is low power, so they have more sleep modes and more controls over how peripherals are clocked in sleep modes.

But if CAN is a requirement in your case, then C is a good way to go.