API functions using Codec Engine (iv)

This article is translated from TI's Handbook, the Handbook is a study of gpp+dsp development of the Golden Code document, I hope that the introduction of the help, there is an inappropriate understanding of the hope please enlighten.
Codec Engine application Developer User ' s Guide.pdf (literature number:sprue67d)
"Codec Engine Application Development Manual" http://blog.csdn.net/dyzok88/article/details/42154487
Chapter One Codec Engine Overview http://blog.csdn.net/dyzok88/article/details/42214813
Chapter II Installation and setup of Codec Engine http://blog.csdn.net/dyzok88/article/details/42278109

Chapter Three uses CODEC Engine's sample application http://blog.csdn.net/dyzok88/article/details/42302793

Body

4.4 Codec Server API functions

In a dual-CPU system, the configured engine "remotely" runs (in DSP) algorithms, transparently using a "DSP server". The DSP server is an executable program for an integrated algorithm and its framework (for example, Dsp/bios, framework components, codecs, and DSP Link drivers), and when the engine is opened, these components are loaded on the DSP and start running.

Server API functions can be called by applications running on GPP, which can access information about the DSP server and control the DSP server. More specifically, these API functions allow GPP applications to obtain information about the number of memory heaps configured in the DSP server, the current usage of a separate memory heap, and so on. and the base address and size of the algorithm heap for reconfiguring the DSP server.

The API functions that involve the server are:
1. Engine_getserver (). Gets the handle to the server.

2. Server_getnummemsegs (). Gets the number of heaps in a server.

3. Server_getmemstat (). Gets the heap statistics about the server.

4. Server_redefineheap (). Sets the base address and size of the server heap.

5. Server_restoreheap (). Resets the server heap to the default base address and size.

4.4.1 Getting the server handle

to access for the DSP server engine , the GPP application must first obtain a server handle by calling the Engine_getserver () API , for example:

static String enginename = "Auddec"; Engine_handle engine; Server_handle server; Engine_error err;engine = Engine_open (Enginename, NULL, &err); server = Engine_getserver (engine);

Note: Engine handles, server handles are not thread protected. Each thread uses a server handle that must perform its own engine_getserver () call (using its own engine handle), or to guarantee synchronous access to the shared server handle.

If the Engine_getserver () return value is NULL, then the engine does not have a server.

4.4.2 Getting memory heap information

the GPP application can be called by calling the Server_getnummemsegs () function, get the number of memory heaps configured to the DSP server, for example:

Server_handle server; Server_status status;int numsegs;/* Get the server handle from a previously opened Engine */server = Engine_getserver (engi NE); status = Server_getnummemsegs (Server, &numsegs);

These API functions return the following error code:
1. Server_eok-Success. In this case, the Numsegs contains the number of heaps in the DSP server.
2. Server_eruntime-An internal run-time error occurred.

Once the number of heaps is known, the GPP application uses the Server_getmemstat () function, which can then be used to get each heap statistic through this number of iterations. The memory statistics are returned to the SERVER_MEMSTAT structure:

typedef struct SERVER_MEMSTAT {Char name[server_maxsegnamelenth+1];          /* Name of Heap segment */Uint32 base;          /* Base Address of heap */Uint32 size;          /* Original Heap Size */Uint32 used;   /* DSP MAUs of heap used */Uint32 Maxblocklen; /* Length of Largest free block */} Server_memstat;

The following sample code shows the use of these API functions (for readability, ignoring error checking)

Int Numsegs, I; Server_memstat Stat; Server_status status;status = Server_getnummemsegs (Server, &numsegs); for (i = 0; i < Numsegs; i++) {Status = S    Erver_getmemstat (server, I, &stat); printf ("%s:base:0x%x size:0x%x used:0x%x Max free block:0x%x", Stat.name, Stat.base, Stat.size, stat.u SED, stat.maxblocklen);}

The return value of Server_getmemstat () is as follows:
1. Server_eok. Success.
2. Server_enotfound. The segment number is out of range.

3. server_eruntime. An internal run-time error occurred.

