2015-05-26 05:44 AM
We have a solution, which reading audio file from SDCard and playing by I2S. It works ok when the CPU Clock Speed is >= 84Mhz. To reducing the Power Consumption, we have to reducing the CPU Clock Speed to 24MHz, then there is a very high noise level in the speaker. My question are
1. Is the stm32f405 capable of playing audio by I2S when the CPU Clock Speed is 24MHz? Has anyone ever done such test?2. How to debug and locating such kind of noise level issue?BestRegards,Biao2015-05-26 07:37 AM
My suspicion: the MCU is not able to sustain the throughput rate (from SD card to I2S) with the lower clock frequency.
I would measure the runtimes of both handlers (perhaps SDIO for SD card, SPI/I2S), and their sequence. Perhaps set/reset a GPIO on entry/exit, and visualise it with a scope. Even checking the ''noisy'' audio output with the scope could give you some hints about timing issues.2015-05-26 10:31 AM
The SDIO has specific AHB/APB clocking requirements.
You some be able to measure the bandwidth of your tasks, and ascertain if you have enough horse-power at 24 MHz to read the data your want, and dispatch it via.You haven't provided any real numbers to work with here. But you'd need to read adequately sized blocks of data from the SD card. You need to review how long that takes, and then the timing of the ping/pong data buffers out the I2S interface. ie consider the buffer size, and the placement of HT/TC DMA interrupts, with respect to your ability to read data and sustain a stream of it.2015-05-28 03:59 AM
Adding to what others have posted already.....
Are you just reading PCM data and sending it out over I2S or are you reading a compressed format like MP3 that requires considerable CPU time to decompress into PCM data? When the system is working, are you running the processor at 84MHz all the time, or only for as long as it needs to? The way to do a minimal power application is to run the processor fairly fast for only as long as you need to, then let the processor sleep whenever it is not actually doing work. You need to make extensive use of interrupts and almost no use of busy waiting. An alternate approach is to switch between running really fast and fairly slow, instead of switching between fast and sleeping.