DSP Lib (.l64P) in xDAIS

JT,

I created an example application to call a DSPLIB app from ARM Linux via DSPLINK.  It doesn't use XDAIS, but it sounds close to what you need:

http://wiki.davincidsp.com/index.php/Example_DSPLIB/DSPLink_Application_on_OMAP-L1x

This app will only run on OMAP-L1x.  Porting it to other devices may be a fair amount of work, since you'd need to swap in another DSPLIB.  (The library currently used by the app is only compatible with C674x DSPs.)

Since you're already using an XDAIS alg (great!), you might check this article:

http://tiexpressdsp.com/index.php/Getting_started_with_IUNIVERSAL

Chris

Hi Joe,

Thanks for the info., I have to stick on XDAIS since we have an existing engine/codec. Though, I was getting a hard time to find a documentation on adding a DSP library on XDAIS.

Any idea where to get a good info for adding library on XDAIS?

JT

Hi Chris,

I should have mentioned the library that I want to put it in XDAIS. I want to use the TI's VLIB (Vision Library vlib.I64P) API to do vision tracking.

Do you think IUNIVERSAL is the right one to integrate the said library?.

Thanks,

JT

I'm not familiar with VLIB, so others can trump me if they want.  [:)]

IUNIVERSAL is pretty much "you're on your own to define whatever you want" and should work for you - but you have to spec the entire API.  It _may_ be interesting to consider something like IVIDENC1 (Video Encode) which is already set up to take raw video buffers as input and generate a bitstream as output.  Perhaps your "bitstream" output buffer(s) could contain details returned by VLIB?

Just my [barely educated] 2 cents.  Trump away.

Chris

That's correct.

I've read using XDAIS can easily ported the existing DSP Library and no need to really understand the API when implementing it. This is what I need for now, I need to make the VLIB available to linux and make an funcation call after I've done implementation.

I'll check the IUNIVERSAL and looks like I could get more info.

John

Hi Chris,

In the old XDAIS, in order to put a DSP library you need to create a skeleton and stubs.

How about in IUNIVERSAL, is it required to create a skeleton and stubs too?

John

In short, no, you don't have to create these yourself.

Stubs/skels are only required if you're using Codec Engine, and running the alg 'remotely' (i.e. on a processor other than the one your app is on).  In that case, _someone_ has to provide stubs/skels.

If you're using an XDM interface (e.g. IVIDENC1, IAUDDEC1, IUNIVERSAL, etc), Codec Engine provides the stubs/skels for you (and handles all the related, messy address translation and cache management).  Your only requirement is to implement exactly that interface.

If you're inventing your own XDAIS-compliant interface, you can still create your own stubs/skels.  But this is a headache, and exactly why we created IUNIVERSAL... so you have one less headache.  [;)]

Chris

I'm kind a lost right now. I read a bunch of stuff and my mind is floating.... may be you can enlighten me up... :)

My goal is this:

I want to use the VLIB library. The VLIB provides only a vlib.I64P and .h (function prototype), no source code and no stubs/skels.

Since, I need to run the function remotely (DSP), I have to create a stubs/skels, am I right?.

1. Is it possible to create a skels/stubs even I don't have a source code?

2. If the library didn't pass in QualiTI, is it possible to use XDAIS even the said library is non-compliant?. If not, is there any other way to force it and use XDAIS interface?

3. Creating a stubs/skels is very painful, is there any other way that I could load, run the dsp library and take advantage of it without spending too much on how to create stubs/skels?.

Thanks,

John

There are a couple ways to skin it - here's what I'd try first... making this up as I go, and not compiling any of this, so cut me a little slack please...  [:P]

Read this and refer to it often - http://tiexpressdsp.com/index.php/Getting_started_with_IUNIVERSAL .  (Please edit it if you see issues or want to add your findings!)

Understand this as you'll be 'extending' the predefined structs - http://tiexpressdsp.com/index.php/Extending_data_structures_in_xDM

