5409 | 5416 | AD5 | ADC | BIOS | Boot | Booting | Bootloader | C540 | C5402 | C5409 | C5416 | CCS | Codec | DMA | Dmad | DSK | DSKPlus | Dsplib | EVM | FFT | FIR | Flash | GPIO | HPI | Initialization | Interrupt | JTAG | LOG_printf | MCBSP | RFFT | RTDX | Sampling | STLM | UART | VC540

Dear Jeff
I did following things:
First: Working
long rx_wait = 0;
long tx_wait = 0;  
while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i])) rx_wait++;
while (!PEP5416_AIC23_write16(hCodec, bufferxmt)) tx_wait++ 
cfir();
and inside cfir() I just did copy paste (xmt=rcv). In that case rx_wait count is varying 0 to
57 and tx_wait is 0
Second: Not Working output is noise
long rx_wait = 0;
 long tx_wait = 0;  
 while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i])) rx_wait++;
 while (!PEP5416_AIC23_write16(hCodec, bufferxmt)) tx_wait++ 
cfir();
and inside cfir i added filterbufferbysamples and copy paste (xmt=rcv) and in that case I got
both rx_wait and tx_wait as 0
Third: Not Working output is noise
long rx_wait = 0;
while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i])) rx_wait++;
  long tx_wait = 0;  
  while (!PEP5416_AIC23_write16(hCodec, bufferxmt)) tx_wait++ 
 cfir();
and inside cfir i added filterbufferbysamples and copy waste (xmt=rcv) and in that case again i
got both rx_wait and tx_wait as 0.
I got all the above counts by placing breakpoints at their next step. I hope I am clear. Kindly
reply.
Thanking You
Megha Daga

Jeff Brower <j...@signalogic.com> wrote: Megha-

This is not the code I asked you to try.  Please do the steps I asked you
to do or I can't help you any more.

Also I asked what are the wait counts with write then read.

-Jeff

