Looking for MCU with programmable PLL

[palindrom71]

Hi,
I'm looking for a solution to such a problem:

MCU gets pulses as an input, this is a reference timing signal from IR photodiode, with some small phase instability in it.
I want to use it as a timing source and generate locked in-phase sine waveform. This is now my internal reference waveform.
Now I want to output a copy of that sine through DAC and gradually sweep phase 0->360deg.

As this timing signal can be anything from 10Hz to 10kHz, I see a potential to use some kind of dedicated PLL circuit(s).
Have you done anything like that with a single MCU or am I forced to used external PLL for that?

The issue with looking for info on PLL loops in MCU context is that everything I found was about PLLs used for internal MCU clock, and this doesn't concern me at all.

Any help appreciated!

[nctnico]

Use an ARM-Cortex based MCU and implement the PLL in software. That will also help to deal with startup and handling interruptions of the signal in a better way.

[PCB.Wiz]

As this timing signal can be anything from 10Hz to 10kHz, I see a potential to use some kind of dedicated PLL circuit(s).
Have you done anything like that with a single MCU or am I forced to used external PLL for that?

Even an external PLL, will struggle with that 1000:1 dynamic range.

The issue with looking for info on PLL loops in MCU context is that everything I found was about PLLs used for internal MCU clock, and this doesn't concern me at all.

Yes, most PLLs are on the clock generate side.

I want to use it as a timing source and generate locked in-phase sine waveform. This is now my internal reference waveform.
Now I want to output a copy of that sine through DAC and gradually sweep phase 0->360deg.

A MCU does not think in sine waves, but one simple scheme here could be to create a PWM channel, that runs a SW PLL.
You set the PWM period to nominally equal the Fi, and then you sample Fi to generate a Go-right / go-left inc/dec/hold  adjustment that locks the PWM.
This action acts as a natural low pass filter and any phase jitter can only produce +/- 1 count.

With that locked, a normal PWM phase adjustment will generate a phase-relative output.

If you really need a sine output, that's more complex as you need some multiple of the Fi and a MCU with a DAC.

[palindrom71]

I wanted to approach problem as it should be done properly, but I should've know better that I'll fail miserably.
I have a couple of MCUs on hand, will browse through datasheets and try to go with direct approach if there's no easy way to have PLL for dummies.

[Kleinstein]

I have done a PLL in software for about the mentioned frequency range with an AVR, but it's a long time ago. A sine wave can than be generated in a kind of DDS generator (done it that way).
Today I would prefer a more powerfull µC, like some ARM  M0 or M3 core.
Because of the large frequency range and the low frequency an analog solution is tricky and the SW solution more practical. The search is for finding suitable SW and not HW support for that.

The µC internal PLL is usually for the main clock and made for much higher frequencies (e.g. 1 MHz and up). The frequency range is also often limited.

[NorthGuy]

I would look for an MCU which would include:

- a DAC to produce sine wave
- a DMA capable of feeding the DAC by a timed trigger
- an NCO to adjust the clock source for the DMA trigger.
- a capture module to get the time of pulses on the input pin.
- couple timers

Then you will use the CPU to analyze the timing of the pulses and adjust the NCO accordingly.

[langwadt]

I would look for an MCU which would include:

- a DAC to produce sine wave
- a DMA capable of feeding the DAC by a timed trigger
- an NCO to adjust the clock source for the DMA trigger.
- a capture module to get the time of pulses on the input pin.
- couple timers

Then you will use the CPU to analyze the timing of the pulses and adjust the NCO accordingly.

And such low frequency I'd probably skip the DMA and just in a fixed timer interrupt to do a DDS, sinewave, feed the dac
a capture timer interrupt get the input period, with that and the DDS accumulator/increment calculate a new increment 

[Kleinstein]

Using software control for the DDS can cause jitter due to variable latency in the interrupts. This may not be much, but is avoidable by DMA or a timer triggering the DAC conversion.
No need for a DMA, but some timer to trigger the DAC would be good.

A hardware NCO is not absolutely needed - that part can be done in software.

[peter-h]

I think it depends on the performance and input specifics.

I have a 32F417 board which produces two independent sinewaves (400Hz actually) which are frequency- and phase-locked to an input square-wave. The input could be anything; I use just zero crossings. The whole job is done in hardware (timer -> DAC -> DMA) via a precomputed sine table. It is also variable amplitude (it is for LVDT emulation) and that was done not by varying the DAC Vref (traditionally one uses a four quadrant multiplying DAC for this) but by recomputing the sine table so I used a fast-sine approximation rather than sin(x). The only non-hardware bit is an ISR which runs at the input zero crossings and runs in 4us.

I managed to make it all work from 30Hz to 1kHz, but that was the limit for my desired sinewave quality of 128 samples per cycle.