Assuming VLIB is "just a bunch of standard function calls", I might treat each fxn call as a UNIVERSAL_process() call.  To differentiate which fxn to call, I might add an extended inArgs field called "functionIndex" so my alg knows which fxn to call.  Function input args should be added to the extended inArgs struct.  Output could be returned via the outArgs output struct.  Any pointers should be passed via inBufs/outBufs/inOutBufs as appropriate.

So, concretely, let's say VLIB has 2 fxns:

• int VLIB_multiplyThis(int a, int b);
• int VLIB_scaleThis(int a2, char *buf);  // where buf is an in/out buffer
  

You might create an extended MYIUNIVERSAL_InArgs like this:

typedef struct MYIUNIVERSAL_InArgs {
    IUNIVERSAL_InArgs base;
    XDAS_Int32 functionIndex;
    XDAS_Int32 arg1;
    XDAS_Int32 arg2;
} MYIUNIVERSAL_InArgs;

And outArgs like this:

typedef struct MYIUNIVERSAL_OutArgs {
    IUNIVERSAL_OutArgs base;
    XDAS_Int32 result;
} MYIUNIVERSAL_InArgs;

My implementation of IUNIVERSAL_Fxns::process() might look something like this...

switch (inArgs->functionIndex) {
    case MYIUNIVERSAL_MULTIPLYTHIS:
        outArgs->result = VLIB_multiplyThis(inArgs->arg1, inArgs->arg2);
        break;

    case MYIUNIVERSAL_SCALETHIS:
        outArgs->result = VLIB_scaleThis(inArgs->arg1, inOutBufs->descs[0].buf);
        // don't forget, since VLIB_scaleThis wrote into inOutBufs with the CPU, you
        // have to indicate this in the buffer descriptor!  (so cache maintenance is done right)
        XDM_SETACCESSMODEWRITE(inOutBufs->descs[0].accessMask);
        break;
    ...
}

Build and integrate your alg as the article describes.  The call it from your app like this:

MYIUNIVERSAL_InArgs inArgs;
MYIUNIVERSAL_OutArgs outArgs;

inArgs->size = sizeof(inArgs);
outArgs->size = sizeof(outArgs);

inArgs->functionIndex = MYIUNIVERSAL_MULTIPLYTHIS;
inArgs->arg1 = 3;
inArgs->arg2 = 2;

result = UNIVERSAL_process(hMyAlg, NULL /* inBufs */, NULL /* outBufs */, NULL /* inOutBufs */,
        &inArgs, &outArgs);

/* result should have the output of calling VLIB_multiplyThis(3, 2) */

Hope that helps frame the story a bit.

Chris

Hi Chris,

Thanks for the info.

I checked the requirements for IUNIVERSAL and it's not compatible to my existing configuation.

I am using Montavista 2.6.10 kernel, dvsdk_1_30_01_41 and mv_pro-4.0.1

My follow up question with you is, do you have another idea to recommend in order to solve my problem?

Thanks,

John

Hi Chris,

I set my configurations correctly and able to compile the iuniversal_example and produced .x64P. I checked the codes of codec fir and randgen and the two have a source for the algorithm (xxx_ti_ialg.c).

I copied the randgen and called it videolib and updates all the .xdc, .bld, .xs etc and able to produced a videolib.I64P. The implementation of IUNIVERSAL_process is in the xxx_ti_ialg.c where I should call the VLIB functions.

Now, let say the two function above, VLIB_multiplyThis() and VLIB_scaleThis() are stored in vlib.I64P library. How do I link the vlib.I64P to videolib?

Thanks,

john

I was able to include the vlib.l64P by appending the archives library. I can generate an codec engine now...

-john

JT said:

I was able to include the vlib.l64P by appending the archives library. I can generate an codec engine now...

To make the above statement more clear for someone else who might come across this thread (such as myself last week), you need to add the library to the linker command line.  This is done by config.bld to something like this:

var Build = xdc.useModule("xdc.bld.BuildEnvironment");
var Pkg = xdc.useModule("xdc.bld.PackageContents");

/* set the location of your codegen tools here */
var cgToolsDir = "/opt/TI/cg6x";

