EDMA A sync vs. AB sync

It is my understanding that you do not have a choice of A-sync versus AB-sync, 1D1D requires A-sync and 2D1D and 1D2D both require AB-sync.

Lee

I thought the type of sync merely indicated how many sync events you needed to transfer per dimension? I haven't read anything in the TRM that says you can't use it for normal 1D-1D transfer of data.

Ralph

I've had both A and AB synchronisation working now. I'm still not sure which would be faster as both are limited with a maximum data transfer per event of 32767 bytes (for "large" transfers at least).

On this topic, in the "Block Move Example" in section 5.3.1 of the TRM, it says that "If the amount of data is greater than 64K bytes, BCNT and the B-indexes need
to be set appropriately with the synchronization type set to AB-synchronized".

Is this statement true for all cases, or is it just referring to this particular example?

Thanks,
Ralph

_Ralph_ said:

On this topic, in the "Block Move Example" in section 5.3.1 of the TRM, it says that "If the amount of data is greater than 64K bytes, BCNT and the B-indexes need
to be set appropriately with the synchronization type set to AB-synchronized".

What documentation are you referring to?  My primary reference to the EDMA LLD has been this:

http://processors.wiki.ti.com/images/5/5e/EDMA3_LLD.pdf

Lee

Wow, thanks for the link. It seems much clearer than the DM8168 Technical Reference Manual on EDMA which is what I was using.

Ralph

_Ralph_ said:

Wow, thanks for the link. It seems much clearer than the DM8168 Technical Reference Manual on EDMA which is what I was using.

This is most clear discussion on EDMA that I've seen so far, but I believe that example 3, the block move, is in error, BCNT should be 2, not 4.

ACNT = number of bytes per element

BCNT = number of elements per frame

CCNT = number of frames

Lee

In example 2 there is an error where DSTBIDX should be 1, not 2. The source element size is 1 byte and if you want to transfer the source bytes so they are contiguous in the destination you should have a DSTBIDX of 1.

In example 3, there are 4 elements per frame (BCNT=4), with each being 2 bytes big (ACNT=2, SRCBIDX=2). TI have made a mistake saying that BCNT is in bytes when it isn't. BCNT is a quantity of how many cells of size ACNT (which _is_ in bytes) there are. This is the logical way of reading it, and the TRM backs this up so fingers crossed this is what's happening.

As if TI hadn't managed to confuse us enough, the EDMA3 LLD manual then contradicts itself in the same paragraph regarding where you count from to get SRCCIDX!!!

From the first byte of loc_11 (the starting of the last 16-bit value
in Frame 1) to the first byte of loc_14, how many bytes should we jump to hop from the end of
the first frame to the beginning of Frame 2? If you count: loc_12 (2 bytes), loc_13 (2 bytes),
loc_14 (2 bytes) – that totals 6 bytes for SRCCIDX.

should be

From the first byte of loc_11 (the starting of the last 16-bit value
in Frame 1) to the first byte of loc_14, how many bytes should we jump to hop from the end of
the first frame to the beginning of Frame 2? If you count: loc_11 (2 bytes), loc_12 (2 bytes),
loc_13 (2 bytes) – that totals 6 bytes for SRCCIDX.

The TRM says that IDXs are measured from the start of cells. I acknowledge there's no problem when your source cells are contiguous (ACNT==SRCBIDX) but when you have gaps between your source cells you're in a world of confusion.

Ralph

P.S.

Having read through the document, it's quite DSP oriented. I'm looking for something more ARM related. Something explaining the contents of the edma.c file would be great!

Will I get an answer from TI on my original post in time for Christmas?