External clock generation at non-multiple of system clock

[Paul UHS]

Posted on April 08, 2013 at 09:24

Hi All,

    I am trying to produce a 256 kHz frequency clock for use with audio codecs. I am trying to produce this 256kHz freq from the 120MHz system clock on the STM32F207 series. I would like to use the timers to produce this 256kHz clock, however 256kHz does not evenly divide into 120MHz. (120Mhz/256kHz = 468.75)      Does anyone know of a way to produce a non-multiple of the system clock by using a combination of timers, and cascading timers. I have found one way to produce 192MHz from the I2S PLL, and then output on MCO 6.4MHz, which can then be divided down to 256KHz, but this requires two pins, 1 for the MCO pin and 1 for external clock input. I would prefer to be able to just use internal timers and get back two micro controller pins. Any help find a solution to this would be great. #fitter #external-clock #advanced-timers #clocks #magic-crystals #doughnuts

[emalund]

Posted on April 08, 2013 at 19:05

this reminds me of all the posts (elsewhere) in the past ''I am using a nice 12 MHZ crystal with my 8051, why can I not generate baudrate xxx''

instead of mickey mousing around the problem change the crystal.  if your 120MHZ clock end up being 119.808 MHZ or something like that that will not affect the rest of the system Erik PS I'll bet you dollars to doughnuts that you can find some PLL combination with a crystal DigiKey has in stock that will achieve this

[Tesla DeLorean]

Posted on April 08, 2013 at 19:29

PS I'll bet you dollars to doughnuts that you can find some PLL combination with a crystal DigiKey has in stock that will achieve this

5.9904 MHz?

3.9936
4.9920
5.9904 <<
6.9888
7.9872
8.9856
9.9840
9824
9808
9792
9776
9760
9744
9728
9712
9696
9680
9664
9648
9632
9616
9600
9584
9568

[Tesla DeLorean]

Posted on April 08, 2013 at 22:54

Doughnuts all round...

119808000 256 KHz * 468
4.096000 M= 4 N=234 P=2
4.915200 M= 4 N=195 P=2
5.120000 M= 5 N=234 P=2
5.529600 M= 3 N=130 P=2
5.990400 M= 3 N=120 P=2
5.990400 M= 4 N=160 P=2
5.990400 M= 5 N=200 P=2
6.144000 M= 4 N=156 P=2
6.144000 M= 5 N=195 P=2
6.144000 M= 6 N=234 P=2
7.372800 M= 4 N=130 P=2
7.372800 M= 6 N=195 P=2
7.680000 M= 5 N=156 P=2
8.192000 M= 8 N=234 P=2
9.216000 M= 5 N=130 P=2
9.216000 M= 6 N=156 P=2
9.216000 M= 7 N=182 P=2
9.216000 M= 8 N=208 P=2
9.830400 M= 8 N=195 P=2
059200 M= 6 N=130 P=2
288000 M= 8 N=156 P=2

[Paul UHS]

Posted on April 09, 2013 at 00:12

Thanks for all the great responses. 
 DMA:
 I am keen to flesh out what you mean by the DMA and resulting jitter. 
 I am assuming it would look like this
 DMA Array for TIMx->ARR of [468, 469, 469,469] with CC1 of 468/2=234, then get TIMx to produce a PWM signal based on CC1 for the ~50% duty cycle.
 Different BOM Crystal:
 The problem of using another crystal is I still need to use USB. Which means I am stuck with a multiple of 8MHz.
 I was originally trying to get from a single 8MHz crystal (or any other cheap value): USB (48Mhz), Ethernet (25MHz or 50MHz) and Audio (256KHz). In the end this was the best I could come up with.
 96MHz System Clock Option:
 I did figure out I could run at 96MHz instead of 120MHz (but had forgot this until you guys reminded me), but this is throwing away 20% of my performance. Performance would be good to keep as I will be doing DSP with the incoming audio.
 STM32F4:
 The STM32F4 with the 160MHz would be perfect! If only I was running an F4 :( (and it didn't cost ~$0.5 more, but I really did think it use to be more than $0.50) 

[emalund]

Posted on April 09, 2013 at 01:08

you will ju8st have to decide which of the two that will have to live with a one tenth of one percent deviation, I doubt either will complain

Erik

[waclawek.jan]

Posted on April 09, 2013 at 08:22

I still don't quite get why don't you use I2S together with its dedicated PLL to generate the required clock.

In fact, it's quite unusual to have an audio codec not connected/connectable through I2S. JW

[Paul UHS]

Posted on April 09, 2013 at 08:43

That's where I lied a little bit. I need the 256KHz for audio, but its not connected to an audio codec, its connected to an audio interface into a SLIC. It uses a PCM audio interface with the following

The pins are: TX - 16 bit audio RX - 16 bit audio FRAME - 1 Bit per 16 bits CLK - 256kHz However here lies the problem, this is a full duplex bus, but the STM32 only supports half-duplex. So maybe my real question is, how do I support a full duplex implementation of I2S with only 4 pins and 1 I2S peripheral?

[waclawek.jan]

Posted on April 09, 2013 at 09:01

No, you can't output 256kHz directly on the MCO pin as output from the I2SPLL, but I didn't mean that. I meant to configure one of the I2S to output 256kHz as the bit clock (I2S_CK), and use only that signal from the module. You'd need to feed some data to it to work, but using DMA it's quite painless.

OK you lose one of the SPI/I2S modules, but hey, you've still got two/one more to burn... 🙂 JW

[Paul UHS]

Posted on April 09, 2013 at 09:44

To give an idea of what I am trying to do I have connected an SPI port (setup as a slave) to the to the SLIC like so

          -

 STM32   SLIC

 SPI_MOSI  PCM_TX (SLIC sends samples on this pin)

 SPI_MISO  PCM_RX (SLIC recvs samples on this pin)

 SPI_CLK  PCM_CLK

 SPI_CS (FRAME)

 PCM_FRAME

 256KHz_CLK  Connect to both SPI_CLK & PCM_CLK

 This way I can use the SPI bus as a full duplex bus for the audio. But to do this I need to generate a 256KHz clock externally, as well as output the 256KHz clock into the SPI peripheral. I like your idea of using the peripheral direct. Unfortunately I am using 1 SPI for talking to a Flash, 1 for this audio, and another for audio too. That's all three gone :\

[waclawek.jan]

Posted on April 09, 2013 at 10:13

And are you aware of the synchronous mode of USARTs?

That can neatly replace master-mode SPI in applications where speed and continuous clock are not critical. JW