var C64P = xdc.useModule("ti.targets.C64P");
C64P.rootDir = cgToolsDir;
C64P.ccOpts.suffix += "-mi10 -mo ";
C64P.ccOpts.suffix += " -I./extlib/VLIB_V_2_1/include";
C64P.lnkOpts.suffix += " -i=extlib/VLIB_V_2_1/library/c64plus";
C64P.lnkOpts.suffix += " -l=vlib.l64P -l=vlib_errChk.l64P -l=imglib2.l64P ";
Build.targets.$add(C64P);

For benefit of people who might come across this thread. Integration of DSPLIB in xDAIS has been done in the new tool C6Accel offered by TI. The tool contains several key DSPLIB kernels and provides docuentation to add more kernels to the xDAIS algorithm

The tool can be downloaded from

http://focus.ti.com/docs/toolsw/folders/print/c6accel-dsplibs.html?DCMP=DSP-C6RunAccel-092110&HQS=Other+PR+c6accel-prtf

The documentation for this tool is available on

http://processors.wiki.ti.com/index.php/C6Accel:_ARM_access_to_DSP_software_on_TI_SoCs

Regards,

Rahul

I'd also like to add that we recently released C6Accel which integrates a bunch of DSP algorithms into an ARM-callable library.  It's built on the IUNIVERSAL interface and so it can integrate with other algorithms in Codec Engine:

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

From my experience it's no problem to build an own IUniversal codec implementing some own functions, and as well it's relatively easy to get them accessed from an application via CodecEngine. This all best by starting from the universal_copy CE sample from within the EZSDK.

The main problems to me have been resp.  yet are:

1. How to get the codec access via CodecEngine into a library or object which contains all XDC generated stuff and can be linked to a usual, non-XDC project. This would have been partially answered by the CE sample video_copy/dual_config from the current EZSDK, if it was working. I got it working, at least after receiving some helpful answers within this thread.
2. How to get an existing lib from the TI world, like DSPLIB, cleanly linked to an XDC managed codec project. I have a lib description, I have a header found by grep, but don't know which two or three lines I have to add to my XDC project file to get it linked.

It was a nice thing if these two connections between XDC and the rest of the world would have been described anywhere here or within the TI wiki... If you know the current place of such a description, please let me know.

Regards,

Joern.

Joern said:

• How to get the codec access via CodecEngine into a library or object which contains all XDC generated stuff and can be linked to a usual, non-XDC project. This would have been partially answered by the CE sample video_copy/dual_config from the current EZSDK, if it was working. I got it working, at least after receiving some helpful answers within this thread.

The XDC team created the "closure tool" for this purpose:

http://rtsc.eclipse.org/docs-tip/Command_-_xdc.tools.closure

Joern said:

• How to get an existing lib from the TI world, like DSPLIB, cleanly linked to an XDC managed codec project. I have a lib description, I have a header found by grep, but don't know which two or three lines I have to add to my XDC project file to get it linked.

Can you clarify on what exactly you're doing?  There are various scenarios:

1. Creating an application (executable)
   1. Using configuro
   2. Using "pure" RTSC build
2. Creating a RTSC package (library), but need to call a dsplib function as part of the processing

Well, I suppose all the cases should probably be covered.  Let me see if I can do it...

1a.  This would be the easy case since all the "RTSC stuff" is performed during the configuro step.  You just added the proper include path and library to your project/makefile and proceed as normal.

1b.  I guess you would need to "wrap" the library to turn it into a RTSC package in this case.  I imagine not many people are writing their code this way, and if they are then this shouldn't be tough for them to do!

2.  Adding the directory of the include files to the "package path" will generate the necessary -i options for the compiler.  One would need to write/modify getLibs() to reference the library itself too.

Joern,

Is this question specific to C6Accel or Are you creating your own codec that needs to access a DSP library via codec engine on the ARM? It is unclear what library (DSPLIB or XDAIS algorithm library)and header you have found through grep, can you describe your setup?

All XDC related basics and interfacing is described here: http://rtsc.eclipse.org/docs-tip/Main_Page.

More specifically programming flow is described here: http://rtsc.eclipse.org/docs-tip/The_RTSC_Flow 

