AnsweredAssumed Answered

CCES Blackfin AudioTalkthrough example -- Unexpected behaviour when introduce emulation operation

Question asked by MikeSmithCanada on Sep 22, 2013
Latest reply on Sep 25, 2013 by CraigG

Hi

 

Trying to understand the audio interrupt behaviour

 

At the start of this code there are 4 arrays\

memset (AudioBuff1, 0, BUFFER_SIZE);

    memset (AudioBuff2, 0, BUFFER_SIZE);

    memset (AudioBuff3, 0, BUFFER_SIZE);

    memset (AudioBuff4, 0, BUFFER_SIZE);

 

2 arrays are queued for Rx and 2 for Tx

 

In the middle of the callback there is

adi_ad1836a_SubmitTxBuffer(uTTCOS_pDevHandle, pRxBuffer, uTTCOS_AUDIOBUFFERSIZE);

 

    /* Submit completed TX buffer to RX */

    adi_ad1836a_SubmitRxBuffer(uTTCOS_pDevHandle, pTxBuffer, uTTCOS_AUDIOBUFFERSIZE);

 

    /* Reset the buffers */

    pRxBuffer = NULL;

    pTxBuffer = NULL;

 

Which keeps the audio interrupt going by resubmitting buffers

 

I am trying to demonstrate the impact of putting a print statement into a real-time system to persuade my students not to debug real-time code with print statements -- however the audio behaviour is not what I expect

 

If I put code such as

   static int count = 0;

    count++;

    if (count == XXX) {

        printf("Hello                                                                                                                \n");

        count = 0;

    }

 

into something that gets executed occasionally (and not part of the audio call-back)

 

I get the audio stream paused while the print statement is processed by the emulator mode -- and then the audio stream recovers

Thats what I expected to happen -- the interrupts stop but continue

 

In VDSP -- If I put

   static int count = 0;

    count++;

    if (count == XXX) {

        printf("Hello                                                                                                                \n");

        count = 0;

    }

into the call-back (ISR) -- then it played hell with the audio, but the audio kept on playing after stuttering because of switching to emulator mode

 

However in CCES -- I see the first print when inside the call-back -- and then everything quits -- almost as if the audio interrupt stream does not recover and no further call-backs

 

The time out between the two modes (print in main and call-back) can't be different

 

Is this an issue with the driver when doing an emulation inside an ISR on CCES or am I misunderstanding functionality ?

 

The code is in total never-never land -- Having to cycle everything to regain control -- using HPUSB-ICE and a late version 0.5 / 0.5 BF533 under WIndows 7 -- 64 bit

 

Thanks

Mike

Outcomes