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. Start a New Thread

BS,

On 11/21/2012 9:54 AM, B S wrote:
> Hi,
>
> How to maintain a real-time when time to fill a buffer is shorter than
> processing it ?

For realtime processing of a continuous data stream the code to process
a buffer needs to execute in the same amount of time [or less] that it
takes to acquire the buffer.
The way to accomplish this is 'quicker code' or a 'faster processor'.

mikedunn
> 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. Start a New Thread

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 -------

_____________________________________ Start a New Thread

B S-

Emphasizing Richard's comments, keep the HWI as short as possible, and invoke the SWI as soon as possible.

Also:

-pay close attention to whether to mask or
enable other interrupts during the HWI

-remember that SWI functions are limited and
can't do some things, such as call certain
BIOS functions, call malloc, etc. (there are
work-arounds)

-I recall, but I'm not sure, that if an HWI
goes off before its SWI is complete, and it
tries to invoke another SWI, that nothing
happens. But if that's wrong, you can use
a simple flag or semaphore to prevent such
an "overrun" -- or alternatively you can
keep track of this in some type of queue,
which might be helpful for uneven sampling
rates

You mention controlling the HWI rate -- normally that's determined by the nature of the data and its sampling
requirements, and typically you have limited flexibility unless you make tradeoffs that reduce data integrity.

-Jeff

> 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.

_____________________________________ Start a New Thread

Hi,

The PING - PONG buffer will not solve your porblem unless the time for
processing data from buffer is <= filling time. you may need to change
the process tsk to higher priority.

Also the SWI can be interupprted by HWI, unless you block/dissable HWI
in SWI rutine..

Regrds
Shreedhar

On 11/25/12, mikedunn wrote:
> BS,
>
> On 11/21/2012 9:54 AM, B S wrote:
>> Hi,
>>
>> How to maintain a real-time when time to fill a buffer is shorter than
>> processing it ?
>
> For realtime processing of a continuous data stream the code to process
> a buffer needs to execute in the same amount of time [or less] that it
> takes to acquire the buffer.
> The way to accomplish this is 'quicker code' or a 'faster processor'.
>
> mikedunn
>> 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.

_____________________________________ Start a New Thread

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 ------- Start a New Thread

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 -------

_____________________________________ Start a New Thread

B.S.

My answers are inline, prefixed by

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.
The use of a ping/pong methodology on both the input and the output means:
some data is always being read,
some data is always being output,
some data is always be processed,
all at the same time; it probably will not correct the problem if the data
processing taking to long

>
> 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 don't think I suggested using a semaphore; however, using a semaphore as
you suggest will throttle the data flow to the rate that the software can
process the data. Using a semaphore, as you suggest, will also result in lost data.
Your best bet is to either slow the sample rate (samples per second) or speed up
processing.

>
> 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 ?

I do not understand this last question. (what is TSK and UPP?)
The best method is:
setup the EDMA to double buffer the input.
setup the EDMA to double buffer the output.
setup the EDMA to trigger a HWI when any input buffer is full
in the HWI processing, trigger a SWI to perform the processing on the most
recently filled input buffer, then exit the HWI.

(the sample code that comes with the CCS kits (and is available at TI.com),
shows exactly how to write the code for using EDMA to double buffer the input,
double buffer the output, and triggering a HWI when a input buffer is full.
and how to use the HWI to trigger a SWI when a input buffer fills, etc.)

The above will give the best use of the available CPU cycles.

Then you need to, as I said before:
1) reduce the input sample rate so it takes longer to fill a buffer
2) speed up the processing, so the SWI is completed before the next HWI occurs.

The sample rate needs to be determined as:
--twice the frequency of the fastest event to be captured in the input data.

As an example, for audio, about the fastest change that needs to be captured is
less than 4k hz. (the phone companies use 3k hz) So a sample capture rate of 8k
hz is more than sufficient for audio.

To acquire more detailed assistance, we need to see your code for
1) setting up the EDMA peripheral
2) setting up the L1/L2 cache
3) setting up the HWI interrupt
4) processing the HWI interrupt
5) processing the SWI interrupt
6) setting up the 4 data buffers

Also, the linker control file to assure the code is being placed in the right
locations in the DSP memory map.

R. Williams

>
> 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 -------

_____________________________________ Start a New Thread

R. Williams,

Thanks again for your detailed answer.

I am not using EDMA peripheral separately, that's part of UPP (Universal Parallel Port). I am using OMAP-L138 EVM which has User Interface (UI) board, ADC has connected with that board. ADC is interfaced with DSP via UPP.

UPP User Guide:
http://www.ti.com/lit/ug/sprugj5b/sprugj5b.pdf

I have already considered reducing sample rate but no use. I benchmarked UPP transfer with differet Fs but it has no effect at all. It takes only 17 CPU cycle to transfer 1024 or X size of data with any sampling rate. CPU is running at the rate of 300 MHz.

I thought of using semaphore because of the long processing time of the buffer. Yes, data will be lost but it will be atleast synchronized, it will wait untill processing is done. Sorry, I couldn't come up with anything else at the moment.
I will consider your suggestions and get back with something useful.

Regards,
BAS
________________________________
From: Richard Williams
To: B S ; "c..."
Sent: Tuesday, December 4, 2012 3:02 PM
Subject: Re: [c6x] SWI vs. TSK

 
B.S.

My answers are inline, prefixed by

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.
The use of a ping/pong methodology on both the input and the output means:
some data is always being read,
some data is always being output,
some data is always be processed,
all at the same time; it probably will not correct the problem if the data
processing taking to long

>
> 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 don't think I suggested using a semaphore; however, using a semaphore as
you suggest will throttle the data flow to the rate that the software can
process the data. Using a semaphore, as you suggest, will also result in lost data.
Your best bet is to either slow the sample rate (samples per second) or speed up
processing.

>
> 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 ?

I do not understand this last question. (what is TSK and UPP?)
The best method is:
setup the EDMA to double buffer the input.
setup the EDMA to double buffer the output.
setup the EDMA to trigger a HWI when any input buffer is full
in the HWI processing, trigger a SWI to perform the processing on the most
recently filled input buffer, then exit the HWI.

(the sample code that comes with the CCS kits (and is available at TI.com),
shows exactly how to write the code for using EDMA to double buffer the input,
double buffer the output, and triggering a HWI when a input buffer is full.
and how to use the HWI to trigger a SWI when a input buffer fills, etc.)

The above will give the best use of the available CPU cycles.

Then you need to, as I said before:
1) reduce the input sample rate so it takes longer to fill a buffer
2) speed up the processing, so the SWI is completed before the next HWI occurs.

The sample rate needs to be determined as:
--twice the frequency of the fastest event to be captured in the input data.

As an example, for audio, about the fastest change that needs to be captured is
less than 4k hz. (the phone companies use 3k hz) So a sample capture rate of 8k
hz is more than sufficient for audio.

To acquire more detailed assistance, we need to see your code for
1) setting up the EDMA peripheral
2) setting up the L1/L2 cache
3) setting up the HWI interrupt
4) processing the HWI interrupt
5) processing the SWI interrupt
6) setting up the 4 data buffers

Also, the linker control file to assure the code is being placed in the right
locations in the DSP memory map.

R. Williams

>
> 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 ------- Start a New Thread

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 ------- Start a New Thread