Regards,

Rahul

Thanks for the hint to the closure tool, I'll have to work this through, in contrast to the way offered by the video_copy/dual_config sample...

What I am exactly doing is:

• Writing a codec,  based on the universal_copy sample. This codec handles some image data and will be able to do some complex analysis, which can be called by giving a function ID together with the input data (image data, analysis patterns, other parameters). I have to write these functions within a codec because we will have to use other, already existing codecs at the same platform as well.

• For the image analysis I have to do optimization on DSP side, concerning memory usage, loop optimization, some information is to be found within the processors wiki. The EZSDK 5.01 comes with c674x-dsplib_1_03_00_00, which looks interesting for me as it seems to provide optimized functions being basically enough to fit some of my needs. Now I have to link this library to my codec. I've read this entry of this thread, of course, but I am wondering if there is no more common way to introduce such a library or if there is possibly a predefined RTSC module covering the DSPLIB interface? The point is, that with plain makefile projects I would know what to do, with RTSC I am always digging for information on how to tell it the RTSC mechanisms...

• I may run and test this codec from ARM side via a simple RTSC-generated app, but afterwards I need a simple C library which covers the CodecEngine handling and the parameter preparation and finally the calls of my codec's functions. I wrote a small wrapper for this (following the video_copy/dual_config sample) and my only problem at that point was the incorrect settings within the sample files of this CE sample (which already has been solved within this thread). I need this way because on ARM side works software built from a huge GNUmakefile-controlled project (C++) with no chance to ever being transferred to an XDC/RTSC-controlled project.

Thanks for all hints already given. I am hopefully that I will get this solved - if being at this point probably I will create the first clear documentation of the how-to of this - in my opinion - typical need.

Best regards,
Joern.

Joern said:

The EZSDK 5.01 comes with c674x-dsplib_1_03_00_00, which looks interesting for me as it seems to provide optimized functions being basically enough to fit some of my needs. Now I have to link this library to my codec. I've read this entry of this thread, of course, but I am wondering if there is no more common way to introduce such a library or if there is possibly a predefined RTSC module covering the DSPLIB interface? The point is, that with plain makefile projects I would know what to do, with RTSC I am always digging for information on how to tell it the RTSC mechanisms...

It sounds like the last piece of the puzzle is to ensure that, whenever your codec is used in an application, the appropriate dsplib is also linked into the same application.  This can be done several ways.  Perhaps the cleanest from a RTSC point of view is to "wrap" the dsplib library in its own package and specify in your codec package that it requires this dsplib wrapper package.

A bit of background:

• every RTSC package can "provide" one of more libraries that must be linked into applications using the package
• RTSC packages "provide" these libraries by adding a file named package.xs that defines a function named getLibs() that simply returns the names of the libraries that need to be linked into the application
• the RTSC configuration tool generates a linker command file that contains the names of the libraries returned by all getLibs() functions from all packages used by an application.

If you create a wrapper for dsplib, say wrapper.dsplib, you simply need to add the following statement to your existing codec package's package.xdc file:

requires wrapper.dsplib;

Doing this will force the wrapper.dsplib package to be used whenever your codec is used.  This in turn ensures that the generated linker command file will name dsplib whenever your codec is used. 

If this approach sounds viable, I can post a complete implementation of this wrapper package. 

Alternatively, your codec package can provide its own getLibs() that simply returns the path to the appropriate dsplib library along with your codec libraries but, as you point out, other codecs will have a similar need.  So, it's best to encapsulate the logic required to get dsplib into the generated linker command file to one place that all codecs can use.

Finally, once we arrive at a good solution, I'm happy to write a FAQ that describes the solution.

Thanks for your explanation, it gives me the certainty to be on the right track!

And yes, the common wrapper approach is what I would prefer. Not only to have a more common solution in THIS case for the DSPLIB only, but much more as it seems to me as a typical need for the RTSC world: How flexible, handy, comfortable and whatever else the RTSC world is, it needs bridges to other programmers' worlds to be applicable with existing projects. And the "common, flat makefile world" in my opinion is the best destination for those bridges from and to the RTSC world, because especially for common makefile based projects already lots of bridges to several other development environments are existing.

