Using DSPLink from multiple processes

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

Translate this page to

Overview

DSPLink supports usage from multiple applications/processes on Operating Systems such as Linux (where multiple processes are present). On operating systems such as PrOS, all tasks are simple threads, and hence this topic is not applicable.
This page describes the considerations when using DSPLink from multiple processes, and the method to be followed.

Details

The method to use DSPLink from multiple processes/applications is different depending on the version of DSPLink used. This page describes the usage pre & post "Enhanced multi-application support" added in DSPLink 1.50.

Pre "Enhanced multi-application support"

This is applicable for DSPLink versions 1.4x and earlier. For these versions of DSPLink, the complete system using DSPLink was considered as a fully static system, consisting of a single application.

The suggested usage is in the below figure:

Here, Process 1 calls PROC_setup(). This process creates a child process - Process 1-1 - using fork() and execve(). Each child process can then attach to the processor by calling PROC_attach(). All the threads in the child process space will share the file descriptor to the device driver & hence they gain access to channel objects. A child process can detach from the processor by calling PROC_detach() after all threads have exited successfully.

Any other process (not necessarily created by fork()) can also attach to the processor by directly calling PROC_attach().

Similarly, to open a POOL that has already been opened from the first process, other processes can simply call POOL_open() with NULL parameters to get a handle to the same POOL. Other processes may also open their own POOLs, as long as they are called before PROC_start(). If each process/application wishes to open its own separate POOL after PROC_start(), they must use the method documented at: Opening Pools dynamically.

When DSPLink is to be used by multiple different applications that are unable to coordinate between themselves in this manner, a separate daemon process is required, which will coordinate access to DSPLink to ensure that the first process to call PROC_attach() is the last one to call PROC_detach(). If this is not done, any other processes still executing while this 'owner' process exits, will crash, since the 'owner' process exit will clean up DSPLink.

The Link Arbiter Daemon provided with Codec Engine provides this functionality.

Post "Enhanced multi-application support"

Enhanced multi application support was added in DSPLink 1.50.

With this feature, the ownership concept for the PROC module was removed. The benefits available are:

Multiple unrelated processes are able to come and go. There are no hidden dependencies based on which process, for example, first used PROC_attach() as there were in previous versions. The first process to attach to the DSP is no longer required to be the last to detach.
An application can be written to execute singly using DSPLink to control and communicate with the DSP. The same application can be used without any changes in the application’s source code, to run simultaneously along with another application also using DSPLink. The only consideration to be used while writing the application, is that the DSPLink resources (e.g RingIO/MSGQ names) used by the applications must be unique for the system.
The applications running concurrently must only coordinate to ensure the following:
- The same integrated DSP executable is used containing DSP-side content required for all the co-existing GPP-side applications.
- The same dynamic configuration file is used by all applications.

This feature supports a partly dynamic system by allowing different applications to work independently of each other, and do not require one top-level application to integrate the multiple applications, as was required before this support was added into DSPLink.

Multiple threads within one process must still use DSPLink in the same manner as before (they must not call PROC_attach() or POOL_open() to get a handle to the DSP/POOL.)

With this feature, the Link Arbiter Daemon and similar utilities may no longer be needed. However, note that for applications which use the dynamic configuration of Link (i.e., they don't pass NULL into PROC_setup() - like Codec Engine applications), LAD and similar daemons can still be useful to keep the DSPLink configuration in a single place (the daemon) and outside of each application. Without LAD, all applications would need to ensure their dynamic configurations were compatible.

Additional details of this feature are available within the design document for "Enhanced multi-process support" LNK_157_DES.pdf, available within the DSPLink release package. This feature is also demonstrated within the message_multi example application added within DSPLink.

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Using DSPLink from multiple processes here.