The frequency range is determined by how many samples per cycle you want (which itself is determined by the sort of filter you use on the output; I use a 3rd order Sallen-Key, but that inherently has a limited frequency range unless you implement software-controlled Rs or Cs) which is limited by the range of values you can load into the timer. Some CPUs have a 32 bit timer which should give a reasonable range, but 1000:1? Depends on the frequency resolution.

You may need to visit stuff like fractional-N frequency synthesis...

If you want to do a really nice job over a 1000:1 range then you will likely find an external analog PLL is the best way. Even a 4046, with CPU-selected synthesised Rs or Cs, will do a smoother job than software synthesis.

The other problem with 1000:1 is control loop stability. A PLL is a control system like any other. You have obvious issues like... it will take you several cycles to be able to compute the control loop stability parameters, which at say 10Hz input is going to be a long time.

Good luck; a fun project

[dobsonr741]

The perfect low coast part for you to implement in software: https://www.eevblog.com/forum/microcontrollers/blackpill-stm32g431cbu6-170-mhz-32k-ram-128k-rom-12-bit-adc-and-dac/msg4998397/#msg4998397

Has DAC, floating point, fixed point accelerator, good coverage in DSP algos

[peter-h]

Any decent arm32 will fo a float op in 1 cycle i.e. 7ns. Division is longer but you don't need it.

I did the input frequency measurement by timing the gap between zero crossings and then synthesising the output. That is not a "PLL" of course but it is an option open to you if you go digital. If you want to do a "classic" PLL that is something else.

Depends on what it is for.

[NorthGuy]

Has DAC, floating point, fixed point accelerator, good coverage in DSP algos

Any decent arm32 will fo a float op in 1 cycle i.e. 7ns. Division is longer but you don't need it.

I don't understand why you need floats for this.

All you need is an NCO, which is a relatively long integer (32-bit is long enough for the most applicatons). You add a fixed value to it at regular intervals (e.g. every 100 ns). When it overflows, it produces a time tick, at which point you re-load the next value from a sine table into your DAC. Depending on the addendum you use for your NCO, this will produce various frequencies as desired. That's all there is to it.

The frequency accuracy will depend on the length of the integer. The jitter will depend on the interval between increments.

You can do it manually from an interrupt, but you need a fast MCU to get 10 MHz interrupt. If your MCU has a built-in hardware for NCO, you can do it much faster and you'll get much better jitter.

Then you need to re-load your DAC. For 10 kHz sine wave with 256 points in the table, you need to do it with 2.56 MHz frequency. You may be able to do this with fast assembler-written interrupt, or you can use DMA which will do it for you without any sweat. Of course, DMA must be triggerable by NCO and must be able to loop through the table.

Also, NCO base frequency must be somewhat faster than the DAC update interrupt, like 5x or better 10x faster.

In addition DAC must be fast enough. So consider its analog characteristics as well.

So, start from picking you target values for jitter, frequency accuracy, DAC resolution, and sine table resolution. Then calculate the required NCO base frequency, max frequency of DAC reloading etc. Then search for an MCU which can do this for you.

[langwadt]

The jitter will depend on the interval between increments.

if you use the NCO to generate a square wave, setting/clearing a single pin

if you use it to generate a sinewave with a DAC and a filter it doesn't directly

[stefanstefan]

maybe take a look into the HRTIM (High Resolution Timer) of some of the STM32 MCUs:

=> AN4539 Application Note HRTIM Cookbook: https://www.st.com/content/ccc/resource/technical/document/application_note/13/d6/48/9d/11/11/4c/08/DM00121475.pdf/files/DM00121475.pdf/jcr:content/translations/en.DM00121475.pdf

It allows you to generate almost every frequency you want, you can also trigger internal DACs.

[palindrom71]

Thank you everyone!
I'm dropping my over-engineered sketch and just pulled out STM32 board out of my MCU bucket. I have H7 Nucleo board but that one would be a massive overkill.
BlackPill looks fit for the job. Actually for starters I'll drop lock-in altogether and use instrumentation amplifiers instead. I didn't think that "more analog" approach would be harder to implement.

[langwadt]

Thank you everyone!
I'm dropping my over-engineered sketch and just pulled out STM32 board out of my MCU bucket. I have H7 Nucleo board but that one would be a massive overkill.
BlackPill looks fit for the job. Actually for starters I'll drop lock-in altogether and use instrumentation amplifiers instead. I didn't think that "more analog" approach would be harder to implement.

Blackpills are usually stm32f411, it doesn't have a DAC

[palindrom71]

I took a couple of various boards. Writing code on bluepill for now until they arrive.
These have both, ADC and DAC:
https://www.aliexpress.com/item/1005004842376803.html
https://www.aliexpress.com/item/1005005303669884.html

It's kind of funny. I have about 15 dev boards on hand, and the only one that would fit the spec is Nucleo, which I'm not willing to use for that.
It's like I'm intentionally making use cases not covered by what I have.