So if actually you would be so kind and post a solution of a RTSC wrapper for the DSPLIB it was not only a solution for that library being helpful for others, but could be a helpful sample to do the same for other libraries, too, especially, if covered by an explanation, maybe best within the Wiki... that would be great.

Joern said:

Thanks for your explanation, it gives me the certainty to be on the right track!

And yes, the common wrapper approach is what I would prefer. Not only to have a more common solution in THIS case for the DSPLIB only, but much more as it seems to me as a typical need for the RTSC world: How flexible, handy, comfortable and whatever else the RTSC world is, it needs bridges to other programmers' worlds to be applicable with existing projects. And the "common, flat makefile world" in my opinion is the best destination for those bridges from and to the RTSC world, because especially for common makefile based projects already lots of bridges to several other development environments are existing.

I completely agree.  We have some documentation about integrating with make but not nearly enough.

Joern said:

So if actually you would be so kind and post a solution of a RTSC wrapper for the DSPLIB it was not only a solution for that library being helpful for others, but could be a helpful sample to do the same for other libraries, too, especially, if covered by an explanation, maybe best within the Wiki... that would be great.

I've created a first draft of a wiki article here: http://rtsc.eclipse.org/docs-tip/Integrating_Existing_Content/Example_1.  There are many ways to wrap existing content so I expect there will be more than one approach that's useful.  As you can see from the topic name, I expect we'll want to create more than one example.

Comments are very welcome. 

Hi Dave,

thanks a lot, these your new Integrating Existing Content RTSC-Pedia articles look promising that they will fill actually that gap we discussed about. I am yet following Example 1, if any questions or hints will remain, I will write that here.

A little off-topic I want note here, that actually often I wished to be able to make small comments to a RTSC-Pedia article, or to hint concerning a typo. Maybe I am blind, but for me it seems that I have not chance to create an account to be enabled to change or at least to comment. I find it no bad idea to limit the edit rights to a smaller group of contributors or even to the creator of an article, as maybe this is a better way to get thought-out articles. But it was nice, if the system behind would at least allow accounts for small annotations.

So here, a very small annotation about possible typos at Integrating Existing Content: Instead "So, it important that the RTSC user be able to easily integrate [...]" I'd suggest "So, it's important that the RTSC user is able to easily integrate [...]" - sorry if I'm wrong, I am no native English speaker, but now I have these small stumbling-stone-hints out of my head, ;-) that was the only reason to spend so much words on it.

Again, thanks a lot,
best regards,
Joern.

Joern said:

Hi Dave,

thanks a lot, these your new Integrating Existing Content RTSC-Pedia articles look promising that they will fill actually that gap we discussed about. I am yet following Example 1, if any questions or hints will remain, I will write that here.

Perfect!  Any comments/corrections would be appreciated.

Joern said:

A little off-topic I want note here, that actually often I wished to be able to make small comments to a RTSC-Pedia article, or to hint concerning a typo. Maybe I am blind, but for me it seems that I have not chance to create an account to be enabled to change or at least to comment. I find it no bad idea to limit the edit rights to a smaller group of contributors or even to the creator of an article, as maybe this is a better way to get thought-out articles. But it was nice, if the system behind would at least allow accounts for small annotations.

