Reply by Jeff Brower ●January 18, 20132013-01-18
BSA-

> Thanks for all your help. Unfortunately, I can't change
> the processor at this point so sticking with it is the only
> option.
>
> However, I appreciate your help with the following query.
>
> If sampling at 200kHz then capturing 1024 point data takes
> (1/200k * 1024 = 5.12 mSec). This way I know i need atleast
> 4 buffer of size 1024 to capture a 50 Hz cycle. In my case
> it's DMA which transfers data to CPU and it always takes 17
> CPU cycle. How would I know in this case that how much
> samples i need to get a 50 Hz cycle ?

4 samples.

-Jeff

> ________________________________
> From: Jeff Brower
> To: B S
> Cc: c...
> Sent: Friday, January 4, 2013 6:32 AM
> Subject: Re: [c6x] Re: SWI vs. TSK
>  
> BAS-
>
> I know I mentioned this already... but... multicore.
>
> One core could be doing decimation, another one your processing.
>
> Check out C66x series. Cores share substantial onchip memory area. And all cores are floating-point.
>
> -Jeff
>
>>> Date: Thu, 3 Jan 2013 05:15:36 -0800 (PST)
>>> From: B S
>> Cc: Richard Williams
>>> Subject: Re: [c6x] Re: SWI vs. TSK
>>>
>>> I could have taken your suggestion if I had an option to use McASP or slower
>>> ADC. I have to use OMAP-L138 EVM with 20 MSPS ADC. One application of my
>>> project is dealing with 1 MHz signal which make sense to use that ADC. I have
>>> to deal with 50 Hz signal using the same device. Therefore, digital filtering
>>> + decimation is the only solution i see right now.
>>
>> Let me assume Fs is 2MHz to get a 1MHz band. Then, if CPU rate is 300MHz, you
>> get no more than 150 clocks to process a single sample in your 1MHz digitized
>> signal.
>>
>> Then, you may have to downsample it to 1KHz band, then you just need to take
>> one sample out of every 1,000, and filter out aliasing frequencies above 1KHz,
>> that is between 1KHz and 2MHz. I guess this is going to be a long filter.
>>
>> I think you will have to use more CPUs and also split the analog input signal
>> into 2 channels, one sampled at a high rate, the other at a slower rate. This
>> would remove downsampling and antialiasing filter out from your system.
>>
>>> BTW, do you have any idea how could I implement decimation filter
>>> (Butterworth or Chebyshev) in C ?
>>
>> I have seen a couple of windows programs on the net that design a digital
>> filter. They calculate coefficients for either FIR or IIR filter type,
>> whichever suits better for you system.
>>
>> Rgds,
>> Andrew
>>
>>> From: Andrew Nesterov
>> To: c...
>>> Sent: Wednesday, January 2, 2013 10:56 PM
>>> Subject: [c6x] Re: SWI vs. TSK
>>>
>>>
>>> Hi B.S.,
>>>
>>>> ---------- Original Message -----------
>>>> From: B S
>>>>
>>>>> I want to capture 50 Hz signal with sampling frequency not more than 2
>>>>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
>>>>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
>>>>> because it uses programmable PLL (CDCE913) to set the clock. I will
>>>>> have to do downsampling which I haven't figured out yet.
>>>
>>> Most probably I have missed some bits of important information, but from
>>> what I can see now, why wouldn't one would use a slow audio type of an
>>> ADC device and McASP to read samples digitized at exactly Fs = 2,000Hz?
>>>
>>> I think there are plenty of such devices out there on the market and
>>> they must be much cheaper to purchase, rather than more expensive
>>> speedy device of 20,000,000Hz sampling rate...
>>>
>>> Using a right device one wouldn't have to employ a numerically expensive
>>> downsampling procedure that has to apply a digital filter to remove
>>> 19,999 samples and free the CPU to perform other important tasks...
>>>
>>> Have I rally missed something?
>>>
>>> Rgds,
>>>
>>> Andrew

_____________________________________
Reply by Abdulmagid Omar ●January 17, 20132013-01-17
Hi;
If your objective is to capture the 50 Hz, all you need is (more or less) 0.5 cycle of the 50 Hz to get all the needed information of the 50Hz. Half cycle is defined by two consecutive zero crossings or positive peak followed by a negative peak (or negative followed by positive peak). This will reduce he buffer size needed.

Omar

--- On Wed, 1/9/13, B S wrote:

From: B S
Subject: Re: [c6x] Re: SWI vs. TSK
To: "Jeff Brower"
Cc: "c..."
Date: Wednesday, January 9, 2013, 5:41 AM

 

Hi,

Thanks for all your help. Unfortunately, I can't change the processor at this point so sticking with it is the only option. 

However, I appreciate your help with the following query.

If sampling at 200kHz then capturing 1024 point data takes (1/200k * 1024 = 5.12 mSec). This way I know i need atleast 4 buffer of size 1024 to capture a 50 Hz cycle. In my case it's DMA which transfers data to CPU and it always takes 17 CPU cycle. How would I know in this case that how much samples i need to get a 50 Hz cycle ?

Thanks.

From: Jeff Brower
To: B S
Cc: c...
Sent: Friday, January 4, 2013 6:32 AM
Subject: Re: [c6x] Re: SWI vs. TSK

 

BAS-

I know I mentioned this already... but... multicore.

One core could be doing decimation, another one your processing.

Check out C66x series. Cores share substantial onchip memory area. And all cores are floating-point.

-Jeff

>> Date: Thu, 3 Jan 2013 05:15:36 -0800 (PST)

>> From: B S

> Cc: Richard Williams

>> Subject: Re: [c6x] Re: SWI vs. TSK

>>

>> I could have taken your suggestion if I had an option to use McASP or slower

>> ADC. I have to use OMAP-L138 EVM with 20 MSPS ADC. One application of my

>> project is dealing with 1 MHz signal which make sense to use that ADC. I have

>> to deal with 50 Hz signal using the same device. Therefore, digital filtering

>> + decimation is the only solution i see right now.

>

> Let me assume Fs is 2MHz to get a 1MHz band. Then, if CPU rate is 300MHz, you

> get no more than 150 clocks to process a single sample in your 1MHz digitized

> signal.

>

> Then, you may have to downsample it to 1KHz band, then you just need to take

> one sample out of every 1,000, and filter out aliasing frequencies above 1KHz,

> that is between 1KHz and 2MHz. I guess this is going to be a long filter.

>

> I think you will have to use more CPUs and also split the analog input signal

> into 2 channels, one sampled at a high rate, the other at a slower rate. This

> would remove downsampling and antialiasing filter out from your system.

>

>> BTW, do you have any idea how could I implement decimation filter

>> (Butterworth or Chebyshev) in C ?

>

> I have seen a couple of windows programs on the net that design a digital

> filter. They calculate coefficients for either FIR or IIR filter type,

> whichever suits better for you system.

>

> Rgds,

> Andrew

>

>> From: Andrew Nesterov

> To: c...

>> Sent: Wednesday, January 2, 2013 10:56 PM

>> Subject: [c6x] Re: SWI vs. TSK

>>

>>

>> Hi B.S.,

>>

>>> ---------- Original Message -----------

>>> From: B S

>>>

>>>> I want to capture 50 Hz signal with sampling frequency not more than 2

>>>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has

>>>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate

>>>> because it uses programmable PLL (CDCE913) to set the clock. I will

>>>> have to do downsampling which I haven't figured out yet.

>>

>> Most probably I have missed some bits of important information, but from

>> what I can see now, why wouldn't one would use a slow audio type of an