4.4.3 to reconfigure the algorithm heap of the DSP server

the DSP server can be configured to dedicated to algorithmic heap of memory segments. In some cases, the DSP server is configured with a small algorithm heap, and the GPP application may need to provide a large, contiguous block of memory used by the DSP server for the algorithm heap at run time. Then, when the heap is not used by the DSP, the memory can be recycled from the DSP and then used by GPP. The following server API functions provide the means to reconfigure the DSP algorithm heap:

Server_status server_redefineheap (Server_handle Server, String name, Uint32 base, Uint32 size); Server_status server_restoreheap (Server_handle Server, String name);

The argument "name" passed to these functions is the name of the heap to reconfigure, and it must not be less than server_maxsegnamelength characters. The "base" address that is passed to Server_redefineheap () must be the address of the DSP, and the memory from base to base + size must be contiguous physical memory. The parameter "size" is given in the DSP Madus (minimum addressable data units, the smallest addressable cell). The base address should be 8-byte aligned, but there is no alignment limit for size, and a value of 0 is acceptable.

When no memory on the heap is currently allocated, the DSP algorithm heap can only be reconfigured. The Server_restoreheap () function resets the base address and size of the algorithm heap back to their original values (any value prior to calling Server_redefineheap (). After a successful call to Server_restoreheap (), the memory was previously "redefined" to the heap and can be used again by the system.

The return value of Server_redefineheap () is as follows:
1. Server_eok. Success.
2. Server_einval. Changing to a new base address and size results in overlapping with another heap.
3. Server_einuse. The memory is currently allocated in the algorithm heap.
4. Server_enotfound. No heap was found for the given name.

5. Server_eruntime. An internal run-time error occurred.

Server_restoreheap () returns any of the following values:

1 . server_eok. Success.
2. Server_einval. Changing to a new base address and size results in overlapping with another heap.

3. Server_einuse. The memory is currently allocated in the algorithm heap.
4. Server_enotfound. No heap was found for the given name.
5. Server_eruntime. An internal run-time error occurred.

The following code shows how these two APIs can be used on dm644x (a GPP+DSP device), in which the GPP application allocates a contiguous block of memory using the Memory_contigalloc () function. However, the address returned through this function is the virtual address of the GPP, so it must be passed to Server_redefineheap () before being converted to the DSP address, memory_getbufferphysicaladdress () The function can convert the virtual address into the physical address of the GPP, so that in the case of dm644x, it is the same address of the DSP.

After the algorithm runs, the algorithm heap is reset to its original size and position, and for better readability, error checking is omitted.

Server_handle  server = NULL; Server_status  status; Engine_handle  ce = NULL; Xdas_int8     *BUF; Uint32         base; String decodername  = "Auddec_copy"; String encodername  = "Audenc_copy"; String enginename   = "audio_copy";/* Open the Engine and get Server handle. Note, the * Engine_open () call would load and start the DSP. */ce = Engine_open (enginename, NULL, NULL); server = Engine_getserver (CE);/* Allocate block of memory, contiguous in physic Al Memory */buf = (Xdas_int8 *) Memory_contigalloc (BUFSIZE, ALIGNMENT);/* Convert virtual address to physical address, whic H on  * dm644x, happens to be the same as the DSP address. */   base = memory_getbufferphysicaladdress (buf, BUFSIZE, NULL);/* Reconfigure the algorithm heap */status = Se Rver_redefineheap (server, "Ddralgheap", base,      BUFSIZE); ' Create and run codecs ' Delete codecs '/* Reconfigure algorithm heap back to their original state. */staTus = Server_restoreheap (Server, "ddralgheap");/* Free the buffer */memory_contigfree (buf, BUFSIZE); 

in other cases, the application may need to reconfigure the algorithm heap to an address , allocating a buffer on ARM does not get the address. For example, suppose there is a fixed memory space on the DSP that gives the application the alternative to the algorithm heap, depending on what algorithm to run. In this case, the application can pass the address of the DSP directly to the Server_redefineheap () function.

API functions using Codec Engine (iv)