Is there anyway to view the actual speed of the generic clocks

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

Is there any way to view the actual speed of the generic clocks, I can set a speed it should be and presume it's at that speed but I often question whether it's really at that speed or not like I think it is. I've just run into various quirks and oddities that point to the generic clocks perhaps not being right or perhaps all being at the same speed but I can't find nay way to know for sure outside of what I programmed in and hoping it's all begin done correctly.

 

My chip is: SAMD51J19

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

Usually you can select a pin to output a generic clock. See the GCLK column of the pinmux table.

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

Without an oscilloscope though theirs still no way I can see the speed. Is there no way I can use a program for that?

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

Go on.   You just write a Blinky with 1 second blinks.

 

Count the blinks against your wristwatch.   Calculate the actual F_CPU.    A dead LED indicates a stopped clock.

 

In practice,  you just tell the Wizard code what clock,  which dividers,  which multipliers.   And it just works.

 

Most ARM chips have got a calibrated RC.   So if you want to measure an unmarked HF crystal,   you can run RC and XTAL clocks.    Measure one clock with the other.    i.e. it works both ways.   you can calibrate the RC versus a known HF crystal.

 

Modern AVRs can do the same thing.

Traditional AVRs can compare their unmarked crystal with the Watchdog RC clock.   (but with little accuracy)

 

In practice,    you just want to know if the unmarked crystal is 7.3728MHz or 8MHz.   A wristwatch can measure to 100ppm accuracy.    You just count enough Blinks.    You don't need a wristwatch to tell if you expected 8MHz and you got 4MHz or 16MHz.

 

David.

Last Edited: Fri. Sep 13, 2019 - 09:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to time the 1 second blinks so that they happen every second and one of the reasons I'm asking this question is because I can't get timers to work at all correctly leading me to believe it may or may not be a problem with the GCLK's. An oscilloscope would tremendously be helpful in this case but I don't have one nor can I afford to buy one. What are you talking about tell the wizard? What's a calibrated RC or HF crystal or XTAL clocks. Also I don't have a wristwatch but I can use Google.

 

There's only 1 crystal on the board and it's a 32.768 KHz crystal which in contrast with the 48 MHz Internal DFLL and 2 DPLL's was able to use 8 GCLK's of different frequencies ideally with the CPU at 120MHz but a number of other frequencies in the other clock domains.

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

You count 100 blinks and compare with your wristwatch. It is not Rocket Science.
Or you tell it to run for 3600 seconds and you only have to wait for the LED to come on in one hour.
.
You don't need sophisticated equipment for an accurate calibration.
But a simple "good enough" value is done with your wristwatch in One minute and Forty seconds.
.
David.

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

What I'm trying to say is I'm new to the world of micro-controllers and embedded programming. I understand what your saying and it's not a bad idea, but to do this on a micro-controller I need to simply fire up a simple timer and set it up so that it fires every second and then see if that every second matches up to about a real second. It's very simple, but I don't know how to work with timers and right now I'm having quite a bit of difficulty figuring them out which involves multiple days of re-reading the same manual chapter on them and scouring google for answers. The best I've gotten is to make an LED blink at a steady pace no matter the settings I use for the timer and no matter the clock I use for the timer which doesn't sound right so right now making an LED blink at a certain rate is not happening until I can figure out timers.

 

That's what I was trying to say earlier. I get what your saying and agree it's really simple and easy but before that I have to get interval blinking down first and then focus on if it's the right interval to what I programmed it to be.

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

As I wrote in your other thread....Take START out for a spin and look at the generated code then compare whats going on to the SAM5 manual.

 

One note also in regard to your other thread that sort of overlaps this one....Use Start to configure the SAM...THEN write your code suing CMSIS maybe?  Just an idea.

 

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

I can look into it, thank you

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

Is there any way to view the actual speed of the generic clocks [without any device that measures clock speed.]

Well, I suppose that that is a thorny problem...

 

There are a couple of things that might help you get "approximate" answers:

 

In the absence of configuration otherwise, you know that the CPU clock is running at 48MHz off of the internal oscillator, and I guess you can theoretically use that to measure other GCLKs, if they are significantly less than 48MHz.  You might have to configure output pins for the measured GCLKs and read the pin states, if that works...

 

You could connect up a binary counter with LEDs to the GPIO GCLK pins; after enough stages you should be able to see/measure blinking.

 

I guess if you can get one timer working with the known-running GCLK0 and a trivial timer configuration, you can divide that down to visible blinking on a pin, and then you can switch it to other GCLKs to see if they seem "reasonable", visibly.

 

You can print out the GCLK registers, and confirm that they contain the bits that you thought you wrote to them...

 

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

Dumb question coming........

Dumb Question is......"Since this sounds like a commercial application, why not tell your employer to ante up for either a used oscilloscope, or a used frequency counter so you can read a GPIO pin set up to output a GCLK?"  I mean even one that hasn't been calibrated recently will be accurate enough to put ones mind at ease.

 

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

There is no employer, it's just me. No company, no employer, no organization. Just little me playing around with an rough idea at the moment. I'm flattered though that you think I work for a computer or electronics company though.

 

Anyways I've sort of figured out my own solution which involves changing software and using different software so problem solved for me. As for the direct answer to this question, I really think the answer is an oscilloscope being the only option however like I said I've found some workarounds that more guarantee me the clock speed I want and it's something I can live with for now. But one day in a blue moon I'll buy an  oscilloscope.

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

Actually I just discovered a ridiculously easier way as I'm slowly learning more about the microprocessor.

 

FREQM

 

Just fire up the frequency meter, tell it to reference a known clock like DFLL or OSC32K and then give it the unknown clock. A sampling over 1 reference clock period should be plenty to get an accurate number. Comparing a 120MHz clock against 1MHz clock inside a period of 1 reference clock cycle yields the result of "120" which is perfect and tells me it''s running at the exact speed I want.

 

All this time the functionality has been right there and it's a ridiculously easy peripheral too. It all took only a few lines of code to get an exact reading. No external tools or breadboard setups needed however basic or easy, this beats all that.

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

NICE!!

 

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