• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 254 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dualcpu_separateconfig

Joern
Genius 3055 points

Hi, I installed the EZSDK for evmTI816X and easily got built and running the codec engine examples - especially the universal_copy example. I could enhance the behaviour for the universal_copy codec (running on the DSP within the all_codecs server) and got the expected results.

All that I did by use of the XDC felt framework. I find it a good idea to produce portability by such a framework. But it seems not desireable to me to combine the XDC usage with a huge, pure gcc project, where I just want to use the DSP as a co-processor for some simple but time-consuming jobs.

Then I found below video_copy the dualcpu_separateconfig example - that seems exactly to be what I need: an XDC-based module wraps all codec engine handling, the call of CERuntime_init() too. I hoped to easily get from this example a wrapper working for the universal_copy example.

But unfortunately it does not compile, and within the wiki that is announced to be an issue at least for DVSDK - obviously it is an issue for EZSDK as well.

I would be very happy if anyone could give me a hint how to write a small wrapper like demonstrated in video_copy/dualcpu_separateconfig or how to make this example running.

Thanks in advance, Joern.

  • 0
    Genius 3055 points

    I am one step further now, it's no clean solution of the problem, but for the very next time it helps.For the case someone runs into the same problem:

    Because C6Accel succesfully builds and uses the IUNIVERSAL interface and the build results include valid linker.cmd and compiler.opt files I combined the steps for using C6Accel for a simple, XDC-free GNUmake project with the universal_copy sample, from which additionally to app.c I had to take some parts from the generated app_remote_xv5T.c to change the Engine_config content to fit my needs. Also the ti-wiki description of the GNUmakefile usage if C6Accel is faulty, as soon as I have some deeper insights I will change that. If someone needs more details, feel free to ask, maybe I would start to document my steps already at this early stage within the ti-wiki then...

    What remains for me will be to write a XDC-based module as a wrapper to the codec functions I am writing, if the build succeeds it should deliver all necessary files to make use of that module from a GNUmake based project.

    Maybe the C6Accel API provides the same, only more comfortable and more common, but at least at the first look it seemed much easier for me to write a codec with some time-consuming functions than to add those functions to the C6Accel framework.

    I understand the reasons for building this RTSC framework. But on the other side I think that it is a typical application as well, that one has a huge existing project, from which a part will be used for the embedded platform at ARM side, with only some little changes, and the want to handle the time consuming functions of this part by the DSP. In such a case all you need is to implement these functions within a RTSC codec project and to get easily a wrapper library for accessing these functions. At the moment C6Accel seems oversized to me, concerning this simple need. Let's see, what I am thinking some weeks later...

  • 0 in reply to Joern
    Genius 3055 points

    In the meanwhile I asked a very similar question again and got it answered, see here:

    Get use of a CE codec compiled into an existing GNUmake project...

    It enabled me to clean the dirty solution above, I got configuro running now almost as wanted (one open question, see the above linked thread).

    So this thread here can be seen as answered.

    Thanks and regards,

    Joern.