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.

Compiling for C67XX for OMAPL138

Other Parts Discussed in Thread: OMAPL138

I'm developing for an OMAPL138 on linux and have been able to compile, build and run the examples

with the DSP/Bios Link software. To quickly build some test code I copied and modified the readwrite

dsplink example. However I would like to compile this as floating point code for the c6748 side of the

OMAP. It seems the default is to compile for the 64XX. I tried modifying the dsplinkcfg.pl script which

creates the setup makefiles by changing the DSPCLASS and DSPTYPE fields in the OMAPL138GEMSHMEM

configuration. With this change the build system complained about a missing C67XX directory.

To get things to work I changed everything back to 64XX and modified the default file c64xxp_5.xx_linux.mk

file to use the -mv6740 option instead of -mv6400+

 

My question what is the best way to modify the dsplink build code to support float point operations on the

c6748 side of the omap?

 

Thanks,

Bob

  • Bob,

    Unless you're trying to support a completely different target (in which case case you may want to add support for the new device), the correct way to go is the latter approach that you mentioned:

    "To get things to work I changed everything back to 64XX and modified the default file c64xxp_5.xx_linux.mk

    file to use the -mv6740 option instead of -mv6400+"

    Did this work for you?

    Regards,
    Mugdha

  • It appears to be working. I was able to link in a 67x library which previously was giving me an error during linking

    that stated the library was for the wrong processor type. I'll test further and get back to you.

    I'll need to learn a lot more about the rtsc/XDC  build process before I can add support for a new device.

    Since the current distribution calls out OMAPL138 I'm surprised that TI hasn't already properly setup dsplink

    to work with the C67xx as part of the OMAPL138 build configuration. Anyhow I'll give it a try and write it up. I'm sure

    other users of the L138 are going to want the same capability.

    Thanks,

    Bob

     

  • Bob,

    I think you have uncovered a bug in the DSPLink handling of floating point.

    Was changing the compile flag enough or you had to do do some more things?

    Deepali

  • Deepali,

    Yes changing the compile flag allowed me to link in a 3rd party library which required C67

    linkage. I still need to work out how to modify the xdc and makefile system to be a proper

    OMAPL138 setup.

    Bob

  • Bob,

    I have filed an internal defect to track this to closure. This will cover the makefiles change.

    What do you mean by the XDC files? Am I missing something?

    Deepali

     

  • Hi, I just posted for this problem, then I found your post.  This is what I said:

     

    We're using DSPLINK with WinCE6.0 for our OMAP-L138.   In the ReadWrite example, 8-bit integers work fine, but there's a problem with 16-bit and float type data:

    1) When I change the DSP_MAUSIZE from 1 (8-bit) to 2 (16-bit), I keep getting zeros for what's returned from the dsp.  DSP_MAUSIZE was chaned on the ARM side in archdefs.h, and on the DSP side in c64xxdefs.h.  Can't make 16-bit ints work.  Need to write these to the dsp and read these from the dsp.  How to do?

    2) I don't see how to configure the DSPLINK ReadWrite example for floats.  Same need to write to and read from dsp.  e.g. writeBuf'[j] in tskReadWrite.c on the dsp side. How to do?

    BTW, my 64xxp_6.xx_windows.mk file is already configured for -mv6740, but that's in the DEBUG compiler options, not RELEASE.  I've been using RELEASE, but I still don't see anything about float data in the example.  That flag is not an option in the RELEASE compiler section.  Can it be added?  Is that all that needs to be done?

    Have these issues been fixed, and if so, what is the fix? 

    Thanks, DM