I can get you a login so you can make changes.  We had to shut down automatic account creation due to some very heavy spamming :(.

Joern said:

So here, a very small annotation about possible typos at Integrating Existing Content: Instead "So, it important that the RTSC user be able to easily integrate [...]" I'd suggest "So, it's important that the RTSC user is able to easily integrate [...]" - sorry if I'm wrong, I am no native English speaker, but now I have these small stumbling-stone-hints out of my head, ;-) that was the only reason to spend so much words on it.

Thanks!  I apologize for the typo's, I rushed it out so as not to delay your work.  I'll make these changes. 

If you send me an email at d-russo at  ti dot com, I'll send you an account and password for the RTSCpedia.

Hi,Brad

I have read the lesson in the URL  http://rtsc.eclipse.org/docs-tip/Integrating_Existing_Content/Example_1,

but still have some problems.

Brad Griffis said:

Can you clarify on what exactly you're doing?  There are various scenarios:

1. Creating an application (executable)
   1. Using configuro
   2. Using "pure" RTSC build
2. Creating a RTSC package (library), but need to call a dsplib function as part of the processing

Brad Griffis said:

2.  Adding the directory of the include files to the "package path" will generate the necessary -i options for the compiler.  One would need to write/modify getLibs() to reference the library itself too.

 

I want to use a normal Library(C language non-XDM) in a codec.

For example, I have the mylib.h and mylib.lib file made in CCS, and I want use this lib in my codec.

First, I make a RTSC package(mycompany.mylib) follow the lesson above.

For my codec, I included the mylib.h into the codec.c file, and add requires mycompany.mylib in the package.xdc files.

The functions in mylib.lib still cannot be found when I built the DSP server project.

I have tried to modify the getLibs function in DSP server, still cannot work.

How to fix my problem?

Are you sure that this library has been built for the same platform as for which you are building your codec? And same calling conventions?

I assume, that Dave's example you mentioned above should be enhanced concerning those aspects, as the RTSC framework allows to provide packages for different platforms and to specify for which the package deliveres valid content... (if I understood that right, that's one of the main purposes of this RTSC framework).

Regards,
Joern.

song said:

I want to use a normal Library(C language non-XDM) in a codec.

For example, I have the mylib.h and mylib.lib file made in CCS, and I want use this lib in my codec.

First, I make a RTSC package(mycompany.mylib) follow the lesson above.

For my codec, I included the mylib.h into the codec.c file, and add requires mycompany.mylib in the package.xdc files.

The functions in mylib.lib still cannot be found when I built the DSP server project.

I have tried to modify the getLibs function in DSP server, still cannot work.

How to fix my problem?

Make sure that you rebuild the codecs that have the new "requires mycompany.mylib" statement.

You can verify that your mycompany.mylib package's getLibs() function is being run by placing a "print(...)" statement in the getLibs().  For example:

function getLibs(prog) {

    print("mycompany.mylib getLibs() returning ./lib/mylib.lib ...");

    return ("./lib/mylib.lib");

}

During the build of the server you should see the output of the print() statement above.

Thanｋ you, sir.

First I have a question about if my library file could be used in codecs.

My library is just a C function. I made the library use CCS in windows. (make a static library project for C674x device, and my board is C6a8168).

I copied lib file and h file to linux, and try to test how to make it work. (The Codec Generation tools versions in windows and Linux are different, is this OK?)

If it's OK, I will show how I tried.

a0783929 said:

Make sure that you rebuild the codecs that have the new "requires mycompany.mylib" statement.

You can verify that your mycompany.mylib package's getLibs() function is being run by placing a "print(...)" statement in the getLibs().  For example:

function getLibs(prog) {

    print("mycompany.mylib getLibs() returning ./lib/mylib.lib ...");

    return ("./lib/mylib.lib");

}

During the build of the server you should see the output of the print() statement above

Yes, I have checked those.

My codec is called bi2vision.errcalc, and I change the universal_copy example in codecs to build this codec. It worked.

Then I want to use some librarys in my codec, so first I make another package under errcalc floder called bi2vision.errcalc.gray.

1. put the h file under bi2vision/errcalc/gray floder, then the lib file in  bi2vision/errcalc/gray/lib floder.

2.make package.xs like this

function getLibs(prog)

{

    var name = "";

    var suffix = "";

    /* And finally, the location of the libraries are in lib/<profile>/* */

    name = "./lib/gray_bi2vision.lib";

/* and dump a helpful breadcrumb */

    print("====--look--====--look--==== will link with " + this.$name + ":" + name + "  ====--look--====--look--====");

    return (name);

}

package.xdc file

package bi2vision.errcalc.gray [1, 0, 0] {

}

package.bld file

var Pkg = xdc.useModule('xdc.bld.PackageContents');

Pkg.attrs.exportAll = true;

