Alternative Clock Source for PDM Interface

RE: Alternative Clock Source for PDM Interface

haakonsh — Thu, 24 Sep 2020 13:53:35 GMT

You're free to bit-bang a PDM interface, but you won't be able to use any of the PDM Peripheral's HW blocks as it is controlled by an internal state-machine that runs independently from the CPU.

RE: Alternative Clock Source for PDM Interface

mkimhj — Wed, 23 Sep 2020 21:46:40 GMT

Hi,

I'd like to expand on this reply.

Why is writing a custom PDM driver not possible? Is it feasible at all to have an entirely new driver that outputs a PDM clock from the time synced clock? From there, anytime the clock fires, can we not sample the PDM_DATA line manually, or put it into a DMA. After 64 clock cycles pass, we then convert the 64 bits into a 16bit pcm data sample. Is the issue here that we would be starving the CPU?

RE: Alternative Clock Source for PDM Interface

haakonsh — Fri, 28 Aug 2020 13:00:26 GMT

[quote user="jjaime2"]Could you elaborate on trimming the PDMCLKCTRL register? Currently, we have both devices set to the same frequency, would we need to constantly be finely adjusting this register to achieve a nominal frequency, and does the register provide that level of granularity? I believe I read that the register only performs integer division of the HFCLK so I am worried that fine adjustments won't be possible.[/quote]

It's probably integer divisions, so the resolution won't be that great.

[quote user="jjaime2"]For clarity, we should be able to change the register while the PDM clock is active correct?[/quote]

I'll have to ask the devs.

[quote user="jjaime2"]Finally, would it be possible to write a custom PDM driver using the 16MHz timers instead?[/quote]

No, the limitation is in HW, the PDM peripheral is tied to the PCLK32M and the 16MHz TIMERs are derived from the same source as PCLK32M.

You can use higher accuracy 32MHz crystals, or you can check out our new nRF5340 that has a dedicated audio PLL clock source. See Audio oscillator and PDM — Pulse density modulation interface.

RE: Alternative Clock Source for PDM Interface

jjaime2 — Thu, 27 Aug 2020 19:35:00 GMT

Could you elaborate on trimming the PDMCLKCTRL register? Currently, we have both devices set to the same frequency, would we need to constantly be finely adjusting this register to achieve a nominal frequency, and does the register provide that level of granularity? I believe I read that the register only performs integer division of the HFCLK so I am worried that fine adjustments won't be possible.

For clarity, we should be able to change the register while the PDM clock is active correct? We cannot stop the PDM stream because our application is in telephony.

Finally, would it be possible to write a custom PDM driver using the 16MHz timers instead?

RE: Alternative Clock Source for PDM Interface

haakonsh — Thu, 27 Aug 2020 13:19:17 GMT

[quote user=""]For instance, would it be possible to use one of the 16MHz timers as opposed to whatever HFCLK is set to?[/quote]

No, the 32MHz clock is the only source available.

[quote user=""]Alternatively, would it be possible to synchronize the 32MHz peripheral clock and use that as a clock source for the PDM interface?[/quote][quote user=""]he goal is to have 2 wireless microphone streams and have them start at the same time, as well as to prevent the PDM clocks used for these streams from drifting apart.[/quote]

You can use the TIMERs to start-stop transfers on a regular basis in order to adjust for drift over time.
You can also trim the PDMCLKCTRL, this should be the first option as you can reduce drift by quite a lot during your production test.
A more advanced synchronization can involve trimming PDMCLKCTRL on-the-fly based on data from your wireless synchronization scheme.