AVR To SAM C/D Series Migration

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm interested in any opinions from people who've migrated from, or who use both in parallel, the 8-bit AVR series to the 32-bit SAM C/D Series.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's just another microcontroller - no "big deal"; nothing fundamentally new or novel, really.

 

Just everything taken up an order of magnitude: more bits, more speed, more memory, more options, more complicated.

 

The big headache is is getting a handle on all the options for the peripherals - which is not just the peripheral itself, but how it gets clocked, enabled, routed to IO pins, woken up, put to sleep, etc, etc, etc, ...

 

This is why they have things like ASF - although whether getting to grips with things like ASF is any easier than getting to grips with the peripherals is a matter for long debate ...

 

frown

 

The debugger is more than just your friend - it is a necessity !

 

EDIT

 

I would say that applies to ARM-based chips generally - not just SAM

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Mar 17, 2020 - 04:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Just everything taken up an order of magnitude: more bits, more speed, more memory, more options, more complicated.

 

And depending on the IDE more BLOATED (ie. START)

 

It also seems that it takes more operations to do teh same thing you can do in an AVR in one statement

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
more BLOATED (ie. START)

The trouble with these things is they they tend to (try to) be entirely general - which, naturally, makes them "bloated" for a specific application.

 

What I tend to do is start with START (or whatever) just to get something that works.

Then, if necessary/appropriate, study it to pull out the bits which really matter in my application.

 

I find that's often easier to do by stepping in the debugger than trying to wade through reams of source. 

 

It also seems that it takes more operations to do teh same thing you can do in an AVR in one statement

Yes, that's always the way - the more options there are, the more work it is to set it up  & manage it.

 

I generally find it's mostly the setup - once it's actually operating, things aren't so bad.

 

YMMV, of course!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
It also seems that it takes more operations to do teh same thing you can do in an AVR in one statement
Do you mean "statement" or "opcode" ? The AVR opcode set are actually pretty powerful but things like the branch and link (rather than CALL/RET) maybe take a bit of getting used to.

 

If you meant "Statement" then isn't that really more about the complexity of the peripherals but in that sense it's not really that much different than a transition from traditional tiny/mega to Xmega/AVR0+1 etc. In that you find that setting up a timer or a UARt or whatever that maybe was 3 SFR writes in the simpler chips is now 10 SFR writes or whatever because these newer things give more options for every aspect of configuring stuff. Actually if you get to know the peripherals in X/0/1 then you may start to see a lot of familarity in SAM. I have a feeling that X and SAM were both products of Atmel's French design team (no doubt someone from Microchip can confirm?) and they reused a lot of the same ideas if not even the same VHDL between one and the next.

 

Odd things you will see in ARM code if you start to study it at hte opcode level are things like constants for index operations tend to be stored "inline" in the code rather than being part of the opcodes themselves. Also you often see curious +1s on branch/jmp destinations - ARM is 32 bit so code is 4 byte aligned but you may see a 4001 target when you think it should be 4000. This is normal as that deliberate "off by one" means "arrive there in 16 bit thumb mode not 32 bit ARM mode". Oh and another thing that wil appear "different" is the whole interrupt handling. I forget the exact details but ARMs all have 8 (is it?) vectors so it's not like AVR8 with one vector per peripheral. Oh and look our for code causing "hard faults". This is where you try to make a 32 bit aligned fetch from 2000343 when to be 32 it aligned it was supposed to be 2000344. It can't do wide fetches "across" cell boundaries and if you do this causes a "hard fault" which is one of the most common things you hit when working with ARM. (hard fault itself is one of those 8 fixed vectors).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
you find that setting up a timer or a UARt or whatever that maybe was 3 SFR writes in the simpler chips is now 10 SFR writes or whatever because these newer things give more options for every aspect

Yes, that's the kind of thing I was getting at - although it often seems more like 100 than just 10 !

 

surprise 

 

I got the impression that there was quite a lot of IP "borrowed" from AVR32; eg, the whol GCLK thing ...

 

a "hard fault" which is one of the most common things you hit when working with ARM

Indeed.

 

eg, if you try to use a peripheral before you've (properly) enabled it and its clocks - you'll end up in the dreaded Hard Fault Handler ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

The debugger is more than just your friend - it is a necessity !

 

Time to dust them off then. Luckily I have an Atmel ICE and a J-Link Plus sitting here.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think all of the  SAM C/D  XPlained boards come with a debugger on board ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nEDBG for SAM D Curiosity Nano

Development Tools - Curiosity Nano Boards (bottom)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most people are going to have an intermediate step between the AVR and the Cortex M0-based Microchip SAM C.  This would be the "blue pill" module board that has an Arduino interface and Cortex M0-based  low-cost high-volume general purpose CPU (STM32F103).

There are several packages on eBay that are 2-3 blue pill boards along with an ST-LINK for about 12-15 $/pounds/euros. https://www.ebay.com/itm/STM32F1...

  I suggest getting one along with any Microchip development/debug hardware that you might buy specific to the SAM C.   You can load and run downloaded test and demo programs on the blue pill board if you hit roadblocks in the SAM C.   You might want to develop your application on both systems at the same time until you need the peripherals specific to the SAM C.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I don't see any advantage in that.

 

Much better, IMO, to get a genuine manufacturer's board like the Curiosity Nano mention above. It is only ~ a tenner.

 

Then you know that it is supported & documented by the manufacturer, and the manufacturer's own test & demo examples can be downloaded & run on it.

 

EDIT: And, as the OP specifically mentions moving from AVR, you can stay with the familiar Atmel Studio environment

 

BTW, the  STM32F103 is a Cortex-M3 - not an M0:

 

https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html

 

I think it was ST's very first Cortex-M ?

 

EDIT 2

 

Not that I have anything against STM32, of course:

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Mar 17, 2020 - 06:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller