Filter
Top Products
Overview
2-4
■ A message queue is created to allow the remote node to receive
commands from the GPP.
■ The node-specific "create" function (for example,
AUDENC_create() ) is called to initialize the node state and
algorithm-specific memory and resources. (Note that this call is
made from within the dispatcher execution context.)
■ A dedicated execution thread (task) is created for the node. The
new thread does not run yet, but is in a suspended state.
■ In the dispatcher thread, instance data for the new node is saved,
and then the dispatcher sends a status response back to the
GPP.
■ On success, the GPP-side instance object is updated with
appropriate handles and data for the new "remote" node.
■ A "start" message is then formed and sent to the dispatcher on
the DSP to start execution of the remote node.
■ Upon receiving the "start" command, the DSP-side dispatcher
changes the priority of the node's thread from suspended to its
configured execution priority. This change in priority causes the
node’s "execute" function to run in the newly created node's
execution context. This function blocks, awaiting commands
from the GPP.
2) The application calls the VISA process API (for example,
AUDENC_process() ), which results in a remote procedure call to the
DSP:
■ The GPP-side algorithm stub is invoked and performs some
basic argument validation.
■ A message structure is allocated and filled in with marshalled
arguments, including translated (DSP) physical addresses for
buffers.
■ The "process" message is sent to the remote node's message
queue on the DSP to invoke the remote algorithm.
■ On the DSP-side, the node's thread wakes upon receipt of the
"process" message, and calls the algorithm skeleton.
■ The skeleton unmarshalls the arguments and input and output
buffers and then invalidates the buffers from the DSP cache.
■ Any algorithm scratch memory is then "activated".
■ The algorithm's actual "process" function is invoked to do the
encoding.