makefile

RULES_MAKE := $(CE_INSTALL_DIR)/../Rules.make

ifneq ($(wildcard $(RULES_MAKE)),)

include $(RULES_MAKE)

endif

CGTOOLS_C674=$(CODEGEN_INSTALL_DIR)

XDCARGS= CGTOOLS_C674=\"$(CGTOOLS_C674)\"

XDCPATH=$(XDAIS_INSTALL_DIR)/packages

all:

"$(XDC_INSTALL_DIR)/xdc" XDCOPTIONS=$(XDCOPTIONS) XDCARGS="$(XDCARGS)" --xdcpath="$(XDCPATH)" release

clean:

"$(XDC_INSTALL_DIR)/xdc" XDCOPTIONS=$(XDCOPTIONS) clean

3. modify the codec, here I don't know which part should I change, bi2vision.errcalc or the universal_copy example in TI's codecs example folder.

a. first include the h file in main c file of bi2vision.errcalc

b. package.xdc file in ti's codec example folder

requires bi2vision.errcalc.gray; /*! * ======== package.xdc ======== * IUNIVERSAL-compatible algorithm. * * This algorithm is compliant with the ti.xdais.dm IUNIVERSAL interface. */ package bi2vision.errcalc [1, 0, 0] { }

Then make clean and make codec.

I will get some warnings such as differ in signedness.

Then I make the server. I got the undefined symbol error.

   will link with bi2vision.errcalc:lib/debug/errcalc.ae674

====--look--====--look--==== will link with bi2vision.errcalc.gray:./lib/gray_bi2vision.lib  ====--look--====--look--====

cle674 package/cfg/bin/ti_platforms_evmTI816X/errcalc_codec_DSP_xe674.c ...

"package/cfg/bin/ti_platforms_evmTI816X/errcalc_codec_DSP_xe674.c", line 6340: warning #225-D: function declared implicitly

cle674 main.c ...

lnke674 bin/ti_platforms_evmTI816X/errcalc_codec_DSP.xe674 ...

warning: creating output section ".plt" without a SECTIONS specification

 undefined           first referenced                                                                                                                   

  symbol                 in file                                                                                                                        

 ---------           ----------------                                                                                                                   

 rgb2gray            /home/dsp/ti-ezsdk_c6a816x-evm_5_00_00_56/codec-engine_3_21_00_02/examples/bi2vision/errcalc/lib/debug/errcalc.ae674<errcalc.oe674>

 rgb2gray_table_init /home/dsp/ti-ezsdk_c6a816x-evm_5_00_00_56/codec-engine_3_21_00_02/examples/bi2vision/errcalc/lib/debug/errcalc.ae674<errcalc.oe674>

error: unresolved symbols remain

I think you simply need to change graph_bi2vision.lib to be built as ELF rather than COFF.  It looks like everything else is ELF.

song said:

I copied lib file and h file to linux, and try to test how to make it work. (The Codec Generation tools versions in windows and Linux are different, is this OK?)

It should be ok.  Libraries and object files can be built and used interchangeably between Linux and Windows.

song said:

Then I make the server. I got the undefined symbol error.

will link with bi2vision.errcalc:lib/debug/errcalc.ae674

====--look--====--look--==== will link with bi2vision.errcalc.gray:./lib/gray_bi2vision.lib  ====--look--====--look--====

cle674 package/cfg/bin/ti_platforms_evmTI816X/errcalc_codec_DSP_xe674.c ...

"package/cfg/bin/ti_platforms_evmTI816X/errcalc_codec_DSP_xe674.c", line 6340: warning #225-D: function declared implicitly

cle674 main.c ...

lnke674 bin/ti_platforms_evmTI816X/errcalc_codec_DSP.xe674 ...

