> >> Do you use any buffers allocated by malloc? My guess is that malloc > >> does allocation of DARAM and SARAM memory. > >> In any case, memory returned by malloc should be not worse than the > >> memory buffer explicitly statically placed to EXTMEM. > > > > Yes, I think you're right, in the avs_kernelcfg.cmd file it talks about a > > DARAM_heap and a SARAM_heap, presumably it's possible to allocate from > > either somehow (using the CSL MEM_* calls probably, I don't know off hand > > which heap is used for task data, but will have a look this evening). It > > also talks about a/the stack being in SARAM. > > I'm sorry if it was not clear enough. Just use normal malloc from C library > without any CSL_MEM_* stuff. You can add some debugging prints for the addresses > of allocated blocks and identify what kind of memory they are actually in (DARAM, > SARAM, SDRAM). By the way, this information is especially important if you want > to use DMA, as you need specifically configure the type of memory (not just > address) when setting up DMA transfer.
No, I understood, I was just mentioning that there appear to be two heaps to chose from - presumably one is used by the DSP tasks (malloc is probably #defined as one of the CSL MEM* fns in the DSP Gateway task functions). > > Over lunch I had a play with the things I talked about in my last email. > > Removing the memcpy (from the slow SDRAM X[] array to the fast SARAM > > fast_in[] array) made the code marginally slower - at least there were more > > drop outs, so it appears that the memcpy() overhead is less than the extra > > time needed to access the data in SDRAM. > > Yes, accessing SDRAM memory is extremely slow. And if you access SDRAM > memory using 16-bit accesses instead of 32-bit accesses, the overhead > doubles. So if your data processing algorithm does not deal exclusively > with 32-bit data accesses, you are better not to run it to process data > in SDRAM memory. Copying data to a temporary buffer in DARAM or > SARAM, processing it there and copying results back to SDRAM would be > faster in this case. The X[] array data type is an int32, so even accessing 32bit from SDRAM is still slower than using a local buffer (depending on what you need to do with it of course). > > I shaved a few array elements off the output[] SARAM array (down from 100 to > > 78 elements, this fits the current Bluez encoder parameters, but if they > > were changed upwards, both the input[] and output[] arrays would probably > > need to be made bigger). I also removed the #PRAGMAs I had been using to > > place the const data from sbc_tables.h in SARAM as from looking the > > avs_kernelcfg.cmd file, .const data is already placed in SARAM (SARAM_DATA > > section) and I thought this might free up some room to fit the X[] array in > > SARAM directly. It didn't. Moving the const tables freed 72x32bits, removing > > the fast_in[] array (not needed if X[] itself is fast) freed 80x32bits, but > > the X[] array requires 2x160x32bits. It still doesn't fit :( > > 2x160x32 bits is only 1280 bytes, which is hardly too big. Try to allocate > buffers with malloc and copy constant tables there on initialization. It know there's not much free SARAM memory (note that the DSP Gateway kernel also appears to hold the majority of its data in the DSP internal memory). But parts of the SARAM and DARAM are reserved for the stack and heaps, which may well have free space on them. It appears that 0xc00 (8bit) bytes are reserved for the stack, the DARAM heap is 0xbf40 bytes in size and the SARAM heap is 0xd000 bytes long. So this may mean that there's enough space in the SARAM if I use malloc to get the memory from the heap. I had thought that the heap would be fairly small so I was #PRAGMAing my large structures to be placed in SDRAM; this was probably the wrong thing to do. I'll test and report back. Cheers, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
