I'm finding that copying / moving blocks of memory on the DSP side of an OMAP 3530 (Gumstix Overo fire module) is running extremely slowly.
Using DSP_blk_move, the documentations (TMS320C64x+ DSP Little-Endian DSP Library Programmer’s Reference) says the move operation should take N/4+6 cycles, but I'm finding it takes approximately 30 times that.
e.g.
#define N 512
#pragma DATA_ALIGN(8);
int16_t b1 [N];
#pragma DATA_ALIGN(8);
Int16 b2 [N];
...
uint32_t cntSmps = CLK_countspms()/1000; // counts per microsecond
uint32_t spH = CLK_cpuCyclesPerHtime();
uint32_t t0, t1, t2;
t0 = CLK_gethtime();
t1 = CLK_gethtime();
DSP_blk_move(b1, b2, N);
t2 = CLK_gethtime(); // returns the programmed number of hardware timer register ticks per millisecond
sprintf(txt, "Clock call time = %d tics", t1-t0);
terminalOut(txt);
t2 = t2-t1 - (t1-t0);
sprintf(txt, "DSP_blk_move %d samples of data from 0x%X to 0x%X took %d tics %duS (expect %d = x%3.2f)",
N, b1, b2, t2*spH, t2/cntSmps, N/4+6, (float)(t2*spH)/(float)(N/4+6));
terminalOut(txt);
gives the following output:
DSP: Clock call time = 16 tics
DSP: DSP_blk_move 512 samples of data from 0x8D0649A0 to 0x8D064DA0 took 3866 tics 10uS (expect 134 = x28.85)
I'm using dsplib64plus.lib version 2.10 from 30 March 2010.
I get very similar results for different block sizes (up to 2^16 samples) and approximately the same amount of time when using memcpy and memmove.
Any suggestions greatly appreciated.