Clock system is SAM-specific, not ARM-generic, right?

Log in or register to post comments
Go To Last Post
4 posts / 0 new
Author
Message
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
#1
Posted by JohanEkdahl: Sat. Dec 2, 2017 - 07:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On my foray into SAM D land I've come to the to the clock system county..

 

Am I correct in my assumption/conclusion that the clock system - clock sources, generic clock generators, clock multiplexers - is specific for SAM Ds rather than being something specified and designed by ARM?

 

The question is asked partly because of pure curiosity, but mainly because of "the duality of the documentation" - i.e. some by/at/from ARM and some by/at/from Atmel/MCPH.

 

In the SAM D data sheets there are often references to ARM documentation, but I saw none in the chapters and parts dealing with the clock system. And I've looked around for ARM documentation of the M0+ and surrounding ARM design elements but found nothing resembling the clock system on the SAM Ds. Hence my assumption/conclusion. Am I correct?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs
Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 3919 View posts
Location: SF Bay area
Posted by westfw: Sat. Dec 2, 2017 - 09:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correct.   For instance, SAMD0x and SAMD2x have slightly different clock systems, and the SAM3x is significantly different.

I'll have to admit that I don't understand the reasoning behind the complexity of the SAMD GCLK clock system; it seems to add quite a lot of synchronization delay without being particularly useful :-(  Most of the peripherals have separate prescalers or whatever, anyway...

 

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 15843 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Sat. Dec 2, 2017 - 11:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, as westfw says - that is correct.

 

The concept of the Generic Clocks seemed to come from AVR32, IIRC.

 

I certainly found that it gave a lot more flexibility than a certain STM32 on a recent project.

 

The evil twin of flexibility is, of course, complexity.

 

frown

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 oscillator: https://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...
Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sat. Dec 2, 2017 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you both!

westfw wrote:
it seems to add quite a lot of synchronization

Ah yes, the synchronization.. Let me semi-highjack my own thread and continue on that specific subject:

 

I must admit that after two "browse-like" reads on the subject I am none the wiser, and am trying to figure out if it is something I need to bother with initially.

 

At some places I read that when certain operations (access to specific peripheral registers) are done then synchronization will happen and "the bus will block" (or some such). Is this something that I will actively need to handle, or is this more of an information that execution speed will be affected?

 

As you might know I am using Alex Taradovs mcu-starter-projects as my platform (rather than ASF/Start) and he has a commit in his Git repo where the comment is that he has "Removed pointless syncs". Reading the discussion (scroll down to the bottom of the commit page) the jury still seems to be out on whether there can be malign situations if you do not handle (wait for) the sync to finish.

 

So:

  1. Can anyone try to explain to this Pooh brain blush what the situation is, why these syncs are needed at all etc?
  2. Can they be safely "ignored" in the meaning that they will just result in some "bus latency", or are there situations where they must be handled or the effects will be catastrophic?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top