Hi,
In various bits of PWM related code, I've seen people setting the PWM clock divisor with:
PWMCLK_DIV , setting the clock source with PWMCLK_CNTL etc.
The normal PWM registers are defined in the broadcom PDF on here, but I can't find anywhere that defines these registers?
What I particularly want to know is whether the divisor is purely integer (as most code seems to assume it is), or whether it has a fractional part / potential for extra delay of some kind, as the code on https://github.com/octachrome/piberry/b ... ster/pwm.c seems to assume. I can't map from the clock divisor in that code to the frequency he talks about.
The reason I'm asking, is that the PWM in serial mode seems like it would work just fine coupled to an LED to generate a TOSLINK SPDif output, but obviously for this to work without the signal needing some kind of dynamic re-clocking, it really needs to be as close to 48000*32 * 2 * 2 hz (6144000hz) as possible. It'd then be possible to generate a TOSLink optical SPDIF signal with just software plus an LED and resistor (like http://scanlime.org/2011/04/spdif-digit ... ontroller/ does on a microcontroller), which could potentially make quality audio way cheaper than the current quite expensive add-on boards.The SPDIF signal generation itself is pretty straightforward, and the DMA support for the PWM FIFO, in conjunction with the serial mode of the PWM chip seems like it would do the job just fine.
-
joemarshall
- Posts: 3
- Joined: Fri Dec 12, 2014 1:58 pm
-
joemarshall
- Posts: 3
- Joined: Fri Dec 12, 2014 1:58 pm
Re: PWMCLK_DIV (and TOSLink output)
Aha,
Found the general purpose timer control registers which have the same pair of names (clock control and clock divisor) and the 12 bit shift on the integer divisor, but also a fractional part in the divisor, and settings for the frequency shifting algorithm to do fractional divisors. So maybe it's the same as those?
It'll obviously have jitter in the signal, but the amount is pretty small (and it'll get reclocked in the receiver anyway).
So the plan is:
Pwm set to 2x spdif frequency, serial mode
Dma to the pwm fifo queue from a circular buffer holding the encoded spdif data.
Spdif encoding itself is pretty straightforward, and only has to work at 48k x 2 samples per second.
I can't see any obvious reason this wouldn't work, it isn't massively different from the way the analog audio is synthesized, and that doesn't take up too much processor.
Found the general purpose timer control registers which have the same pair of names (clock control and clock divisor) and the 12 bit shift on the integer divisor, but also a fractional part in the divisor, and settings for the frequency shifting algorithm to do fractional divisors. So maybe it's the same as those?
It'll obviously have jitter in the signal, but the amount is pretty small (and it'll get reclocked in the receiver anyway).
So the plan is:
Pwm set to 2x spdif frequency, serial mode
Dma to the pwm fifo queue from a circular buffer holding the encoded spdif data.
Spdif encoding itself is pretty straightforward, and only has to work at 48k x 2 samples per second.
I can't see any obvious reason this wouldn't work, it isn't massively different from the way the analog audio is synthesized, and that doesn't take up too much processor.
Re: PWMCLK_DIV (and TOSLink output)
The PWM and PCM clocks are just additional clocks in the clock register area (which includes the general clocks 0, 1, and 2.
A non-zero MASH setting is needed for the fractional divider to take effect.
You can use the 19.2 MHz OSC or the 500 MHz PLLD for a stable clock source. There are also the HDMI 216 MHz and the 1000 MHz PLLC (but PLLC frequency is said to vary with overclocking).
A non-zero MASH setting is needed for the fractional divider to take effect.
You can use the 19.2 MHz OSC or the 500 MHz PLLD for a stable clock source. There are also the HDMI 216 MHz and the 1000 MHz PLLC (but PLLC frequency is said to vary with overclocking).
-
joemarshall
- Posts: 3
- Joined: Fri Dec 12, 2014 1:58 pm
Re: PWMCLK_DIV (and TOSLink output)
Brilliant, thanks for that detail.
Is there some document I could have read to know that? Some kind of raspberry PI documentation in addition to the Broadcom chip docs, or is it just something that you need to be reading the code to work out?
Joe
Is there some document I could have read to know that? Some kind of raspberry PI documentation in addition to the Broadcom chip docs, or is it just something that you need to be reading the code to work out?
Joe
Re: PWMCLK_DIV (and TOSLink output)
This possibly duplicates what you have seen https://www.scribd.com/doc/127599939/BC ... dio-clocks
Minimal clock access http://abyz.co.uk/rpi/pigpio/examples.html#Misc_code may have some more details.
I did confirm the clock source speeds by experiment.
One thing I am no longer sure about is whether it is safe to use non-zero MASH with frequencies greater then 25 MHz.
Minimal clock access http://abyz.co.uk/rpi/pigpio/examples.html#Misc_code may have some more details.
I did confirm the clock source speeds by experiment.
One thing I am no longer sure about is whether it is safe to use non-zero MASH with frequencies greater then 25 MHz.
Re: PWMCLK_DIV (and TOSLink output)
The reason I'm asking, is that the PWM in serial mode seems like it would work just fine coupled to an LED to generate a TOSLINK SPDif output, but obviously for this to work without the signal needing some kind of dynamic re-clocking, it really needs to be as close to 48000*32 * 2 * 2 hz (6144000hz) as possible. It'd then be possible to generate a TOSLink optical SPDIF signal with just software plus an LED and resistor (like http://scanlime.org/2011/04/spdif-digit ... ontroller/ does on a microcontroller), which could potentially make quality audio way cheaper than the current quite expensive add-on boards.The SPDIF signal generation itself is pretty straightforward, and the DMA support for the PWM FIFO, in conjunction with the serial mode of the PWM chip seems like it would do the job just fine.
joe - hope you get this worked out. i've suspected this would be possible for some time, but it's well beyond my coding skills... however, i did want to pass on one other potential hardware tip i've realized since i asked about this a year ago, (http://www.raspberrypi.org/forums/viewt ... 38&t=52945), which is that many home theater receivers will accept a 1v p-p signal on the coaxial digital inputs. it does not have to be a TTL-level signal, so that seems to be less of a hurdle than it originally appeared.