cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G0B1RE Using a timer to sample a clock signal

undacmic
Associate II

Hello and thank you for taking the time to read and answer my question.

 

What I want to do:

I have SYSCLK configured at a frequency of 16 MHz (using HSI), and a PLL block clock with a frequency of 18 MHz.

I want to sample the PLL clock on the rising edge of the SYSCLK. (the application in which I want to use this is not really of interest in this post).

What is the most efficient way to do this?

Use a timer channel in input capture mode for the reference clock and read the value of the other channel where I connect the 18 MHz clock, whenever I have a rising edge?

Interrupts? (It seems like 16.000.000 interrupts a second might saturate the CPU)

Any other good way?

13 REPLIES 13

Okey, let's start from the premise I am wrong.

Right my sampling clock doesn't comply with Nyquist theorem, but I don't want to digitally reproduce the 18 MHz analogic signal.

I am merely trying to poll it's current logic value, not the frequency, nor the duty cycle or the pulse width. I don't get how Nyquist theorem affects me here.

KnarfB
Principal III

If you can live with SYSCLK/2, try SPI.

hth

KnarfB


@undacmic wrote:

Okey, let's start from the premise I am wrong.

Right my sampling clock doesn't comply with Nyquist theorem, but I don't want to digitally reproduce the 18 MHz analogic signal.

I am merely trying to poll it's current logic value, not the frequency, nor the duty cycle or the pulse width. I don't get how Nyquist theorem affects me here.


It's because you have presented an incomplete problem. You are saying you want to sample a signal but you aren't really saying what quality if the signal you are interested in. If Nyquist doesn't apply then fundamentally you're saying it doesn't matter what frequency that signal is. Its hard for me to imagine a scenario where that is true. It's highly unusual to present a signal, specify its frequency, then insist the frequency doesn't matter.

Seems like there is a language or term barrier here. And also maybe some engineering inexperience. I think you should run with what you have. When you run into issues then you can come back and with more detail try to understand what you have to deal with. Of course, sometimes you have to be lucky enough to hit the problem sooner rather than later. I appreciate that you are filtering out lots of the information that you feel isn't relevant and saving us from having to read through all of that. And maybe there are some proprietary elements. Nevertheless, its hard to do that when you don't fully understand the principles.

If instead of STM32G0B1 you take STM32G0C1, it has a built-in RNG.

JW