>> ADC device and McASP to read samples digitized at exactly Fs = 2,000Hz?

>>

>> I think there are plenty of such devices out there on the market and

>> they must be much cheaper to purchase, rather than more expensive

>> speedy device of 20,000,000Hz sampling rate...

>>

>> Using a right device one wouldn't have to employ a numerically expensive

>> downsampling procedure that has to apply a digital filter to remove

>> 19,999 samples and free the CPU to perform other important tasks...

>>

>> Have I rally missed something?

>>

>> Rgds,

>>

>> Andrew
Reply by B S ●January 17, 20132013-01-17
Hi,

Thanks for all your help. Unfortunately, I can't change the processor at this point so sticking with it is the only option. 

However, I appreciate your help with the following query.

If sampling at 200kHz then capturing 1024 point data takes (1/200k * 1024 = 5.12 mSec). This way I know i need atleast 4 buffer of size 1024 to capture a 50 Hz cycle. In my case it's DMA which transfers data to CPU and it always takes 17 CPU cycle. How would I know in this case that how much samples i need to get a 50 Hz cycle ?

Thanks.

________________________________
From: Jeff Brower
To: B S
Cc: c...
Sent: Friday, January 4, 2013 6:32 AM
Subject: Re: [c6x] Re: SWI vs. TSK

 
BAS-

I know I mentioned this already... but... multicore.

One core could be doing decimation, another one your processing.

Check out C66x series. Cores share substantial onchip memory area. And all cores are floating-point.

-Jeff

>> Date: Thu, 3 Jan 2013 05:15:36 -0800 (PST)
>> From: B S
> Cc: Richard Williams
>> Subject: Re: [c6x] Re: SWI vs. TSK
>>
>> I could have taken your suggestion if I had an option to use McASP or slower
>> ADC. I have to use OMAP-L138 EVM with 20 MSPS ADC. One application of my
>> project is dealing with 1 MHz signal which make sense to use that ADC. I have
>> to deal with 50 Hz signal using the same device. Therefore, digital filtering
>> + decimation is the only solution i see right now.
>
> Let me assume Fs is 2MHz to get a 1MHz band. Then, if CPU rate is 300MHz, you
> get no more than 150 clocks to process a single sample in your 1MHz digitized
> signal.
>
> Then, you may have to downsample it to 1KHz band, then you just need to take
> one sample out of every 1,000, and filter out aliasing frequencies above 1KHz,
> that is between 1KHz and 2MHz. I guess this is going to be a long filter.
>
> I think you will have to use more CPUs and also split the analog input signal
> into 2 channels, one sampled at a high rate, the other at a slower rate. This
> would remove downsampling and antialiasing filter out from your system.
>
>> BTW, do you have any idea how could I implement decimation filter
>> (Butterworth or Chebyshev) in C ?
>
> I have seen a couple of windows programs on the net that design a digital
> filter. They calculate coefficients for either FIR or IIR filter type,
> whichever suits better for you system.
>
> Rgds,
> Andrew
>
>> From: Andrew Nesterov
> To: c...
>> Sent: Wednesday, January 2, 2013 10:56 PM
>> Subject: [c6x] Re: SWI vs. TSK
>> Hi B.S.,
>>
>>> ---------- Original Message -----------
>>> From: B S
>>>
>>>> I want to capture 50 Hz signal with sampling frequency not more than 2
>>>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
>>>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
>>>> because it uses programmable PLL (CDCE913) to set the clock. I will
>>>> have to do downsampling which I haven't figured out yet.
>>
>> Most probably I have missed some bits of important information, but from
>> what I can see now, why wouldn't one would use a slow audio type of an
>> ADC device and McASP to read samples digitized at exactly Fs = 2,000Hz?
>>
>> I think there are plenty of such devices out there on the market and
>> they must be much cheaper to purchase, rather than more expensive
>> speedy device of 20,000,000Hz sampling rate...
>>
>> Using a right device one wouldn't have to employ a numerically expensive
>> downsampling procedure that has to apply a digital filter to remove
>> 19,999 samples and free the CPU to perform other important tasks...
>>
>> Have I rally missed something?
>>
>> Rgds,
>>
>> Andrew
Reply by Jeff Brower ●January 4, 20132013-01-04
BAS-

I know I mentioned this already... but... multicore.

One core could be doing decimation, another one your processing.

Check out C66x series. Cores share substantial onchip memory area. And all cores are floating-point.

-Jeff

>> Date: Thu, 3 Jan 2013 05:15:36 -0800 (PST)
>> From: B S >> Cc: Richard Williams
>> Subject: Re: [c6x] Re: SWI vs. TSK
>>
>> I could have taken your suggestion if I had an option to use McASP or slower
>> ADC. I have to use OMAP-L138 EVM with 20 MSPS ADC. One application of my
>> project is dealing with 1 MHz signal which make sense to use that ADC. I have
>> to deal with 50 Hz signal using the same device. Therefore, digital filtering
>> + decimation is the only solution i see right now.
>
> Let me assume Fs is 2MHz to get a 1MHz band. Then, if CPU rate is 300MHz, you
> get no more than 150 clocks to process a single sample in your 1MHz digitized
> signal.
>
> Then, you may have to downsample it to 1KHz band, then you just need to take
> one sample out of every 1,000, and filter out aliasing frequencies above 1KHz,
> that is between 1KHz and 2MHz. I guess this is going to be a long filter.
>
> I think you will have to use more CPUs and also split the analog input signal
> into 2 channels, one sampled at a high rate, the other at a slower rate. This
> would remove downsampling and antialiasing filter out from your system.
>
>> BTW, do you have any idea how could I implement decimation filter
>> (Butterworth or Chebyshev) in C ?
>
> I have seen a couple of windows programs on the net that design a digital
> filter. They calculate coefficients for either FIR or IIR filter type,
> whichever suits better for you system.
>
> Rgds,
> Andrew
>
>> From: Andrew Nesterov >> To: c...
>> Sent: Wednesday, January 2, 2013 10:56 PM
>> Subject: [c6x] Re: SWI vs. TSK
>> Hi B.S.,
>>
>>> ---------- Original Message -----------
>>> From: B S >>>>
>>>> I want to capture 50 Hz signal with sampling frequency not more than 2
>>>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
>>>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
>>>> because it uses programmable PLL (CDCE913) to set the clock. I will
>>>> have to do downsampling which I haven't figured out yet.
>>
>> Most probably I have missed some bits of important information, but from
>> what I can see now, why wouldn't one would use a slow audio type of an
>> ADC device and McASP to read samples digitized at exactly Fs = 2,000Hz?
>>
>> I think there are plenty of such devices out there on the market and
>> they must be much cheaper to purchase, rather than more expensive
>> speedy device of 20,000,000Hz sampling rate...
>>
>> Using a right device one wouldn't have to employ a numerically expensive
>> downsampling procedure that has to apply a digital filter to remove
>> 19,999 samples and free the CPU to perform other important tasks...
>>
>> Have I rally missed something?
>>
>> Rgds,
>>
>> Andrew

_____________________________________
Reply by Andrew Nesterov ●January 3, 20132013-01-03
> Date: Thu, 3 Jan 2013 05:15:36 -0800 (PST)
> From: B S > Cc: Richard Williams
> Subject: Re: [c6x] Re: SWI vs. TSK
>
> I could have taken your suggestion if I had an option to use McASP or slower
> ADC. I have to use OMAP-L138 EVM with 20 MSPS ADC. One application of my
> project is dealing with 1 MHz signal which make sense to use that ADC. I have
> to deal with 50 Hz signal using the same device. Therefore, digital filtering
> + decimation is the only solution i see right now.

Let me assume Fs is 2MHz to get a 1MHz band. Then, if CPU rate is 300MHz, you
get no more than 150 clocks to process a single sample in your 1MHz digitized
signal.

Then, you may have to downsample it to 1KHz band, then you just need to take
one sample out of every 1,000, and filter out aliasing frequencies above 1KHz,
that is between 1KHz and 2MHz. I guess this is going to be a long filter.

I think you will have to use more CPUs and also split the analog input signal
into 2 channels, one sampled at a high rate, the other at a slower rate. This
would remove downsampling and antialiasing filter out from your system.

> BTW, do you have any idea how could I implement decimation filter
> (Butterworth or Chebyshev) in C ?

I have seen a couple of windows programs on the net that design a digital
filter. They calculate coefficients for either FIR or IIR filter type,
whichever suits better for you system.

Rgds,
Andrew

> From: Andrew Nesterov > To: c...
> Sent: Wednesday, January 2, 2013 10:56 PM
> Subject: [c6x] Re: SWI vs. TSK
> Hi B.S.,
>
>> ---------- Original Message -----------
>> From: B S >>>
>>> I want to capture 50 Hz signal with sampling frequency not more than 2
>>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
>>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
>>> because it uses programmable PLL (CDCE913) to set the clock. I will
>>> have to do downsampling which I haven't figured out yet.
>
> Most probably I have missed some bits of important information, but from
> what I can see now, why wouldn't one would use a slow audio type of an
> ADC device and McASP to read samples digitized at exactly Fs = 2,000Hz?
>
> I think there are plenty of such devices out there on the market and
> they must be much cheaper to purchase, rather than more expensive
> speedy device of 20,000,000Hz sampling rate...
>
> Using a right device one wouldn't have to employ a numerically expensive
> downsampling procedure that has to apply a digital filter to remove
> 19,999 samples and free the CPU to perform other important tasks...
>
> Have I rally missed something?
>
> Rgds,
>
> Andrew

_____________________________________
Reply by B S ●January 3, 20132013-01-03
Andrew,

I could have taken your suggestion if I had an option to use McASP or slower ADC. I have to use OMAP-L138 EVM with 20 MSPS ADC. One application of my project is dealing with 1 MHz signal which make sense to use that ADC. I have to deal with 50 Hz signal using the same device. Therefore, digital filtering + decimation is the only solution i see right now.

BTW, do you have any idea how could I implement decimation filter (Butterworth or Chebyshev) in C ?
Thanks.

BAS

________________________________
From: Andrew Nesterov
To: c...
Cc: B S ; Richard Williams
Sent: Wednesday, January 2, 2013 10:56 PM
Subject: [c6x] Re: SWI vs. TSK

 

Hi B.S.,

> ---------- Original Message -----------
> From: B S
>>
>> I want to capture 50 Hz signal with sampling frequency not more than 2
>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
>> because it uses programmable PLL (CDCE913) to set the clock. I will
>> have to do downsampling which I haven't figured out yet.

Most probably I have missed some bits of important information, but from
what I can see now, why wouldn't one would use a slow audio type of an
ADC device and McASP to read samples digitized at exactly Fs = 2,000Hz?

I think there are plenty of such devices out there on the market and
they must be much cheaper to purchase, rather than more expensive
speedy device of 20,000,000Hz sampling rate...

Using a right device one wouldn't have to employ a numerically expensive
downsampling procedure that has to apply a digital filter to remove
19,999 samples and free the CPU to perform other important tasks...

Have I rally missed something?

Rgds,

Andrew
Reply by Andrew Nesterov ●January 2, 20132013-01-02
Hi B.S.,

> ---------- Original Message -----------
> From: B S
>>
>> I want to capture 50 Hz signal with sampling frequency not more than 2
>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
>> because it uses programmable PLL (CDCE913) to set the clock. I will
>> have to do downsampling which I haven't figured out yet.

Most probably I have missed some bits of important information, but from
what I can see now, why wouldn't one would use a slow audio type of an
ADC device and McASP to read samples digitized at exactly Fs = 2,000Hz?

I think there are plenty of such devices out there on the market and
they must be much cheaper to purchase, rather than more expensive
speedy device of 20,000,000Hz sampling rate...

Using a right device one wouldn't have to employ a numerically expensive
downsampling procedure that has to apply a digital filter to remove
19,999 samples and free the CPU to perform other important tasks...

Have I rally missed something?

Rgds,

Andrew

_____________________________________
Reply by Richard Williams ●January 1, 20132013-01-01
B.S.

I'm thinking that sampling cannot be slowed further.

Therefore,
how make each 'row' the count of division needed to reduce sampling rate to ~2khx.
have a row count the same as the number of samples that you actually want to
look at at each processing event.

have the end of row interrupt move the last entry in the current row to the
related entry in the buffer to be processed.
When all rows are filled, have the resulting interrupt trigger a software
interrupt to perform the processing.
and re-start the capture at the first row.

The above is a method to (effectively) reduce the rate of data that is to be
processed.

I.E. if 512 entries are to be processed at a time,
then
--setup 512 entry rows
--allocate a processing buffer of 512 entries

(If you implement double buffering using 512 entry processing buffers,
Then you can double the available time to process a single buffer.)

The End of row interrupt moves 1 entry from the current row to the processing
buffer{row number]
The End of sequence interrupt triggers the software interrupt

The interrupts are never disabled.

(with double buffering, the end of sequence buffer will also swap which
processing buffer is currently receiving data at the end of line interrupts and
which processing buffer is being processed by the software interrupt.)

R. Williams

---------- Original Message -----------
From: B S
To: Richard Williams , "c..."

Sent: Mon, 31 Dec 2012 06:55:11 -0800 (PST)
Subject: Re: [c6x] SWI vs. TSK

> R. Williams,
>
> I want to capture 50 Hz signal with sampling frequency not more than 2
> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
> because it uses programmable PLL (CDCE913) to set the clock. I will
> have to do downsampling which I haven't figured out yet.
>
> CDCE913 Data sheet. Page 17, Table 10 shows register PDIV which is a
> divider to set the sampling rate. Minimum value can be used is 127
> dec. Fig 6 shows the default configuration.
http://www.ti.com/lit/ds/scas849e/scas849e.pdf
>
> As mentioned earlier, Universal Parallel Port (uPP) is used to get the
> data from ADS901. All uPP transactions use the internal DMA to feed
> data to or retrieve data from the I/O channels. I am not separately
> programming any DMA register, only setting uPP to get the data from
> ADC.
>
> More information about uPP can be found here:
> http://processors.wiki.ti.com/index.php/Introduction_to_uPP
>
> Attached is uPP register settings to show you how it is working;
>
>     //UPCTL
>     config.UPCTL.value=0;
>     config.UPCTL.bits.DPFA = 0;
>     config.UPCTL.bits.DPWA = 2;
>     config.UPCTL.bits.IWA = 1;
>     config.UPCTL.bits.CHN = 1;                //dual
> channel mode     config.UPCTL.bits.MODE = 0;           
> //0 all recv, 1 all xmit, 2 a recv b xmit, 3 a xmit b recv, Channel A
> ADC, Channel B DAC                            
>           
>
>     //UPICR
>     config.UPICR.value=0;
>    
>     //UPIVR
>     config.UPIVR.value=0;
>
>     //UPTCR
>     config.UPTCR.value=0;                //all values 0
> for 64byte DMA bursts read / write
>
>     //UPDLB
>     config.UPDLB.value=0;                //no
> loopback               
>
>     //UPIES                           
>     config.UPIES.value=0;                    //dont
> enable any interrupts     config.UPIES.bits.EOWI= 1;        
>   //turn on EOW(end of window)interrupt for CHA(DMA channel I)    
>     //UPPCR     config.UPPCR.value = 0;           
>         config.UPPCR.bits.EN = 1;               
> //enable uPP     config.UPPCR.bits.RTEMU = 1;        //allow
> emulator use     config.UPPCR.bits.SOFT = 1;           
> //allow emulation
>
> Once uPP peripheral is initialized, DMA registers can be programmed to
> get the data.
>
> Given below is uPP DMA register settings which writes data to recv_buffer.
>
>     UPP->UPID0 = (uint32_t)&recv_buffer;    //add next DMA transfer
>     UPP->UPID1 = 0x00010800;                    
> //1 lines 2048 bytes per line     UPP->UPID2 = 0x00000800; 
>
> As soon as end of window interrupt (EOWI) triggers (after collecting
> 1024 point), ISR is called where I disabled interrupt and process the
> buffer. ISR code snippet can be seen below.
>
> void isrUPP(void)
> {
>  
>    UPISR_t interrupt_status;
>   interrupt_status.value = UPP->UPIER;
>   
>   while (interrupt_status.value != 0)
>   {
>      
>       if (interrupt_status.bits.EOWI)
>     {
>         UPP->UPIER |= ~(0x08);               
>         // clear EOWI bit in UPIER         // Handle EOWI
>      }
>
>     // loop again if any interrupts are left
>     interrupt_status.value = UPP->UPIER;
>   } // end of while
>  
>   // write end of interrupt vector to allow future calls
>       UPP->UPEOI = 0;
>   
> } // end of function
>
> My problem is fundamental i.e., filling of buffer is faster than
> processing it which can be solved either by slowing down the sampling
> rate or using a faster DSP. Slowing down the sampling rate deoesn't
> help either because uPP transfer is not directly related to sampling
> rate. I tried transfering different data sizes e.g. 64, 128 or 1024
> point but it takes only 17 CPU cycle make the transfer.
>
> Reducing the uPP transfer rate might help but I don't know how to do
> that. Please guide me If you have any idea.
>
> I hope i have explained every thing concerning my problems.
>
> Apart from simple downsampling, I would like to know other efficient
> way to capture 50 Hz signal using current ADC configuration ?
>
> Regards,
> BAS
>
> ________________________________
> From: Richard Williams
> To: B S ; "c..."
> Sent: Thursday, December 20, 2012 11:06 PM
> Subject: Re: [c6x] SWI vs. TSK
>
>  
> B.S.
>
> I think we have covered this ground previously.
>
> First I have a question.
> What is the highest frequency that you want to capture?
>
> Second, you how how long it takes to process a buffer. Therefore, the
> sample rate MUST be slow enough to take longer than the processing time.
>
> Third, to maximize the through put.
> 1) use the EDMA to perform all the input/output to/from buffers.
> 2) have the EDMA trigger an interrupt when a input buffer is full.
> 3) have the interrupt processing only do a couple of things:
> --switch which input buffer is 'active'
> --trigger a software interrupt to perform the actual processing
> --clear the interrupt pending flag
>
> I have pointed you toward examples on how to setup the sampling, the
> EDMA, the hardware interrupt processing and the software interrupt
> processing and how to setup and handle double buffering for both the
> input and the output; there is little more that I can do.
>
> I doubt will be able to help you further without the following file
> and code snip-its: --*.con file (linker control file)/ --the input
> sampling setup/ --the EDMA peripheral setup/ --the hardware interrupt processing/
> --the software interrupt processing
> --and some parameters about the incoming data characteristics
>
> R. Williams
>
> ---------- Original Message -----------
> From: B S
> To: Richard Williams , "c..."
>
> Sent: Thu, 20 Dec 2012 06:17:31 -0800 (PST)
> Subject: Re: [c6x] SWI vs. TSK
>
> > R. Williams,
> >
> > I applied optimization but it is still taking over 1 millisecond time
> > to process the data. I think it's impossible to cut down the
> > processing time to even some millisecond scale, nanosecond is out the
> > question. I wonder any device using DMA will make the faster so fast,
> > does that mean real-time is not possible for all of them ?
> >
> > If I have to live with this fact, what efficient way can be used to
> > capture and processing simultaneously ?
> >
> > Thanks.
> >
> > ________________________________
> > From: Richard Williams
> > To: B S ; "c..."
> > Sent: Thursday, December 6, 2012 11:07 PM
> > Subject: Re: [c6x] SWI vs. TSK
> >
> >  
> > B.S.
> >
> > Here is a reference to the TI document on optimization of C code for
> > the C6000 DSP family.
> >
> > sprabf2.pdf
> >
> > Found at: http://www.ti.com/product/tms320dm648
> >
> > R. Williams
> >
> > ---------- Original Message -----------
> > From: B S
> > To: Richard Williams , "c..."
> >
> > Sent: Tue, 4 Dec 2012 01:42:59 -0800 (PST)
> > Subject: Re: [c6x] SWI vs. TSK
> >
> > > Richard,
> > >
> > > Thanks a lot for your valuable suggestions. I will try optimization to
> > > reduce the time span.
> > >
> > > I still don't understand how PING/PONG will solve my problem if the
> > > processing time is more than capturing time.
> > >
> > > If I post a semaphore to TASK when the buffer is filled to process it
> > > and pend on such a semaphore and not posting another semaphore untill
> > > processing is completed, should synchronise the processing though with
> > > some delay ? Is this correct idea of posting and pending a semaphore ?
> > > Correct me if I am wrong.
> > >
> > > I am already creating a TSK to initialize the UPP and exiting main to
> > > handover the control to TSK, whenever interrupt is fired, it is
> > > executing ISR. Is it Okay to post another TSK inside hwi ISR for
> > > buffer processing ?
> > >
> > > Thanks.
> > >
> > > ________________________________
> > > From: Richard Williams
> > > To: B S ; "c..."
> > > Sent: Thursday, November 29, 2012 11:41 PM
> > > Subject: Re: [c6x] SWI vs. TSK
> > >
> > >  
> > >
> > > B.S.
> > >
> > > using the EDMA3 peripheral, no cpu cycles need be expended for I/O
> > >
> > > You could link the EDMA chains so ping/pong is operational for both
> > > the input and the output data flows.
> > >
> > > You could make sure that no external memory is accessed. I.E. use
> > > L1P/L1D and L2 memory only with part of each L1/L2 allocated for cache
> > > operations.
> > >
> > > You could make sure that all data accesses (by the cpu/program are
> > > aligned on a 64bit boundary (8 byte boundary).
> > >
> > > You could make sure only single precision float values are being used
> > > in all calculations.
> > >
> > > You could make sure the 6ALUs are always kept busy such that there are
> > > no execution pipe stalls.
> > >
> > > You could up the Vcc voltage to 1.3v and then up the CPU clock to
> > > 456MHz if you have the appropriate version of the 6748 DSP
> > >
> > > extensive use of the built-in SPLOOP buffer can/will greatly reduce the
> > > execution time of the code.
> > >
> > > You could make sure the code makes max use of the 'compact'
> > > instructions for heavily executed code sequences.
> > >
> > > You could make sure that heavily executed code sequences are all on
> > > the same page of memory.
> > >
> > > ---------- Original Message -----------
> > > From: B S
> > > To: Richard Williams , "c..."
> > >
> > > Sent: Thu, 29 Nov 2012 06:01:52 -0800 (PST)
> > > Subject: Re: [c6x] SWI vs. TSK
> > >
> > > > Thanks all for your suggestions.
> > > >
> > > > I am using C6748 with uPP to capture data from ADC which is sampling
> > > > at 4.5 MSPS. Processing algorithm which compute only FFT at the moment
> > > > is taking 1.2 millisecond. I used TSC register to benchmark uPP data
> > > > transfer. uPP takes only 17 CPU cycle (17 * 1/300 MHz) to capture 1024
> > > > point of data. I tried to increase the size of buffer but it takes the
> > > > same amount of time to capture X size of buffer, perhaps the reason is
> > > > that, it uses DMA to move data but I am not sure. I think it's
> > > > impossible to accomplish FFT processing in some nanosecond duration
> > > > even with highly optimized code. I simply want to maintain a
> > > > continuous capturing and processing of incoming data, if some
> > > > conditions met over the captured data, save those data points to
> > > > permanent memory.
> > > >
> > > > Hope this helps.
> > > >
> > > > ________________________________
> > > > From: Richard Williams
> > > > To: B S ; "c..."
> > > > Sent: Monday, November 26, 2012 4:54 AM Subject:
> > > > Re: [c6x] SWI vs. TSK
> > > >
> > > > B.S.
> > > >
> > > > In general:
> > > >
> > > > It is almost always best practice to have the hardware interrupt
> > > > routine trigger the SWI, where the SWI performs the actual processing.
> > > >
> > > > There are three things that I would recommend for allowing the
> > > > processing of the data to stay ahead of the data capture.
> > > >
> > > > Double buffering helps immensely as then the older buffer of data can
> > > > be processed while the newer buffer of data is being captured..
> > > >
> > > > For your case of the processing taking longer than the capture of the data.
> > > >
> > > > 1) reduce the capture rate
> > > > 2) improve the algorithm and coding of the processing so it takes less
> > > > time to process a buffer of data.
> > > >
> > > > I cannot give more specific guidance without knowing your application
> > > > and the algorithm you are using.
> > > >
> > > > If you are willing to divulge that information (application and
> > > > algorithm), then I can assist your further.
> > > >
> > > > R. Williams
> > > >
> > > > ---------- Original Message -----------
> > > > From: B S
> > > > To: "c..."
> > > > Sent: Wed, 21 Nov 2012 07:54:35 -0800 (PST)
> > > > Subject: [c6x] SWI vs. TSK
> > > >
> > > > > Hi,
> > > > > How to maintain a real-time when time to fill a buffer is shorter than
> > > > > processing it ? I want to use PING PONG case to maintain real-time but
> > > > > don't understand how should I do it because in my application, time to
> > > > > fill the buffer is shorter than processing it. In this case, should I
> > > > > restrict HWI to trigger about the same time which is required to
> > > > > process it ?
> > > > >
> > > > > I would appreciate if you help me understaing when TSK or SWI should
> > > > > be used ?
> > > > >
> > > > > According to DSP/BIOS user guide, SWI runs untill its completion. Does
> > > > > that mean, there will be no HWI untill SWI ISR will be executed ?
> > > > >
> > > > > Thanks.
> > > > ------- End of Original Message -------
> > > ------- End of Original Message -------
> > ------- End of Original Message -------
> ------- End of Original Message -------
------- End of Original Message -------

