• Not Answered

Interrupts v Polling for collecting samples from line input

I'm back...

Please take a look at my code: https://github.com/staticd/TheGatorKator/tree/gamma

Here is my issue, which seems to be recurring because I obviously haven't figured out what my problem is:

-In my ISR, I have a section to collect samples.  I do this by passing the array pointer and sample to a frame_and_filter file.  The frame_and_filter file filters the data and fills the input buffer.  Upon completion, I move to the next control element.

-The problem is that I increment the index of the array and see that the index has made it to the end of the buffer but there are no data!

-When I add a printf to the ISR to see that I am indeed collecting samples, low and behold, my input_buffer has data.  I do the same thing for the frame_and_filter (commenting out the printf in the ISR) and I get the same behavior.

-I have tried not including the filtering of the data and I still get no data in the input_buffer.  I did this because I thought that perhaps the filtering was taking too long.  That turns out to not be an issue.

My code should compile on anyone's CCS v5, if you'd like to try it out and see if you can point out my blunder.

As for polling, I created a new branch: https://github.com/staticd/TheGatorKator/tree/psi

On this branch I tried polling instead of interrupts.  In this case, I get my samples but every other sample is zero and this just won't work for my application.

I think I got a little cocky on my last post because I had made a little progress but there is a fundamental misunderstanding on my part, I thimk. 

If you could look at my code and see why it is behaving like this, I would be forever grateful.

11 Replies

  • Natt,

    Welcome back. I hope you had a good couple of weeks away from us.

    There are a lot of different people who try to help on the TI E2E Forum, and the same number of different personalities and preferences. Please do not be offended if I do not download and debug your code. There may be cases where some snippets will need to be pasted inline, but 80% of problems can be solved from your own thoughtful description of your observations. Other people may do this differently, and you might like their answers more.

    Even though you and I have a long history together (weeks), I do not know from this post which DSP you are using. It probably does not matter, but it could be helpful in many cases.

    Natt Day
    -When I add a printf to the ISR to see that I am indeed collecting samples, low and behold, my input_buffer has data.

    My first reaction here is "never put printf in an ISR"; printf is slow and non-deterministic. But you are using this for debug purposes.

    My second reaction is that printf may be accidentally cleaning some cache for you. That is my guess for your problem. But that would assume that you have a non-DSP master like the EDMA3 or some peripheral that has a bus mastering capability, and that it needs to have the cache coherency managed. The Megamodule or CorePac Reference Guide is the place to read about the available cache coherency management hardware, the SYS/BIOS User's Guide is the place to read about the BCACHE_ (or CACHE_ ?) API functions, and the Wiki is a good place to search for training material on "C6000 training" (no quotes) to look through some written or recorded training material.

    Natt Day
    I tried polling instead of interrupts.  In this case, I get my samples but every other sample is zero and this just won't work for my application.

    Similar first reaction as above. The second sentence is not clear. Are you getting all your samples and they are spread out with zeroes in between, or are you dropping half the samples with zeroes in their places?

    But the fact that polling gets the data (assuming without the printf's), it implies that the interrupts were on a sample-by-sample basis and not from an non-DSP-core module like the EDMA3. So my guess above could be totally wrong.

    A clue as to the peripheral through which the data is being accessed would be helpful, too.

    Regards,
    RandyP

  • In reply to RandyP:

    Thanks for the reply, RandyP.  I am using the c6713dsk by Spectrum Digital.  I should have included that.

    Indeed, I am just using the printf for debug purposes only.

    I have used the C6000 training during my development and still not discovered why this behavior is occurring.  As far as I can tell, everything is hunky-dory, minus the application doing what I intended it to do.

    My setup is quite simple.  I am using the line input and I am collecting samples from the left channel (for now).  I am supplying audio from my computer or a microphone.  I have checked the inputs and they are of appropriate energy for full scale functionality of the ADC.

    Since I started from an empty project, I have not implemented my project using SYS/BIOS.  Instead, I have Chassaing's assembly file to construct the IST.

    In a perfect world, I know someone out there knows exactly what's wrong and they'll lead me in the correct direction.  Honestly, all of the documentation is overwhelming and very difficult to sift through in order to identify a certain problem--with little situational awareness.

    So, here is what I know: I know I my ISR is being exectued and I am collecting samples and running my code.  What I don't know is why that processed sample (filtered) is not being copied to my data array.  Honestly, I am baffled and don't know where to start.

    I think I am in a position where I have to continue using the polling technique, even though I am getting a zero for every other sample.  I haven't determined whether the data is being shifted by the zero value or skipped over.

  • In reply to Natt Day:

    Natt,

    You did not say specifically, but I now guess that you are not using EDMA for getting the data. This means cache is not going to be the issue. EDMA is a very good thing to use for data transfer and for servicing peripherals like serial ports, but it does add a new issue of coherency.

    Do you have a simple in/out loop where you can take the input samples and write them to the LineOut or SpeakerOut to validate that the data is coming in and going out? This would be a good data point to have.

    It sounds like you believe that you are getting all of the data samples from the serial port but they are not landing in an internal buffer. That would mean that you do not have any questions about the functionality of the DSP but of your C code. Do I understand that correctly, based on what you believe is going on?

    Are the polling zeroes in the samples from the serial port or are they in the input buffer?

    One debug technique for looking into the polling zero issue would be to use the polling code in the ISR and see how it behaves differently (if it does).

    Regards,
    RandyP

  • In reply to RandyP:

    Honestly, I am just at a loss.  I would like to spend my time working on my algorithms rather than debugging hardware.  So, I am punting again...

    I am trying to figure out how to learn from your sage advice but I just end up even more confused...ugh.

    How is it that there is not clear, concise approach to solving this problem?

  • In reply to Natt Day:

    Natt,

    Why do you think it is hardware. The implication I am getting from your description so far is that you are getting the samples okay from the hardware, but they are missing after the first phase of processing puts them in an input buffer. Am I confused about that?

    Regards,
    RandyP

  • In reply to RandyP:

    Indeed, I don't know which is the culprit.  :)

  • In reply to Natt Day:

    Natt,

    What do you do with the sample when you get an interrupt? Show me a snippet that you think is relevant from the ISR.

    Regards,
    RandyP

  • In reply to RandyP:

    If I uncomment the printf, I can see the sample value in the console and when I halt, input_buffer is being populated.  The contrary is true as you see the code.

  • In reply to RandyP:

    // interrupt service routine

    interrupt void c_int11() {

     

              short sample_data;

              short out_sample;

     

              if (program_control == 0) {

     

                       sample_data = input_left_sample();

                       //printf("sample: %d\n", sample_data);

                       signal_status = frame_and_filter(sample_data, input_buffer);

                       out_sample = sample_data;

                       if (signal_status > 0) {

     

                                 program_control = 1;

                       }

                       output_sample(out_sample);

              }

     

              if (program_control == 1) {

     

                       out_sample = playback();

                       output_sample(out_sample);

              }

     

              return;

    }

    I tried posting an image of this and see it has to be approved my a moderator...that's probably good.  ;)

     

  • In reply to Natt Day:

    Natt,

    Is it correct that if you uncomment the printf, then you see data samples?

    If you force signal_status=0 and comment out the frame_and_filter call, do you get good audio from input to output?

    With the printf commented again, create an array that captures sample_data in a circular buffer fashion, then halt the processor and look at that array in CCS. Does it look like data?

    If you then look at input_buffer, does it look empty?

    From all of this, you should know whether it is hardware or software. And you should have an idea where the problem may be.

    I know you do not like just getting questions, but you can figure this out.

    Regards,
    RandyP