Problem with printf() in evmomapl138_test_audio sample

Bruno Grentzinger

Other Parts Discussed in Thread: OMAPL138

Hello,

I am testing the audio program sample provided with omapl138 experimenter kit. In the source file test_audio.c, in the function testAudioLineIn( ) there is the core loop which copy the input signal in the output:

         for (sample = 0; sample < 48; sample++)
         {
            // wait for xmit ready and send a sample to the left channel.
            while (!CHKBIT(MCASP->SRCTL11, XRDY)) {}
            MCASP->XBUF11 = (sinetable[sample] << 15) | 0x00000000;

            // wait for xmit ready and send a sample to the left channel.
            while (!CHKBIT(MCASP->SRCTL11, XRDY)) {}
            MCASP->XBUF11 = (sinetable[sample] << 15) | 0x00000000;
         }

This program is working fine, but I tried to print "dat" in the standard output and it doesn't work. More precisely, it works as soon as I don't flush stdout. For example I can set a printf( ) without flushing before the for loops because it only flushs at the end of the loops. But I can't set a printf inside the for loop, I think it's because the stack is too small, and it flush before the end of the loops. When printf flushed, the program freeze at a while (!CHKBIT(MCASP->SRCTL11, XRDY)) { } line. I noticed that the value of the register MCASP->XSTAT change from 0x50 to 0x179 after a printf( ).

I have read the wiki about printf( ) and I noticed the warning "Avoid C I/O inside interrupt handler functions". Do you think it can be the source of my problem?

Is it really possible to write on 2 outputs ( stdout and codec input ) in the same time?

Note that I have tried to change the stack size without success.

Thanks in advance

over 14 years ago

0 Joe Coombs over 14 years ago

TI__Expert 8890 points

Bruno,

The standard C I/O functions (including printf) are relatively slow and should definitely not be used in a time-critical context. One alternative is to add DSP/BIOS support to your project and use LOG_printf, which is fast enough for what you want to do.

For an example application that uses the LOG APIs in a DSP/BIOS 5.41 application, please refer to this low-level audio application for C6747:

http://software-dl.ti.com/dsps/dsps_public_sw/c6000/web/c6747_audio_edma_app/latest/index_FDS.html

Note that this application creates a LOG object in the BIOS configuration file (TCF).

Hope this helps.

0 Gus Martinez over 14 years ago in reply to Joe Coombs

TI__Mastermind 29041 points

The printf instruction is considered an emulation access. During an emulation access, the DSP CPU is halted, however the serial port is not. Since the CPU is halted, it misses the real-time event from the serial port. I agree with Joe's suggestion to use a LOG_printf (available only with the DSP/BIOS real-time OS). LOG_printf does not halt the DSP CPU. Instead, it stores the data in a buffer which is emptied only during low-activity periods.

0 Bruno Grentzinger over 14 years ago in reply to Gus Martinez

Intellectual 285 points

Thanks for your replies and explanations. So I will use printf_log instead.

Processors

Processors forum

Problem with printf() in evmomapl138_test_audio sample