Forums - FastRPC restrictions?

4 posts / 0 new
Last post
FastRPC restrictions?
pyosifov
Join Date: 6 Aug 13
Posts: 19
Posted: Wed, 2014-01-29 07:56

We have 2 principal questions about FastRPC-based applications (as I understand, no another way to communicate with DSP using FastCV...?):

1) Is the way to hack lack of "inout" IDL parameter? We need bi-direct shared memory buffer... Little tests shows that is possible to do:

mystruct_t mystruct = { ... };

mydsp_func(&mystruct, &mystruct);

where: mydsp_func(in mystruct_t in_mystruct, rout mystruct_t out_mystruct) in IDL

But in this hack we have really two different copies of mystruct and mydsp_func() implementation gets 2 different pointers.

2) Is the way to workaround FastRPC synchronous nature (to prevent scheduller implementation on client-side with may-many-many calling of some DSP-interface function via FastRPC mechanism, may be via some non-blocked call and async. response from DSP-side) ?

  • Up0
  • Down0
anatolyy
Join Date: 15 Feb 14
Posts: 7
Posted: Sat, 2014-02-15 11:00

on the second question.  You can construct a thread or several threads and a queue on the arm side to faciliatate an asynchronous interface to the aDSP.  This is fairly simple to build, and gives the developer control over queing priorities, timeouts, etc.., without having the kernel driver managing such a complex data structure between different processes.  

  • Up0
  • Down0
pyosifov
Join Date: 6 Aug 13
Posts: 19
Posted: Mon, 2014-02-17 02:02

Anatoly, do you mean thread on ARM side? But is it possible to communicate with DSP via 2 (or more) threads in the same time, in parallel? Does FastRPC support this (exclusive access, buffers...) ?

  • Up0
  • Down0
anatolyy
Join Date: 15 Feb 14
Posts: 7
Posted: Mon, 2014-02-17 10:44

Its up to you to use your own thread synchronization mechansiims.  But you can call into the adsp with as many threads as the application OS will let you.

 

I find the easiest way to get going is to build the aDSP module to be simple and stateless and do the threadpool workerqueue on the HLOS side.  So the aDSP code can be a simple interface on top of a stateless algorith, and the HLOS code can contain all the thread managment complexity.  You can have more then 1 thread calling into the aDSP and you can have each thread pull more then one item from your work queue at a time.  Depending on the size of the memory you are mapping to the adsp with each work item this could be the most effecient way of doing this.

 

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.