> I did that too:
>  while(1)
>     {
>     i=0;
>     rx_wait = 0;
>     tx_wait = 0;
>        // for (i = 0; i < 2048; i++)
>         {
>             while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]))
> rx_wait++;
>             while (!PEP5416_AIC23_write16(hCodec, bufferxmt)) tx_wait++;
>             cfir(bufferrcv, &bufferxmt, 1);
>         }
>     }
> And for the values, I first put breakpoint at second while (while for
> write) and got value of rx_wait and then put another break point at cfir()
> and got value for tx_wait. The value with FilterBufferBySamples in cfir()
> was 0 for both and without that function was variable (0 to 57) for
> rx_wait and 0 for tx_wait.
> Thanking You
> Megha Daga
> Jeff Brower  wrote:     Megha-
>   Secondly when I calculated the rx_wait and tx_wait without
> FilterBufferBySamples I got a range of values (0-50) for rx_wait and 0
> for tx_wait. For rx_wait it was changing every time. And what if you
> just do this:
>    long rx_wait;
>   long tx_wait;
>   int sample;   rx_wait = 0;
>   while (!PEP5416_AIC23_read16(hCodec, &sample)) rx_wait++;
>
>   tx_wait = 0;  <--- breakpoint, check rx_wait here
>   while (!PEP5416_AIC23_write16(hCodec, &sample)) tx_wait++;
>
>                 <--- breakpoint, check tx_wait here
> what are the xx_wait values then?  At least one should be 10000s if the
> code counts for 22 usec.  Try the code both with call to AIC23_read()
> first and AIC23_write() first.
> -Jeff
> Jeff Brower  wrote:  Megha-Suggestions:1) Comment
> out Preemphasis() for now, during debug.2) Does FilterBufferBySamples()
> expect floating-point arguments?  If so, you are passing pointer to
> fixed-point, which is going to be a problem.3) Place counters in these two
> loops and find out how long they wait:  long rx_wait = 0;
>   long tx_wait = 0;  while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]))
> rx_wait++;
>   while (!PEP5416_AIC23_write16(hCodec, bufferxmt)) tx_wait++;One loop
> should wait a long time (close to 22 usec, or one sample period), the
> other loop should wait a very short time, just a few counts.  Make sure
> the short wait is called second.-Jeff
>  -------- Original Message --------
>
>    Subject:   Re: [c54x] code working on simulator but not on device?
> Date:   Mon, 8 May 2006 12:06:16 -0700 (PDT)    From:   megha daga
>     To:   Jeff Brower
> ,c54group    Dear Jeff
> cfir() is not taking too long. cfir is not taking floating point data.
> This is because 54xx is reading just fixed point data and I am passing
> fixed point data to the cfir. So it is like following:
> Int16 bufferrcv[2048];
> Int16 bufferxmt;
> main()
> {
> .......
> while(1)
>     {
>     i=0;
>        // for (i = 0; i < 2048; i++)
>         {
>             while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>             while (!PEP5416_AIC23_write16(hCodec, bufferxmt));
>             cfir(bufferrcv, &bufferxmt, 1);
>         }
>     }
> void cfir(Int16 *data,Int16 *results,Int16 blksize)
> {
>     Preemphasis(data,blksize);    FilterBufferBySamplesIIR(data, blksize);
>    *results = data[0];
>      //  *results = 32768*flacoustic[0];
> }
> So you see data, results is fixed point an dblksize is 1. Now inside the
> FilterBufferBySamplesIIR we are passing fixed point, but all the
> calculations (with coefficients) is in float. In the end the output is
> stored in flacoustic (defined extern float) in FilterBufferBySamplesIIR().
> This float output is multiplied by 32768 in cfir() and the int equivalent
> of that gets srored in results. But in the above case I am not even using
> flacoustic. I am just copy pasting the data to results. Just running the
> Filter function is disturbing the output. And as I said before, the filter
> function is not changing the data[0]. I can see that in the watch window.
> I will try optimizing the filter function today. That might help.
> Kinldy reply.
> Thanking You
> Megha Daga
>
>  Jeff Brower  wrote:  Megha-> Yes its an IIR
> filter and yes everything inside that is in floating point
>> representation. I understand that 54xx will take long due to the
>> floating
>> point, but can anything be done to reduce that like optimization or
>> something...(as I think that will make it work)First question is whether
>> cfir() is really taking too long, which I doubt, or you have some other
>> problem(s).  Does cfir() expect floating-point or fixed-point arguments?
>>   If floating-point, then the code I gave you should look like:  /* wait
>> for input sample to be ready */
>   while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));  /* output last
> filtered sample */
>   PEP5416_AIC23_write16(hCodec, &out_sample);  /* filter one sample */
> flt_input = bufferrcv[i]/32767.0;
>   cfir(&flt_input, &flt_output, 1);  out_sample = fltoq(flt_output);where
> flt_xxx are floats.Also, are you sure that "blksize" inside cfir() = 1?
> If you do more than one, it won't work since you're only processing one
> sample at a time.-Jeff
>   Jeff Brower  wrote: Megha-> Thanks. Well as I
> told I did debug the code and saw step by step, the
>> value is getting transferred as it is and it is coming into results as
>> required, but somehow o/p is not coming. It can be due to length of the
>> code. If its long can you suggest some thing.If it's IIR filter, and you
>> call it with len = 1 (filter one sample), then
> it should not take long.If cfir() is all in floating-point, then that may
> be taking a long time to
> process. Floating-point on C54xx has to be done with software routines,
> since C54xx is fixed-point processor.Well, you will have to figure this
> out.-Jeff> Jeff Brower wrote: Megha-
>>
>>> What I understand is you got 22.6usec from the audio sampling rate of
>>> 44.1KHz. Well but I think I dont understand the theory behind codec
>>> waiting for next 22.6usec to take another data. See I understand it
>>> takes
>>> input data and writes at output but I dont understand why wont it loose
>>> data when its waiting for those 22.6usec. As the data is continous and
>>> i
>>> wont be reading anything in that 22.6usec interval, wont that data get
>>> lost? Kindly clear this confusion of mine.
>>
>> There is no "continuous" in "digital signal processing (dsp) system.
>> With
>> your sampling rate, each time the codec samples the audio data, there is
>> 22.6 usec until the next sample. That is the time available to process
>> one sample. All filtering -- or whatever processing needed -- for each
>> sample must fit within that time. Otherwise, the system is not in
>> real-time.
>>
>>> As per as single sample processing is concerned, its not working.
>>
>> In the code I suggested previously:
>>
>> /* wait for input sample to be ready */
>> while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>>
>> /* output last filtered sample */
>> PEP5416_AIC23_write16(hCodec, @out_sample);
>>
>> /* filter one sample */
>> cfir(bufferrcv[i], @out_sample, 1);
>>
>> what happens if you replace cfir() line with:
>>
>> out_sample = bufferrcv[i];
>>
>> do you get continuous output? Sure. So then you look into cfir()
>> routine, find out what's wrong? Maybe it has a bug, takes too long...
>>
>> Whatever is wrong with cfir(), I don't know -- that's your code and you
>> have to debug it. I can't help you with this any further until you get
>> the single-sample step working. When you get that far, write the group
>> again.
>>
>> -Jeff
>>> As I
>>> wrote in previous mail, I did try your suggestion, but I am still
>>> getting
>>> noise. there is contious output but output is noise. I did the
>>> following:
>>> In main:
>>> while(1)
>>> {
>>> i=0;
>>> // for (i = 0; i < 2048; i++)
>>> {
>>> while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>>>
>>> while (!PEP5416_AIC23_write16(hCodec, bufferxmt));
>>> cfir(bufferrcv, &bufferxmt, 1);
>>> }
>>> // counter++;
>>> }
>>> and in cfir()
>>> {
>>> Preemphasis(data,blksize);
>>>
>>> if(doagcdrc)
>>> {
>>> //Now call the front end functions that are desired
>>> AGCDRC(data,blksize);
>>> }
>>>
>>> FilterBufferBySamplesIIR(data, blksize);
>>>
>>> //for (i = 0; i < blksize; i++)
>>> //i=0;
>>> *results = data[0];
>>> // *results = 32768*flacoustic[0];
>>> }
>>> In above case I am just trying to copy paste again ( *results =
>>> data[0]).
>>> The change is I am running the FilterBufferBySamplesIIR(). If I remove
>>> FilterBufferBySamplesIIR() and try the above copy paste thing, it
>>> works.
>>> But with that filter function inside, I am not getting the proper
>>> output.
>>> The filter function is not changing the data anywhere. I dont get why
>>> this
>>> thing is happening. I even checked the values in watch window and it is
>>> fine, but still its not fine at headphone. Sampling rate is 44KHz for
>>> filters and device is runnning at 48MHz (96/2, divide by 2 mode). I am
>>> attaching the respective code. Kindly tell me the reason behind this.
>>> Kindly reply.
>>> Thanking You
>>> Megha Daga
>>>
>>>
>>>
>>> Jeff Brower wrote: Megha-
>>>
>>>> You suggested:
>>>> /* wait for input sample to be ready */
>>>> while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>>>>
>>>> /* output last filtered sample */
>>>> PEP5416_AIC23_write16(hCodec, @out_sample);
>>>>
>>>> /* filter one sample */
>>>> cfir(bufferrcv[i], @out_sample, 1);
>>>>
>>>> i++;
>>>>
>>>> The above case is not real time. In the above case when the processor
>>>> is
>>>> processing write() and after that cfir(), nothing is getting read into
>>>> bufferecv[] and hence that amount of data is lost.
>>>
>>> It is real-time, but you don't understand signal processing well enough
>>> to
>>> realize it. The above code waits for the codec sample period, does
>>> input
>>> and output, then has 22.6 usec of time to filter one sample before the
>>> next sample period. For sure your IIR filter can process one sample in
>>> 22.6 usec -- if not, then you will not be in real-time and no amount of
>>> DMA or any other technique is going to fix that. Do you understand the
>>> significance of 22.6 usec? If you cannot answer that, I cannot help you
>>> any longer.
>>>
>>>> What I want is real time and thats why I was thinking of PIP, HST,
>>>> McBSP,
>>>> DMA...
>>>
>>> DSP students have to learn to crawl before they can walk. Your current
>>> level of DSP coding experience does not allow you to try advanced
>>> techniques. If you can get single-sample processing working, then you
>>> can
>>> advance one step at a time: enable McBSP interrupts (i.e. don't poll
>>> for
>>> sample period), then add buffering instead of single-sample, etc.
>>>
>>> -Jeff
>>>
>>>> I tried one of the sample examples by TI for PIP (copy.pjt copies
>>>> data from i/p to o/p). But thats not working on my device. I am not
>>>> getting the reason. I have just added the device initialization part
>>>> to
>>>> that code. I am attaching that code, if possible have a look at that.
>>>> What I think is if I can read data from PIP (continous real time). I
>>>> can
>>>> read it in form of 3/4 frames. Then I can pass 1 frame at a time to
>>>> the
>>>> filter process and then that frame to o/p. Then again I will take 2
>>>> frame
>>>> and so on. this way I wont loose data. I will have to use interrupts.
>>>> Thats what in my mind.
>>>> Kindly provide your suggestion.
>>>> Thanks
>>>> Megha
>>>>
>>>> Jeff Brower wrote: Megha-
>>>>
>>>>> There is one more thing. I ran the following program:
>>>>> i=1;
>>>>> while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>>>>> cfir(bufferrcv, bufferxmt, BUFFSIZE);
>>>>>
>>>>> and in cfir():
>>>>>
>>>>> FilterBufferBySamplesIIR(data, blksize);
>>>>>
>>>>> // for (i = 0; i < blksize; i++)
>>>>> i=1;
>>>>> results[i] = data[i];
>>>>> if I remove filterbufferbysamples I get proper output for single
>>>>> samples
>>>>> (i=1), but if i add filterbufferbysamples I am not getting output but
>>>>> just noise.
>>>>
>>>> This is because you are waiting too long to output to the codec. Try
>>>> it
>>>> this way:
>>>>
>>>> /* wait for input sample to be ready */
>>>> while (!PEP5416_AIC23_read16(hCodec, &bufferrcv[i]));
>>>>
>>>> /* output last filtered sample */
>>>> PEP5416_AIC23_write16(hCodec, @out_sample);
>>>>
>>>> /* filter one sample */
>>>> cfir(bufferrcv[i], @out_sample, 1);
>>>>
>>>> i++;
>>>>
>>>> /* end of loop; repeat and wait for next sample */
>>>>
>>>> The idea is that when the codec is ready, you need to do both input
>>>> and
>>>> output without waiting. Otherwise the codec will output some junk.
>>>>
>>>> If you can get this to work, then you can try buffering samples,
>>>> instead
>>>> of single sample processing. One step at a time.
>>>>
>>>> -Jeff
>>>>
>>>>
>>>>> My data is not changing in filterbufferbysamples. Its the same. I
>>>>> am just using it once inside that function that to get its value. i
>>>>> am
>>>>> not changing its value. Can you think of any reson why thats
>>>>> happening.
>>>>> kindly reply.
>>>>> thanking you
>>>>> megha
>>>>>
>>>>>
>>>>>
>>>>> Jeff Brower wrote: Megha-
>>>>>
>>>>>> Yeah thats what I was asking about. Currently I am using just a
>>>>>> single
>>>>>> buffer in my program which is making my data lost. Hence I need to
>>>>>> use
>>>>>> dual buffers.
>>>>>> Now what I had in mind:
>>>>>> to use dual buffer I will have to use McBSP and DMA. I am not sure
>>>>>> how
>>>>>> to
>>>>>> use dual buffer without those and I dont want to use DMA right now.
>>>>>> Can you help me in how to use them. Or can you give some links,
>>>>>> where
>>>>>> their description can be found.
>>>>>
>>>>> If your loop is processing each sample, which would explain why you
>>>>> get
>>>>> some noise on the output if you wait too long to supply the output
>>>>> value
>>>>> (i.e. result from the filter), then for now you can just use a single
>>>>> sample delay, then worry about ping-pong buffer later.
>>>>>
>>>>> For example, if your processing loop is based either on a sample
>>>>> interrupt
>>>>> or polling (waiting) for each sample, then you can do something like
>>>>> this:
>>>>>
>>>>> cur_sample = fltoq(flacoustic[i]);
>>>>> PEP5416_AIC23_write16(hCodec, last_sample);
>>>>> last_sample = cur_sample;
>>>>>
>>>>> Note this causes a 1-sample delay in the output.
>>>>>
>>>>> Only when your filter and other processing gets to be enough it
>>>>> cannot
>>>>> be
>>>>> accomplished in one sample period do you need to worry about using
>>>>> ping-pong buffers. What is your sampling rate?
>>>>>
>>>>> -Jeff
>>>>>
>>>>>
>>>>>> Jeff Brower wrote: Megha-
>>>>>>
>>>>>>> I am not using that in recurrsion and hence I took your advice.
>>>>>>> Actually
>>>>>>> there is one more function in DSP called fltoq(). it converts
float
>>>>>>> to
>>>>>>> Q15 (short). i read about it and it does nothing but
multiplication
>>>>>>> by
>>>>>>> 32768 :)
>>>>>>> Well actually I dont know how this scaling is affecting my
output.
>>>>>>> Right
>>>>>>> now I am not getting the whole output. Actually as I am using a
>>>>>>> single
>>>>>>> buffer, my data is getting lost when the previous data is getting
>>>>>>> processed and hence I am just getting beeps right now instead of
>>>>>>> continous data. I think I will have to use two buffers now, ex
ping
>>>>>>> pong
>>>>>>> buffering. But I think I will have to use it with DMA and McBSP.
Do
>>>>>>> you
>>>>>>> have any suggestions on that?
>>>>>>
>>>>>> Ping pong (dual) buffers are needed for real-time, continuous
>>>>>> output:
>>>>>> in
>>>>>> your case, one buffer is going out to DAC while other buffer is
>>>>>> being
>>>>>> filled by your filter output + fltoq().
>>>>>>
>>>>>> My suggestion is to get that working first, then worry about DMA.
>>>>>> Your
>>>>>> sampling rates are not high enough to cause DMA to be required for
>>>>>> real
>>>>>> time operation, so save the DMA for last step.
>>>>>>
>>>>>> -Jeff
>>>>>>
>>>>>>> Jeff Brower wrote: Megha-
>>>>>>>
>>>>>>>> I thought of converting like that. I thought of multiplying
my
>>>>>>>> filtered
>>>>>> output and giving that to result. But you see like this I will
>>>>>> disturb
>>>>>> the filtered value. It wont be same as it was. So thats a problem I
>>>>>> think.
>>>>>>>
>>>>>>> It's just scaling. As long as you don't feed results[] back into
>>>>>>> the
>>>>>> filter, then no problem. If results[] must be used as recursive
>>>>>> input
>>>>>> to the filter, then keep 2 arrays:
>>>>>>>
>>>>>>> results[i] = flacoustic[i];
>>>>>>> dac_out[i] = (short int)(32767.0*flacoustic[i]);
>>>>>>>
>>>>>>> where results[] is float, and dac_out[] is short int.
>>>>>>>
>>>>>>> -Jeff
>>>>>>>
>>>>>>>> Jeff Brower wrote: Megha-
>>>>>>>>
>>>>>>>>> As I told in my last mail, there is some problem in my
filter
>>>>>> function. cause its running properly but the filtered output is not
>>>>>> coming. I got the reason why. Well the last lines are:
>>>>>>>>> for(i=0; i
>>>>>>>>> results[i] = flacoustic[i];
>>>>>>>>> Well flacoustic is the filtered output from filter
function and
>>>>>> results is the array which is written back on the output port of the
>>>>>> device. Now
>>>>>>>>> the problem is flacoustic is float and result is
>>>>>>>>> Int16(typedefined
>>>>>>>>> as
>>>>>> short).the filetered function is returning all values between 1 and
>>>>>> -1
>>>>>> and hence when they go into results (defined short), the value
>>>>>> becomes
>>>>>> 0, and hence no output. I hope you got my point.
>>>>>>>>
>>>>>>>> Try like this:
>>>>>>>>
>>>>>>>> results[i] = floor(32767.0*flacoustic[i]);
>>>>>>>>
>>>>>>>> I don't know if you floor() function is available or not; if
not
>>>>>>>> find
>>>>>>>> a
>>>>>> function that converts float to int. Also just this might work:
>>>>>>>>
>>>>>>>> results[i] = (short int)(32767.0*flacoustic[i]);
>>>>>>>>
>>>>>>>> but I'm not sure because 54xx floating-point library support
in
>>>>>>>> CCS
>>>>>>>> may
>>>>>> not be that complete.
>>>>>>>>
>>>>>>>> In any case, once you have values between -32768 and 32767 in
>>>>>> results[], then you can send those out to D/A converter; i.e. using
>>>>>>>> PEP5416_AIC23_write16() function.
>>>>>>>>
>>>>>>>> -Jeff
>>>>>>>>
>>>>>>>>
>>>>>>>>> Now there were two choices either I convert all Int16 to
float or
>>>>>> float to
>>>>>>>>> Int16. if I convert float to Int16, I will get 0 in
flacoustic
>>>>>>>>> itself
>>>>>> (cause filtered value is between 1 and -1 and will become 0 if
>>>>>> flacoustic
>>>>>>>>> is short). So the only option remains is converting Int16
to
>>>>>>>>> float.
>>>>>> Now the problem is in the device inbuilt functions, when i read
>>>>>> data,
>>>>>> its
>>>>>>>>> read in Int16 format. the statement is decalred like
following in
>>>>>>>>> the
>>>>>> header file of teh device (pep5416_aic23.h):
>>>>>>>>> CSLBool PEP5416_AIC23_read16(PEP5416_AIC23_CodecHandle
hCodec,
>>>>>>>>> Int16
>>>>>> *val);
>>>>>>>>> and write is defined in following manner:
>>>>>>>>> CSLBool PEP5416_AIC23_write16(PEP5416_AIC23_CodecHandle
hCodec,
>>>>>>>>> Int16
>>>>>> val);
>>>>>>>>> So as you see the val is Int16 and now if I convert Int16
into
>>>>>>>>> float,
>>>>>> I will have to convert it here too. But if I convert it to float,
>>>>>> there is
>>>>>>>>> lot of noise and I am not getting proper output. i tried
it
>>>>>>>>> without
>>>>>> filter
>>>>>>>>> function, on my first code (simple audio in and same audio
out).
>>>>>>>>> I
>>>>>>>>> am
>>>>>>>>> not
>>>>>>>>> getting proper output if I change this function; which I
was
>>>>>>>>> getting
>>>>>>>>> when
>>>>>>>>> it was Int16. I hope I am able to explain everything
clearly.
>>>>>>>>> Hence my problem remains. I am not able to think of a
solution to
>>>>>> this. If you have any idea kindly help me.
>>>>>>>>> Thanks
>>>>>>>>> Megha
>>>>>>>>>
>>>>>>>>> Jeff Brower wrote: Megha-
>>>>>>>>>
>>>>>>>>>> As I wrote in my last mail, its problem with
InitBuffer
>>>>>>>>>> function.
>>>>>>>>>> Well
>>>>>>>>>> I debugged it further and there is no problem in that.
The
>>>>>>>>>> problem
>>>>>>>>>> is
>>>>>> when data goes into the filter function "cfir()'. I just tried
with
>>>>>> a
>>>>>> loop inside the cfir. The loop did following:
>>>>>>>>>> rcv = xmt;

______________________________
New Year Gift for Members of DSPRelated.com.  Details here.

(You need to be a member of c54x -- send a blank email to c54x-subscribe@yahoogroups.com )