_____________________________________
Reply by B S ●January 1, 20132013-01-01
R. Williams,

I want to capture 50 Hz signal with sampling frequency not more than 2 kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate because it uses programmable PLL (CDCE913) to set the clock. I will have to do downsampling which I haven't figured out yet.

CDCE913 Data sheet. Page 17, Table 10 shows register PDIV which is a divider to set the sampling rate. Minimum value can be used is 127 dec. Fig 6 shows the default configuration.
http://www.ti.com/lit/ds/scas849e/scas849e.pdf

As mentioned earlier, Universal Parallel Port (uPP) is used to get the data from ADS901. All uPP transactions use the internal DMA to feed data to or retrieve data from the I/O channels. I am not separately programming any DMA register, only setting uPP to get the data from ADC.

More information about uPP can be found here:
http://processors.wiki.ti.com/index.php/Introduction_to_uPP

Attached is uPP register settings to show you how it is working;

    //UPCTL
    config.UPCTL.value=0;
    config.UPCTL.bits.DPFA = 0;
    config.UPCTL.bits.DPWA = 2;
    config.UPCTL.bits.IWA = 1;
    config.UPCTL.bits.CHN = 1;                //dual channel mode
    config.UPCTL.bits.MODE = 0;            //0 all recv, 1 all xmit, 2 a recv b xmit, 3 a xmit b recv, Channel A ADC, Channel B DAC
                                      

    //UPICR
    config.UPICR.value=0;
   
    //UPIVR
    config.UPIVR.value=0;

    //UPTCR
    config.UPTCR.value=0;                //all values 0 for 64byte DMA bursts read / write

    //UPDLB
    config.UPDLB.value=0;                //no loopback               

    //UPIES                           
    config.UPIES.value=0;                    //dont enable any interrupts
    config.UPIES.bits.EOWI= 1;           //turn on EOW(end of window)interrupt for CHA(DMA channel I)
   
    //UPPCR
    config.UPPCR.value = 0;               
    config.UPPCR.bits.EN = 1;                //enable uPP
    config.UPPCR.bits.RTEMU = 1;        //allow emulator use
    config.UPPCR.bits.SOFT = 1;            //allow emulation

Once uPP peripheral is initialized, DMA registers can be programmed to get the data.

Given below is uPP DMA register settings which writes data to recv_buffer.

    UPP->UPID0 = (uint32_t)&recv_buffer;    //add next DMA transfer
    UPP->UPID1 = 0x00010800;                     //1 lines 2048 bytes per line
    UPP->UPID2 = 0x00000800; 

As soon as end of window interrupt (EOWI) triggers (after collecting 1024 point), ISR is called where I disabled interrupt and process the buffer. ISR code snippet can be seen below.

void isrUPP(void)
{
 
   UPISR_t interrupt_status;
  interrupt_status.value = UPP->UPIER;
  
  while (interrupt_status.value != 0)
  {
     
      if (interrupt_status.bits.EOWI)
    {
        UPP->UPIER |= ~(0x08);                        // clear EOWI bit in UPIER
        // Handle EOWI
     }

    // loop again if any interrupts are left
    interrupt_status.value = UPP->UPIER;
  } // end of while
 
  // write end of interrupt vector to allow future calls
      UPP->UPEOI = 0;
  
} // end of function

My problem is fundamental i.e., filling of buffer is faster than processing it which can be solved either by slowing down the sampling rate or using a faster DSP. Slowing down the sampling rate deoesn't help either because uPP transfer is not directly related to sampling rate. I tried transfering different data sizes e.g. 64, 128 or 1024 point but it takes only 17 CPU cycle make the transfer.

Reducing the uPP transfer rate might help but I don't know how to do that. Please guide me If you have any idea.

I hope i have explained every thing concerning my problems.

Apart from simple downsampling, I would like to know other efficient way to capture 50 Hz signal using current ADC configuration ?

Regards,
BAS

________________________________
From: Richard Williams
To: B S ; "c..."
Sent: Thursday, December 20, 2012 11:06 PM
Subject: Re: [c6x] SWI vs. TSK

 
B.S.

I think we have covered this ground previously.

First I have a question.
What is the highest frequency that you want to capture?

