Why is DMA separate from BIOS/DSP?

I'm not sure if I understand...

DMA is one of features of our DSP. It is a hardware feature of the DSP: "The direct memory access (DMA) controller performs asynchronously scheduled data transfers

between memory regions without the intervention of the CPU."

So, as any piece of hardware, it needs to be used by your program by software. You can do that just controlling the DMA registers directly (that can be a lot of work) or use our software stack that abstracts that for you. So our DSP/BIOS drivers use DMA, and the document you mentioned is describing the software to internface to it.

To elaborate on Mariana's suggestion, assuming you are using DM6437 based on your prior posts there is a EDMA driver available, for documentation on it please see C:\dvsdk_1_01_00_15\psp_1_00_02_00\edma3\src\edma3_drv\docs. This is a more direct driver than the DMA framework suggested by SPRAAG1, so it may or may not be useful depending on what exactly you are trying to implement.

Hi,

       Thanks.

        I think the reason is that C64x+ is replaced by hardwired logic in such devices as DM355.

so DMA is not part of DSP/BIOS. If so, ARM side application may run the code that DSP application

run before.In this case DSP/BIOS doesn't exist.

      Today I find a new document spraan4a: How to use the EDMA3 Driver on a TMS320DM643x device.

What is the relation between spraan4a and SPRAAG1.

      I am developing algorithms on DM6437. In order to improve performance, DMA maybe be utilized.

I'm not clear how to use DMA. It seems DMA is used directly in spraan4a. But I remember that algorithms

can't use it directly. I am a little confused.

Best Regards

Jogging

Please note that DSP/BIOS is the Operating System on top of DSP processor and peripheral drivers, such as DMA, are normally written on top of this.

That said, spraan4a discusses the software low level EDMA driver and how to use it, this is primarily geared towards using EDMA channels (as opposed to QDMA channels).   SPRAAG1 discusses DMA from a framework components point of view and primarily used to access QDMA channels.  Please note that I use 'primarily; to mean these are typically the default allocations of the DMA channels.  Also, framework components 2.20 and higher have added features to allow access of EDMA channels as well, although I have not seen this features at work myself yet.  The advantage of using framework components instead of directly accessing DMA resources via low level DMA driver is that if multiple algorithms from different vendor are used in your system, framework components will provide a way to ensure two or more algorithms are not trying to access the same DMA resource.

Also, I am no sure what you meant by "ARM side application may run the code that DSP application run before", but just wanted to point out that there is no ARM on DM643x.

Hi,

     Thanks. Do you mean that framework component is just a wrapper of EDMA driver?

Best Regards

Jogging

we provide two ways to access DMA resources, one is via the framework (framework components software module), the other is via Low Level DMA driver.

hihi, jog, now i have the same puzzle with you. i need to use DMA on DM6467. i am now developping an video filering algo under the environment of CCS 3.3 SR12 + XDS560 emulator.

I don't know how should i choose to interface with DMA, ACPY(framework) or LLD?

Is there any suggestion from you?

thanks!

bhouziao