warning: creating output section ".plt" without a SECTIONS specification

 

 undefined           first referenced                                                                                                                   

  symbol                 in file                                                                                                                        

 ---------           ----------------                                                                                                                   

 rgb2gray            /home/dsp/ti-ezsdk_c6a816x-evm_5_00_00_56/codec-engine_3_21_00_02/examples/bi2vision/errcalc/lib/debug/errcalc.ae674<errcalc.oe674>

 rgb2gray_table_init /home/dsp/ti-ezsdk_c6a816x-evm_5_00_00_56/codec-engine_3_21_00_02/examples/bi2vision/errcalc/lib/debug/errcalc.ae674<errcalc.oe674>

 

It looks like the server will properly link with the library bi2vision/errcalc/gray/lib/gray_bi2vision.lib.  Since you are still getting undefined symbols, there are two more things to check:

1. verify rgb2gray and rgb2gray_table_init are defined in gray_bi2vision.lib, and if they are
2. verify that either you are using the --reread_libs flag to the linker or that the gray_bi2vision.lib appears after errcalc.ae674 in the generated linker command file used to link the server

To verify 1., you can use the nm6x tool provided with the TI compiler.  Something like the following:

nm6x ./lib/gray_bi2vision.lib | grep rgb2gray

If these are function symbols, you should see something like:

xxxxxxxx T rgb2gray

yyyyyyyy T rgb2gray_table_init

To verify 2., look into the server's linker command file ./package/cfg/bin/ti_platforms_evmTI816X/errcalc_codec_DSP_xe674.xdl.  You should see a list of all libraries, one per line, that will be passed to the linker.  Make sure gray_bi2vision.lib appears after errcalc.ae674.  DON"T EDIT THIS FILE.  It's a generated file and will be overwritten the next time you build the server.  If the order is wrong, try adding the --reread_libs option to the linker; this tells the linker to re-read previously scanned libraries when trying to find symbol definitions.

Thank you for your detailed explanation sir,

I have checked both.

a0783929 said:

To verify 1., you can use the nm6x tool provided with the TI compiler.  Something like the following:

nm6x ./lib/gray_bi2vision.lib | grep rgb2gray

If these are function symbols, you should see something like:

xxxxxxxx T rgb2gray

yyyyyyyy T rgb2gray_table_init

I got the result like this:

000000b0 t $C$DW$L$_rgb2gray$2$B

000001c6 t $C$DW$L$_rgb2gray$2$E

000001c6 t $C$DW$L$_rgb2gray$3$B

000001cc t $C$DW$L$_rgb2gray$3$E

00000014 t $C$DW$L$_rgb2gray_table_init$2$B

0000008c t $C$DW$L$_rgb2gray_table_init$2$E

00000094 T _rgb2gray

00000000 T _rgb2gray_table_init

a0783929 said:

To verify 2., look into the server's linker command file ./package/cfg/bin/ti_platforms_evmTI816X/errcalc_codec_DSP_xe674.xdl.  You should see a list of all libraries, one per line, that will be passed to the linker.  Make sure gray_bi2vision.lib appears after errcalc.ae674.  DON"T EDIT THIS FILE.  It's a generated file and will be overwritten the next time you build the server.  If the order is wrong, try adding the --reread_libs option to the linker; this tells the linker to re-read previously scanned libraries when trying to find symbol definitions.

I found the two library here in right order.

-l"/home/dsp/ti-ezsdk_c6a816x-evm_5_00_00_56/codec-engine_3_21_00_02/examples/bi2vision/errcalc/lib/debug/errcalc.ae674"

-l"/home/dsp/ti-ezsdk_c6a816x-evm_5_00_00_56/codec-engine_3_21_00_02/examples/bi2vision/errcalc/gray/lib/gray_bi2vision.lib"

I will try to make a ELF library as  Brad said.

If it is necessary, I can upload my code here.

Looking forward your reply.

Thank you very much.

yours,

wang

Brad Griffis said:

I think you simply need to change graph_bi2vision.lib to be built as ELF rather than COFF.  It looks like everything else is ELF.

It worked!!

I think I made both COFF and ELF format for my program,

I can see the message like this when I make the codec and server.

C64P_FORMAT=\"COFF ELF\" C674_FORMAT=\"COFF ELF\"

Thank you very much, Brad and a0783929(Sorry, I don't know your name.)

I can not verify answer in this thread, all I can do is to say thanks.