Second, you how how long it takes to process a buffer. Therefore, the sample
rate MUST be slow enough to take longer than the processing time.

Third, to maximize the through put.
1) use the EDMA to perform all the input/output to/from buffers.
2) have the EDMA trigger an interrupt when a input buffer is full.
3) have the interrupt processing only do a couple of things:
--switch which input buffer is 'active'
--trigger a software interrupt to perform the actual processing
--clear the interrupt pending flag

I have pointed you toward examples on how to setup the sampling, the EDMA, the
hardware interrupt processing and the software interrupt processing and how to
setup and handle double buffering for both the input and the output; there is
little more that I can do.

I doubt will be able to help you further without the following file and code
snip-its:
--*.con file (linker control file)/
--the input sampling setup/
--the EDMA peripheral setup/
--the hardware interrupt processing/
--the software interrupt processing
--and some parameters about the incoming data characteristics

R. Williams

---------- Original Message -----------
From: B S
To: Richard Williams , "c..."

Sent: Thu, 20 Dec 2012 06:17:31 -0800 (PST)
Subject: Re: [c6x] SWI vs. TSK

> R. Williams,
>
> I applied optimization but it is still taking over 1 millisecond time
> to process the data. I think it's impossible to cut down the
> processing time to even some millisecond scale, nanosecond is out the
> question. I wonder any device using DMA will make the faster so fast,
> does that mean real-time is not possible for all of them ?
>
> If I have to live with this fact, what efficient way can be used to
> capture and processing simultaneously ?
>
> Thanks.
>
> ________________________________
> From: Richard Williams
> To: B S ; "c..."
> Sent: Thursday, December 6, 2012 11:07 PM
> Subject: Re: [c6x] SWI vs. TSK
>
>  
> B.S.
>
> Here is a reference to the TI document on optimization of C code for
> the C6000 DSP family.
>
> sprabf2.pdf
>
> Found at: http://www.ti.com/product/tms320dm648
>
> R. Williams
>
> ---------- Original Message -----------
> From: B S
> To: Richard Williams , "c..."
>
> Sent: Tue, 4 Dec 2012 01:42:59 -0800 (PST)
> Subject: Re: [c6x] SWI vs. TSK
>
> > Richard,
> >
> > Thanks a lot for your valuable suggestions. I will try optimization to
> > reduce the time span.
> >
> > I still don't understand how PING/PONG will solve my problem if the
> > processing time is more than capturing time.
> >
> > If I post a semaphore to TASK when the buffer is filled to process it
> > and pend on such a semaphore and not posting another semaphore untill
> > processing is completed, should synchronise the processing though with
> > some delay ? Is this correct idea of posting and pending a semaphore ?
> > Correct me if I am wrong.
> >
> > I am already creating a TSK to initialize the UPP and exiting main to
> > handover the control to TSK, whenever interrupt is fired, it is
> > executing ISR. Is it Okay to post another TSK inside hwi ISR for
> > buffer processing ?
> >
> > Thanks.
> >
> > ________________________________
> > From: Richard Williams
> > To: B S ; "c..."
> > Sent: Thursday, November 29, 2012 11:41 PM
> > Subject: Re: [c6x] SWI vs. TSK
> >
> >  
> >
> > B.S.
> >
> > using the EDMA3 peripheral, no cpu cycles need be expended for I/O
> >
> > You could link the EDMA chains so ping/pong is operational for both
> > the input and the output data flows.
> >
> > You could make sure that no external memory is accessed. I.E. use
> > L1P/L1D and L2 memory only with part of each L1/L2 allocated for cache
> > operations.
> >
> > You could make sure that all data accesses (by the cpu/program are
> > aligned on a 64bit boundary (8 byte boundary).
> >
> > You could make sure only single precision float values are being used
> > in all calculations.
> >
> > You could make sure the 6ALUs are always kept busy such that there are
> > no execution pipe stalls.
> >
> > You could up the Vcc voltage to 1.3v and then up the CPU clock to
> > 456MHz if you have the appropriate version of the 6748 DSP
> >
> > extensive use of the built-in SPLOOP buffer can/will greatly reduce the
> > execution time of the code.
> >
> > You could make sure the code makes max use of the 'compact'
> > instructions for heavily executed code sequences.
> >
> > You could make sure that heavily executed code sequences are all on
> > the same page of memory.
> >
> > ---------- Original Message -----------
> > From: B S
> > To: Richard Williams , "c..."
> >
> > Sent: Thu, 29 Nov 2012 06:01:52 -0800 (PST)
> > Subject: Re: [c6x] SWI vs. TSK
> >
> > > Thanks all for your suggestions.
> > >
> > > I am using C6748 with uPP to capture data from ADC which is sampling
> > > at 4.5 MSPS. Processing algorithm which compute only FFT at the moment
> > > is taking 1.2 millisecond. I used TSC register to benchmark uPP data
> > > transfer. uPP takes only 17 CPU cycle (17 * 1/300 MHz) to capture 1024
> > > point of data. I tried to increase the size of buffer but it takes the
> > > same amount of time to capture X size of buffer, perhaps the reason is
> > > that, it uses DMA to move data but I am not sure. I think it's
> > > impossible to accomplish FFT processing in some nanosecond duration
> > > even with highly optimized code. I simply want to maintain a
> > > continuous capturing and processing of incoming data, if some
> > > conditions met over the captured data, save those data points to
> > > permanent memory.
> > >
> > > Hope this helps.
> > >
> > > ________________________________
> > > From: Richard Williams
> > > To: B S ; "c..."
> > > Sent: Monday, November 26, 2012 4:54 AM Subject:
> > > Re: [c6x] SWI vs. TSK
> > >
> > > B.S.
> > >
> > > In general:
> > >
> > > It is almost always best practice to have the hardware interrupt
> > > routine trigger the SWI, where the SWI performs the actual processing.
> > >
> > > There are three things that I would recommend for allowing the
> > > processing of the data to stay ahead of the data capture.
> > >
> > > Double buffering helps immensely as then the older buffer of data can
> > > be processed while the newer buffer of data is being captured..
> > >
> > > For your case of the processing taking longer than the capture of the data.
> > >
> > > 1) reduce the capture rate
> > > 2) improve the algorithm and coding of the processing so it takes less
> > > time to process a buffer of data.
> > >
> > > I cannot give more specific guidance without knowing your application
> > > and the algorithm you are using.
> > >
> > > If you are willing to divulge that information (application and
> > > algorithm), then I can assist your further.
> > >
> > > R. Williams
> > >
> > > ---------- Original Message -----------
> > > From: B S
> > > To: "c..."
> > > Sent: Wed, 21 Nov 2012 07:54:35 -0800 (PST)
> > > Subject: [c6x] SWI vs. TSK
> > >
> > > > Hi,
> > > > How to maintain a real-time when time to fill a buffer is shorter than
> > > > processing it ? I want to use PING PONG case to maintain real-time but
> > > > don't understand how should I do it because in my application, time to
> > > > fill the buffer is shorter than processing it. In this case, should I
> > > > restrict HWI to trigger about the same time which is required to
> > > > process it ?
> > > >
> > > > I would appreciate if you help me understaing when TSK or SWI should
> > > > be used ?
> > > >
> > > > According to DSP/BIOS user guide, SWI runs untill its completion. Does
> > > > that mean, there will be no HWI untill SWI ISR will be executed ?
> > > >
> > > > Thanks.
> > > ------- End of Original Message -------
> > ------- End of Original Message -------
> ------- End of Original Message -------
------- End of Original Message -------
Reply by Jeff Brower ●January 1, 20132013-01-01
B.S.-

