I2S at 384kHz... can it be done ?

[alberto239955_stm1_stmicro_com]

Posted on June 27, 2013 at 00:37

Hello,

  the I2S interface is specified up to 192kHz, and actually the  stm32f4xx_spi.h  file has defines from 8kHz up to 192kHz. I am wondering if anybody has ever tried to push the I2S interface up to 384kHz (and possibly beyond...). Were it possible, that would be very interesting for my product. Thanks for any feedback, positive or negative.

[waclawek.jan]

Posted on June 27, 2013 at 13:33

> I used for the current code the routines that I found defined in  stm32f4xx_spi.c,

> namely the I2S_Init() with its parameters, which however do not contemplate the case of  > speeds higher than 192 ks/sec.  Well, except of the assertion at the beginning of I2S_Init(), I see no problem using it for speeds beyond 192ksps. There might be some rounding errors involved in the calculations there (you should check that), but apart of that, as long as you are within the prescribed limits (especially that the complete divider should be >=4), it should work. JW

[Tesla DeLorean]

Posted on June 27, 2013 at 13:42

> Elsewhere the shifting unit is limited to 37.5 MHz, Where?

Front page of the data sheet/manual. At least in Rev 1, Rev 4 moves it to 42 MHz''Up to 3 SPIs (37.5 Mbits/s), 2 with muxed full-duplex I2S to achieve audio class accuracy via internal audio PLL or external clock'' There are multiple other reference too it, I'd have to wade through the archive to figure when the goal posts moved.

[waclawek.jan]

Posted on June 27, 2013 at 14:10

Ah, I see. Thanks.

JW

[alberto239955_stm1_stmicro_com]

Posted on June 27, 2013 at 18:01

Clive and Jan,

    thanks indeed for your suggestions and help. After all, it looks like it can be done... I will contact immediately the FPGA programmer to talk him into modifying his code to give me rates of 384 and 768 ks/sec. I have just copied  stm32f4xx_spi.c  into my code, modified it eliminating all the asserts and the sanity checks of the #ifdef / #endif  blocks, and it compiles without errors at 384 ks/sec, waiting now for the new FPGA code. If the M4F will be capable of processing the new rates, and the product could be then updated, I will drink to your health...  🙂

[Tesla DeLorean]

Posted on June 27, 2013 at 19:27

768 KHz @ 32-bit (16+16) would be workable, however @ 64-bit (32+32) your bit clock is pushing 49.152 MHz which is beyond the expressed limit. I'll presume you're stuck at audio rates?

656.25 KHz is where you can get with 42 MHz. As synchronous structures go a shift register isn't high on the critical list for timings. I think the real issue here is that ST hasn't really validated/qualified the limit. Moving to an F429 would get you nearer 45 MHz, although the SAI peripheral might offer some other features.

[alberto239955_stm1_stmicro_com]

Posted on June 27, 2013 at 22:30

> 768 KHz @ 32-bit (16+16) would be workable, however @ 64-bit (32+32) your bit clock is pushing

> 49.152 MHz which is beyond the expressed limit. I'll presume you're stuck at audio rates? No, audio does not enter into the picture... the rates are determined by the clock of the RF sampling ADC, and the downsampling done inside the FPGA. But in any case I am a bit skeptic about the processing power of the M4F chip.. after all, I have to do CIC filters, a couple of FIRs, 1024-point FFTs, etc. etc.  At 192 kHz, I still have a good reserve of CPU cycles, but probably I will be able to reach 384 kHz, but not go beyond. But doubling the rate will be in itself a very positive step forward...   waiting for a faster clock M4F..  🙂