[Dspforum] EDMA Questions

Tue Nov 3 18:45:56 MST 2009

You don't need a second buffer if you work from the "back" to the front.
I.e., take the data at 8191, and write it to 8192*2-2, and a zero at 8192-1,
etc.

To better understand how to perform different transfers, go to the myriad of
examples in the appendix of SPRU234. I think "Figure A-4.Element
Synchronized 1D-to-1D Transfer (SUM = 00, DUM = 11)" applies directly.

Joseph

On Tue, Nov 3, 2009 at 6:49 PM, Alan Ding <alan33d at gmail.com> wrote:

> In terms  of rearranging the 1/2 full ping buffer to put 0's in every other
> sample and spreading out the samples across 2*8192 floats, which I can't
> seem to figure out how to do without overwriting something along the way
> unless if I have a temporary storage buffer.
>
> In order to do this interpolation, we need another buffer to iterate
> through, correct?  Am I not getting something.
>
> we first need to do: ping[i]=(float)*((short*)(&ping[i])); to get just the
> right channel since left and right short values for each index is
> duplicated.
>
> we also need a second buffer to DMA into and iterate for 2*4096 samples and
> place the values in every other sample in the ping buffer with 0's in
> between before doing the FFT?
>
> Hypothetically, if I would like a more elegent solution using the IDX and
> CNT fields for EDMA, how would I do that?
>
> I am still element synchronized....  the ELERLD field is 2*8192.  LINK is
> pointed to the handle for Pong....  I guess how does the IDX field work for
> our uses to have the every other sample offset when DMA'n into the ping or
> pong buffer?
>
>  Parameter Contents Parameter
>
> 307D 0002h EDMA Channel Options Parameter (OPT)
>
> 3000 0000h EDMA Channel Source Address (SRC)
>
> 007Fh 0002h EDMA Channel Transfer Count (CNT)
>
> 0000 2000h EDMA Channel Destination Address (DST)
>
> FF81h 0080h EDMA Channel Index (IDX)
> 0002h 01B0h EDMA Channel Count Reload/Link Address (RLD)
>
>
> I think I am lost....
>
> Thanks,
>
> Alan
>
> On Tue, Nov 3, 2009 at 2:11 PM, Wenstrand, Doug S. <
> Douglas.Wenstrand at jhuapl.edu> wrote:
>
>>  Second question - most certainly there is, and you could certainly do
>> that.  I presume that you mean that you are going to fill those buffers with
>> 0's and then only put data in the alternating samples.  It does introduce a
>> couple of problems though - if you compute the FFT in place in the buffer,
>> those zeros will be gone, and need to be refilled again.  There are ways
>> around that, and there  are tons of solutions to get you where you want to
>> be.
>>
>>
>>
>> The thing is, data is going to arrive in a format that isn't what you want
>> in more ways than that.  First and foremost, it will be in fixed point form,
>> and it will be packed L/R ...etc.  No matter how you look at it, you are going
>> to have to do some sort of pre-processing of the buffer before you do your
>> FFT.  If that is the case, you might as well make it simple, just let the
>> ping or pong buffer get 1/2 full with data.  Then, when it is done, have a
>> little pre-processing function that picks the right channel, converts the
>> data to float, puts in the 0's.  At the end of that function, you'll be
>> using the whole ping or pong buffer, and can FFT it right in place.
>>
>>
>>
>> Like I said, tons of other choices and you are free to do whatever makes
>> sense to you.  This is a simple way though, that doesn't require lots of
>> complexity in the DMA, and doesn't really take any significant extra time.
>>
>>
>>
>> Doug
>>
>>
>>
>> Note - the first question
>>
>> But if we "interdigitate" with zeros, after the buffer is filled with
>> samples, aren't we going to lose data?
>>
>>
>>
>> The buffer shouldn't be filled with samples, right?  That would be too
>> many samples.  If your buffer is FFTSIZE*complex, and you have real data, if
>> it is full, you have 2xFFTsize points.  The way we are describing it, your
>> buffer would be 1/2 full.
>>
>>
>>
>>
>>
>> *From:* dspforum-bounces at echelonembedded.com [mailto:
>> dspforum-bounces at echelonembedded.com] *On Behalf Of *Alan Ding
>> *Sent:* Tuesday, November 03, 2009 2:01 PM
>> *To:* dspforum at echelonembedded.com
>> *Subject:* Re: [Dspforum] EDMA Questions
>>
>>
>>
>> But if we "interdigitate" with zeros, after the buffer is filled with
>> samples, aren't we going to lose data?
>>
>>
>>
>> Is there  a way to setup the IDX field to put sample elements in every
>> other buffer index?
>>
>> On Tue, Nov 3, 2009 at 7:50 AM, Joseph Haber <josephhaber at gmail.com>
>> wrote:
>>
>> All,
>>
>>
>>
>> One common way to handle this is to have a for loop in the processing that
>> occurs after the EDMA for a ping or pong buffer is done, prior to the FFT.
>> That would iterate through the loop, select one channel, perform the
>> short-to-float conversion, and interdigitate with zeros.
>>
>>
>>
>> Joseph
>>
>>
>>
>> On Tue, Nov 3, 2009 at 1:07 AM, Alan Ding <alan33d at gmail.com> wrote:
>>
>> - ping and pong buffers are of size COMPLEX*FFTLEN. Does that mean that
>> they are automatically filled with complex zeros or do we have to do that?
>>
>> I think we have to do that... I'm still trying to figure out how this
>> element index offset thing work.   Since we are DMA'ing 32-bit ints that are
>> L and R channels into a float buffer, how do we extract just the left
>> channel?
>>
>>
>>
>>
>> - i have issues finding/understanding RLD register. What is it used for?
>>
>> From spru234.pdf:
>>
>> "EDMA Channel Count Reload/Link Address Parameter (RLD)
>> The EDMA channel count reload/link address parameter (RLD) in the EDMA
>> parameter entries specifies the value used to reload the element count
>> field
>> and the link address. The RLD is shown in Figure 2-18 and described in
>> Table 2-25.
>> The 16-bit unsigned element count reload (ELERLD) value reloads the
>> element count (ELECNT) field in the EDMA channel transfer count parameter
>> (CNT), once the last element in a frame is transferred. ELERLD is used
>> only
>> for a 1D element sync (FS = 0) transfer, since the EDMA has to keep track
>> of
>> the next element address using the element count. This is necessary for
>> multiframe
>> EDMA transfers, where frame count value is greater than 0. See
>> section 1.7 for more details.
>> The EDMA controller provides a mechanism to link EDMA transfers. This is
>> analogous to the autoinitialization feature in the DMA. When LINK = 1 in
>> the
>> EDMA channel options parameter (OPT), the 16-bit link address (LINK)
>> specifies the lower 16-bit address in the parameter RAM where the EDMA
>> loads/reloads the parameters of the next event in the chain. Since the
>> entire
>> EDMA parameter RAM is located in the 01A0 xxxxh area, only the lower
>> 16-bit
>> address is required.
>> The reload parameters are specified in the address range 01A0 0180h to
>> 01A0 07F7h. You must ensure that the link address is on a 24-byte
>> boundary,
>> and that the operation is undefined if this rule is violated (see section
>> 1.9). In
>> addition to the reload parameter space, the entry of any unused EDMA
>> channel can also be used for linking. The EDMA can always have up to 85
>> programmed entries, regardless of the number of channels actually used."
>>
>>
>>
>> On Mon, Nov 2, 2009 at 11:07 PM, Nenad Uzunovic <
>> nenad at roboticresearch.com> wrote:
>>
>> Hi there,
>>
>> I have a few questions about the EDMA lab.
>>
>> - ping and pong buffers are of size COMPLEX*FFTLEN. Does that mean that
>> they are automatically filled with complex zeros or do we have to do that?
>>
>> - i have issues finding/understanding RLD register. What is it used for?
>>
>> Thanks,
>> Nenad
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Dspforum mailing list
>> Dspforum at echelonembedded.com
>> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>>
>>
>>
>> --
>> -------------------------------------------------------
>> Alan Ding
>> Master of Sci, Electrical Engineering
>> Johns Hopkins University
>>
>> Email: alan33d at gmail.com
>> Contact #: 4844593290
>>
>> _______________________________________________
>> Dspforum mailing list
>> Dspforum at echelonembedded.com
>> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>>
>>
>>
>>
>> _______________________________________________
>> Dspforum mailing list
>> Dspforum at echelonembedded.com
>> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>>
>>
>>
>>
>> --
>> -------------------------------------------------------
>> Alan Ding
>> Master of Sci, Electrical Engineering
>> Johns Hopkins University
>>
>> Email: alan33d at gmail.com
>> Contact #: 4844593290
>>
>> _______________________________________________
>> Dspforum mailing list
>> Dspforum at echelonembedded.com
>> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>>
>>
>
>
> --
> -------------------------------------------------------
> Alan Ding
> Master of Sci, Electrical Engineering
> Johns Hopkins University
>
> Email: alan33d at gmail.com
> Contact #: 4844593290
>
> _______________________________________________
> Dspforum mailing list
> Dspforum at echelonembedded.com
> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20091103/705d4c49/attachment-0001.html>