You can look into the EVM6678 card. This has 8 cores running at 1.2 GHz each, which could reduce your processing time
by 8x compared to where you're at now... actually even more since the C6678 can do more multiply-accumulate per clock
cycle.

Of course this assumes your algorithm can be parallelized; i.e. split across cores in an efficient way.

And, there is always the issue of A/D daughtercard. You may have to do some interface logic -- but that's a good
problem to have, compared to lack of compute-intensive processing performance.

-Jeff

> B.S.,
>
> It seems you are using a very high speed device, Where the number of words
> transferred is in the 2 or more million words per second.
>
> That is WAY to high a rate peripheral for what you want to do.
>
> I suggest you either re-think the hardware or re-think the application.
>
> For the data sample rates that you are interested in, for this defined application,
> I would suggest a TMS320C6713 DSK or TMS320C6416 DSK with the appropriate
> daughter card A/D daughter card.
>
> There is the possibility of using a slow enough external clock source for the
> A/D peripheral/uPP peripheral, but I would expect clock slew problems from the
> very slow clock would make the application unstable.
>
> R. Williams
> ---------- Original Message -----------
> From: B S
> To: Richard Williams , "c..."
>
> Sent: Mon, 31 Dec 2012 06:55:11 -0800 (PST)
> Subject: Re: [c6x] SWI vs. TSK
>
>> R. Williams,
>>
>> I want to capture 50 Hz signal with sampling frequency not more than 2
>> kHz. I am using OMAP-L138 EVM with has ADS901 attached with it. It has
>> sampling rate 20 MSPS, I can't get less than 212.60 kHz sampling rate
>> because it uses programmable PLL (CDCE913) to set the clock. I will
>> have to do downsampling which I haven't figured out yet.
>>
>> CDCE913 Data sheet. Page 17, Table 10 shows register PDIV which is a
>> divider to set the sampling rate. Minimum value can be used is 127
>> dec. Fig 6 shows the default configuration.
> http://www.ti.com/lit/ds/scas849e/scas849e.pdf
>>
>> As mentioned earlier, Universal Parallel Port (uPP) is used to get the
>> data from ADS901. All uPP transactions use the internal DMA to feed
>> data to or retrieve data from the I/O channels. I am not separately
>> programming any DMA register, only setting uPP to get the data from
>> ADC.
>>
>> More information about uPP can be found here:
>> http://processors.wiki.ti.com/index.php/Introduction_to_uPP
>>
>> Attached is uPP register settings to show you how it is working;
>>
>>     //UPCTL
>>     config.UPCTL.value=0;
>>     config.UPCTL.bits.DPFA = 0;
>>     config.UPCTL.bits.DPWA = 2;
>>     config.UPCTL.bits.IWA = 1;
>>     config.UPCTL.bits.CHN = 1;                //dual
>> channel mode     config.UPCTL.bits.MODE = 0;           
>> //0 all recv, 1 all xmit, 2 a recv b xmit, 3 a xmit b recv, Channel A
>> ADC, Channel B DAC                            
>>           
>>
>>     //UPICR
>>     config.UPICR.value=0;
>>    
>>     //UPIVR
>>     config.UPIVR.value=0;
>>
>>     //UPTCR
>>     config.UPTCR.value=0;                //all values 0
>> for 64byte DMA bursts read / write
>>
>>     //UPDLB
>>     config.UPDLB.value=0;                //no
>> loopback               
>>
>>     //UPIES                           
>>     config.UPIES.value=0;                    //dont
>> enable any interrupts     config.UPIES.bits.EOWI= 1;        
>>   //turn on EOW(end of window)interrupt for CHA(DMA channel I)    
>>     //UPPCR     config.UPPCR.value = 0;           
>>         config.UPPCR.bits.EN = 1;               
>> //enable uPP     config.UPPCR.bits.RTEMU = 1;        //allow
>> emulator use     config.UPPCR.bits.SOFT = 1;           
>> //allow emulation
>>
>> Once uPP peripheral is initialized, DMA registers can be programmed to
>> get the data.
>>
>> Given below is uPP DMA register settings which writes data to recv_buffer.
>>
>>     UPP->UPID0 = (uint32_t)&recv_buffer;    //add next DMA transfer
>>     UPP->UPID1 = 0x00010800;                    
>> //1 lines 2048 bytes per line     UPP->UPID2 = 0x00000800; 
>>
>> As soon as end of window interrupt (EOWI) triggers (after collecting
>> 1024 point), ISR is called where I disabled interrupt and process the
>> buffer. ISR code snippet can be seen below.
>>
>> void isrUPP(void)
>> {
>>  
>>    UPISR_t interrupt_status;
>>   interrupt_status.value = UPP->UPIER;
>>   
>>   while (interrupt_status.value != 0)
>>   {
>>      
>>       if (interrupt_status.bits.EOWI)
>>     {
>>         UPP->UPIER |= ~(0x08);               
>>         // clear EOWI bit in UPIER         // Handle EOWI
>>      }
>>
>>     // loop again if any interrupts are left
>>     interrupt_status.value = UPP->UPIER;
>>   } // end of while
>>  
>>   // write end of interrupt vector to allow future calls
>>       UPP->UPEOI = 0;
>>   
>> } // end of function
>>
>> My problem is fundamental i.e., filling of buffer is faster than
>> processing it which can be solved either by slowing down the sampling
>> rate or using a faster DSP. Slowing down the sampling rate deoesn't
>> help either because uPP transfer is not directly related to sampling
>> rate. I tried transfering different data sizes e.g. 64, 128 or 1024
>> point but it takes only 17 CPU cycle make the transfer.
>>
>> Reducing the uPP transfer rate might help but I don't know how to do
>> that. Please guide me If you have any idea.
>>
>> I hope i have explained every thing concerning my problems.
>>
>> Apart from simple downsampling, I would like to know other efficient
>> way to capture 50 Hz signal using current ADC configuration ?
>>
>> Regards,
>> BAS
>>
>> ________________________________
>> From: Richard Williams
>> To: B S ; "c..."
>> Sent: Thursday, December 20, 2012 11:06 PM
>> Subject: Re: [c6x] SWI vs. TSK
>>
>>  
>> B.S.
>>
>> I think we have covered this ground previously.
>>
>> First I have a question.
>> What is the highest frequency that you want to capture?
>>
>> Second, you how how long it takes to process a buffer. Therefore, the
>> sample rate MUST be slow enough to take longer than the processing time.
>>
>> Third, to maximize the through put.
>> 1) use the EDMA to perform all the input/output to/from buffers.
>> 2) have the EDMA trigger an interrupt when a input buffer is full.
>> 3) have the interrupt processing only do a couple of things:
>> --switch which input buffer is 'active'
>> --trigger a software interrupt to perform the actual processing
>> --clear the interrupt pending flag
>>
>> I have pointed you toward examples on how to setup the sampling, the
>> EDMA, the hardware interrupt processing and the software interrupt
>> processing and how to setup and handle double buffering for both the
>> input and the output; there is little more that I can do.
>>
>> I doubt will be able to help you further without the following file
>> and code snip-its: --*.con file (linker control file)/ --the input
>> sampling setup/ --the EDMA peripheral setup/ --the hardware interrupt processing/
>> --the software interrupt processing
>> --and some parameters about the incoming data characteristics
>>
>> R. Williams
>>
>> ---------- Original Message -----------
>> From: B S
>> To: Richard Williams , "c..."
>>
>> Sent: Thu, 20 Dec 2012 06:17:31 -0800 (PST)
>> Subject: Re: [c6x] SWI vs. TSK
>>
>> > R. Williams,
>> >
>> > I applied optimization but it is still taking over 1 millisecond time
>> > to process the data. I think it's impossible to cut down the
>> > processing time to even some millisecond scale, nanosecond is out the
>> > question. I wonder any device using DMA will make the faster so fast,
>> > does that mean real-time is not possible for all of them ?
>> >
>> > If I have to live with this fact, what efficient way can be used to
>> > capture and processing simultaneously ?
>> >
>> > Thanks.
>> >
>> > ________________________________
>> > From: Richard Williams
>> > To: B S ; "c..."
>> > Sent: Thursday, December 6, 2012 11:07 PM
>> > Subject: Re: [c6x] SWI vs. TSK
>> >
>> >  
>> > B.S.
>> >
>> > Here is a reference to the TI document on optimization of C code for
>> > the C6000 DSP family.
>> >
>> > sprabf2.pdf
>> >
>> > Found at: http://www.ti.com/product/tms320dm648
>> >
>> > R. Williams
>> >
>> > ---------- Original Message -----------
>> > From: B S
>> > To: Richard Williams , "c..."
>> >
>> > Sent: Tue, 4 Dec 2012 01:42:59 -0800 (PST)
>> > Subject: Re: [c6x] SWI vs. TSK
>> >
>> > > Richard,
>> > >
>> > > Thanks a lot for your valuable suggestions. I will try optimization to
>> > > reduce the time span.
>> > >
>> > > I still don't understand how PING/PONG will solve my problem if the
>> > > processing time is more than capturing time.
>> > >
>> > > If I post a semaphore to TASK when the buffer is filled to process it
>> > > and pend on such a semaphore and not posting another semaphore untill
>> > > processing is completed, should synchronise the processing though with
>> > > some delay ? Is this correct idea of posting and pending a semaphore ?
>> > > Correct me if I am wrong.
>> > >
>> > > I am already creating a TSK to initialize the UPP and exiting main to
>> > > handover the control to TSK, whenever interrupt is fired, it is
>> > > executing ISR. Is it Okay to post another TSK inside hwi ISR for
>> > > buffer processing ?
>> > >
>> > > Thanks.
>> > >
>> > > ________________________________
>> > > From: Richard Williams
>> > > To: B S ; "c..."
>> > > Sent: Thursday, November 29, 2012 11:41 PM
>> > > Subject: Re: [c6x] SWI vs. TSK
>> > >
>> > >  
>> > >
>> > > B.S.
>> > >
>> > > using the EDMA3 peripheral, no cpu cycles need be expended for I/O
>> > >
>> > > You could link the EDMA chains so ping/pong is operational for both
>> > > the input and the output data flows.
>> > >
>> > > You could make sure that no external memory is accessed. I.E. use
>> > > L1P/L1D and L2 memory only with part of each L1/L2 allocated for cache
>> > > operations.
>> > >
>> > > You could make sure that all data accesses (by the cpu/program are
>> > > aligned on a 64bit boundary (8 byte boundary).
>> > >
>> > > You could make sure only single precision float values are being used
>> > > in all calculations.
>> > >
>> > > You could make sure the 6ALUs are always kept busy such that there are
>> > > no execution pipe stalls.
>> > >
>> > > You could up the Vcc voltage to 1.3v and then up the CPU clock to
>> > > 456MHz if you have the appropriate version of the 6748 DSP
>> > >
>> > > extensive use of the built-in SPLOOP buffer can/will greatly reduce the
>> > > execution time of the code.
>> > >
>> > > You could make sure the code makes max use of the 'compact'
>> > > instructions for heavily executed code sequences.
>> > >
>> > > You could make sure that heavily executed code sequences are all on
>> > > the same page of memory.
>> > >
>> > > ---------- Original Message -----------
>> > > From: B S
>> > > To: Richard Williams , "c..."
>> > >
>> > > Sent: Thu, 29 Nov 2012 06:01:52 -0800 (PST)
>> > > Subject: Re: [c6x] SWI vs. TSK
>> > >
>> > > > Thanks all for your suggestions.
>> > > >
>> > > > I am using C6748 with uPP to capture data from ADC which is sampling
>> > > > at 4.5 MSPS. Processing algorithm which compute only FFT at the moment
>> > > > is taking 1.2 millisecond. I used TSC register to benchmark uPP data
>> > > > transfer. uPP takes only 17 CPU cycle (17 * 1/300 MHz) to capture 1024
>> > > > point of data. I tried to increase the size of buffer but it takes the
>> > > > same amount of time to capture X size of buffer, perhaps the reason is
>> > > > that, it uses DMA to move data but I am not sure. I think it's
>> > > > impossible to accomplish FFT processing in some nanosecond duration
>> > > > even with highly optimized code. I simply want to maintain a
>> > > > continuous capturing and processing of incoming data, if some
>> > > > conditions met over the captured data, save those data points to
>> > > > permanent memory.
>> > > >
>> > > > Hope this helps.
>> > > >
>> > > > ________________________________
>> > > > From: Richard Williams
>> > > > To: B S ; "c..."
>> > > > Sent: Monday, November 26, 2012 4:54 AM Subject:
>> > > > Re: [c6x] SWI vs. TSK
>> > > >
>> > > > B.S.
>> > > >
>> > > > In general:
>> > > >
>> > > > It is almost always best practice to have the hardware interrupt
>> > > > routine trigger the SWI, where the SWI performs the actual processing.
>> > > >
>> > > > There are three things that I would recommend for allowing the
>> > > > processing of the data to stay ahead of the data capture.
>> > > >
>> > > > Double buffering helps immensely as then the older buffer of data can
>> > > > be processed while the newer buffer of data is being captured..
>> > > >
>> > > > For your case of the processing taking longer than the capture of the data.
>> > > >
>> > > > 1) reduce the capture rate
>> > > > 2) improve the algorithm and coding of the processing so it takes less
>> > > > time to process a buffer of data.
>> > > >
>> > > > I cannot give more specific guidance without knowing your application
>> > > > and the algorithm you are using.
>> > > >
>> > > > If you are willing to divulge that information (application and
>> > > > algorithm), then I can assist your further.
>> > > >
>> > > > R. Williams
>> > > >
>> > > > ---------- Original Message -----------
>> > > > From: B S
>> > > > To: "c..."
>> > > > Sent: Wed, 21 Nov 2012 07:54:35 -0800 (PST)
>> > > > Subject: [c6x] SWI vs. TSK
>> > > >
>> > > > > Hi,
>> > > > > How to maintain a real-time when time to fill a buffer is shorter than
>> > > > > processing it ? I want to use PING PONG case to maintain real-time but
>> > > > > don't understand how should I do it because in my application, time to
>> > > > > fill the buffer is shorter than processing it. In this case, should I
>> > > > > restrict HWI to trigger about the same time which is required to
>> > > > > process it ?
>> > > > >
>> > > > > I would appreciate if you help me understaing when TSK or SWI should
>> > > > > be used ?
>> > > > >
>> > > > > According to DSP/BIOS user guide, SWI runs untill its completion. Does
>> > > > > that mean, there will be no HWI untill SWI ISR will be executed ?
>> > > > >
>> > > > > Thanks.
>> > > > ------- End of Original Message -------
>> > > ------- End of Original Message -------
>> > ------- End of Original Message -------
>> ------- End of Original Message -------
> ------- End of Original Message -------
>
>
>
> _____________________________________
>

_____________________________________