Forums

Mukesh,

I am not aware of the DSP loop application you are refering to, does this application configure any peripheral and get some data from it? If not, the dsp side algorithm can be wrapped in the iUniversal framework and integrated with the code server. A good starting point to go through this process is described here:

http://processors.wiki.ti.com/index.php/Getting_started_with_IUNIVERSAL

Hope this helps. Good luck !!!

Regards,

Rahul

thanks for your response.

the loop application that i mentioned, has two binaries. one runs on arm and sends some data to the dsp, after loading the dsp side binary, which in turn sends that data back to the arm. the arm side binary then checks the integrity of the data received and prints the result.

I have modified the dsp side application to receive the data through mcbsp (I/O operation) peripheral and send it to the arm. I have already successfully run this application separately, it is working absolutely fine.

Now, again i am stuck on the same point as before. i want to create one single binary  for this application as well as codec server that could be loaded on the dsp by the arm side application.

In this case, I don`t think you should explore the option of iUniversal. Codec engine is not suited for application that are using DSP drivers as described here:

http://processors.wiki.ti.com/index.php/When_to_use_and_when_not_to_use_Codec_Engine 

To use the codec server your best chance would be to modifying the app so that ARM manages the IO while DSP does the computation? I am not sure how easy it would be for you modify that. If not you would have to create a custom app that builds on DSPLINK to enable this kind of functionality. Let me move the post to the Linux forums to see if someone has a better solution for you.

Regards,

Rahul

May be I am not able to put forward my idea clearly.

let me explain everything properly once again. I am working on a VOIP solution project.

We will use Arm as master and DSP as slave.

DSP would be used for 3 things:

1. Codec conversion, using codec server(provided by TI).

2. Tone(DTMF,MFC etc) Generation, using TGE component of VOLIB (also provided by TI).

3.Tone Detection, using TDU component of VOLIB (also provided by TI).

for this the TDM data would be received and trasmitted by DSP using MCBSP peripheral(which would be under the control of DSP).

ARM would be used for:

1. Hosting Codec Engine.

2. Executing the main application, that would control the flow of TDM data to be sent or received from the DSP. This data could be sent for codec conversion, or Tone Detection. This application will also load the single binary to be run on the DSP (to carry out the above mentioned DSP tasks).

Thus, to build a single DSP binary, i need to somehow integrate the application carrying out the Tone related tasks, Mcbsp access as well as the codec server that resides on the DSP.

To sum up My requirements, I need VOLIB(TGE and TDU), Codec Server, MCBSP driver, and DSP side application in a single binary(DSP).

Hi Mukesh,

My suggestion would be for you to write your application based on the Dsplink loop example. Set it up so that you can send a message over to the DSP side which then runs Codec Engine in a 'local' configuration (ie. the VISA API is called on the DSP side which directly talks to the codecs). In this manner, you will not need a 'DSP server' executable, and instead you just have a DSP executable that handles everything including calling the VISA API for codec conversion. If you check out the Codec Engine examples (e.g. video_copy) you will see examples running on a single core that show how to configure CE for 'local' execution.

Best regards,

Vincent

Thanks for your suggestion.

I have compiled Codec Engine examples (e.g. audio_copy) for OMAPL138 in APP_LOCAL mode (i.e codec engine and server) in same binary . Now i want to merge audio_copy( Codec Engine examples ) with my dsplink custom application( discussed earlier).

How can i achieve this.

Hi Mukesh,

This is what I expect you'd have to do:

- Make sure both your dsplink application and the CE example work by themselves. It's better to start with working code.

- Merge the contents of the 'local.tcf' file with the tcf file that you already have for your dsplink application. You'll need to go through the 'local.tcf' file and resolve any conflicting configuration it may have with your dsplink application's. Refer to DSP/BIOS documentation if you need help with BIOS configuration.

- Merge the 'main' function in the CE example with the one for the DSP-side in your dsplink application.

- Modify your DSP-side makefiles to run the configuro utility (details on http://rtsc.eclipse.org/docs-tip/Command_-_xdc.tools.configuro) on your .cfg file. It will generate the 'compiler.opt' and 'linker.cmd' files that you will need to use in the next step. If you have the DVSDK for omap-l138 installed there are examples that show usage of configuro as well in the DVSDK demos' makefiles. Or you can refer to the CE example in apps\video_copy\configuro. Look at the makefiles in any of the subdirectories and you will see configuro being used.

- Modify your DSP-side makefiles to rebuild your application along with the ".c" files that are in the CE example (minus the main function assuming you have merged it with your own). Compile the DSP side executable using the options in 'compiler.opt' in addition to the existing ones, and similarly link it using the options in 'linker.cmd' in addition to the existing ones.

- Run the application. If you merged the main function properly, the DSP should run the CE example in addition to what it was supposed to do originally.

Best regards,

Vincent

Hi Vincent,

Thanks for your quick response.

I created a makefile as per your suggestion.

while run configuro on local.cfg file, I am getting an error.

output log is as follows:-

sh /opt/ti/xdctools_3_23_00_32/xs xdc.tools.configuro -t ti.targets.C674 -p  ti.platforms.evmOMAPL138 -c "/opt/ti/ccsv5/tools/compiler/c6000" /root/Desktop/local.cfg
making package.mak (because of package.bld) ...
configuring local.x674 from package/cfg/local_p674.cfg ...
js: "/root/Desktop/DVSDK/codec-engine_2_26_02_11/packages/ti/sdo/ce/osal/bios/package.xs", line 54: TypeError: Cannot call method "instances" of undefined
gmake: *** [package/cfg/local_p674.xdl] Error 1
js: "/opt/ti/xdctools_3_23_00_32/packages/xdc/tools/Cmdr.xs", line 51: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted.
make: *** [all] Error 1

Hi Mukesh,

It looks like your configuro invocation is missing some information for the tool to resolve some of the BIOS modules. Could you try adding the flag '--tcf' to the configuro invocation, just before specifying the cfg file? Make sure your DSP executable's tcf file is right next to the cfg file, and has the same filename (e.g. name it local.tcf for local.cfg).

Best regards,

Vincent

Thanks for reply,

I have run configuro on local.cfg succesfully. I got linker.cmd and compiler.opt.

After adding compile.opt and linker.cmd files in my dsplink project, I am getting some error.

   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "hwi12" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "hwi15" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "hwi14" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "ECM_ENABLE" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "KNL_swi" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "PWRM_PWRM_SCALING" redefined: first defined in
   "./loopcfg.obj"; redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "MEM_gNumHeap" redefined: first defined in
   "./loopcfg.obj"; redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "TSK_idle" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "CLK_null" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "GBL_L2MODE" redefined: first defined in "./loopcfg.obj";
   redefined in
   "/root/Desktop/root/Desktop/local/package/cfg/local_x674cfg.o674"
error #10056: symbol "KNL_swi$sts$avgfmt" redefined: first defined in
   "./loopcfg.obj"; redefined in

Hi Mukesh,

The errors say you are trying to link two object files that have the same BIOS symbols. I believe one of them is generated by configuro (most likely local_x674cfg.o674 since it is under the 'package directory) and it is listed in linker.cmd. That one is needed by your project. The other one (loopcfg.obj) is probably generated because your original DSPLINK project was interpreting the .tcf file and linking in the resulting file. You no longer need to do that since configuro has already processed your .tcf file. So make sure your makefile(s) no longer refers to the tcf file (or the loopcfg.obj file), except for the configuro command.

Best regards,

Vincent

Thanks a ton Vincent!! our codec engine is being run on DSP now and i am able to encode/decode my data successfully.

Now, I have another issue in front of me, and seek your advice regarding the same.

I am trying to send RTP packets to the DSP from arm, and have to do the encoding/decoding on those packets. For this i am using DSPLINK and its components. The question that is troubling me is that what should be the transport mechanism for efficient and fast data transmission between the ARM and DSP.

Till now i was using CHNL component for data transfer, however it seems that it is too slow as per our requirements. Could you please advice me on this issue, whether i should stick to the same component or switch to some other like RINGIO, MSGQ etc.. Or could you guide me on the evaluation of the component's performance regarding the before mentioned matter.

Hi Mukesh,

Glad to hear you managed to get CE running locally. Regarding your question, the answer would depend on your use case. With MSGQ, you can put your packets into shared memory (between ARM and DSP) and simply send pointers to the packets across using messages. Different packets can reside in disjoint memory areas. This is convenient especially if you have data already residing in the shared memory (e.g. if you have your driver set up to store data in the shared memory, then there'd be no copying involved), so the cost would simply be to create the message with the pointer, send a notification interrupt across, service the interrupt at the receiver, and extract the data from the message. There will also be cache maintenance involved on one or both sides if cache is enabled, and maybe the need to send the consumed buffer back to the sender..I'd expect this approach to be faster than using CHNL if you had to copy data into CHNL-owned buffers.

RingIO uses a circular buffer as a transport, and is a bit more specialized. Typically I see it used for audio data. It is good for scenarios where the reader and the writer operate at approximately the same rate, in which case the buffer rarely becomes full or empty, the reader and writer can be agnostic of one another, and there would be no need for many interrupts to be sent across (as opposed to MSGQ which needs to send an interrupt every time a message is sent). However, if the two sides work at different rates, one side would constantly wait on the other, potentially resulting in more interrupts, in which case the performance may be worse than if you simply use MSGQ because RingIO also needs to deal with extra features like buffer wraparound, attribute buffer, notification conditions, etc.

My suggestion would be to pick the model that is most natural to your use case. If you are unsure, you can start with MSGQ and see if the performance suits you, and go from there.

Best regards,

-Vincent

Hi Vincent, thanks for your response.

i have data of 32 channels(RTP voice channels) that i have to send to dsp simultaneously, on which encoding/decoding will be done. Now, i have three options to implement this. First, i could use MSGQ to transfer the RTP buffer. Second, I could use CHNL to transfer the buffers and MSGQ to send control messages(similar to scale application provided in the dsplink samples). Third, i could use MSGQ for messaging and PROC to transfer or copy the RTP data to DSP(somewhat similar to the readwrite example application in dsplink samples).

However, i am still wondering which one would be the best approach. or, is there any other option that i could use.

My gut feeling is that doing zero-copy pointer passing (as I described in my previous post) with your data using MSGQ would be the most efficient, given it does not require copying the data. If you want to be sure however you'd have to try out the various options yourself. Your results may vary depending on packet sizes. In my opinion the PROC approach will give you the worst numbers, since DSPLINK will be making a copy of the data for you.

Best regards,

Vincent