Building DSPLink Applications

END OF LIFE

DSP Link is still available for download, but no further releases or updates are planned. Please see IPC Software Options for details and alternatives.

Overview

There are several ways to build your own DSPLink applications. The intent of this page is to cover some of the basics so that you can quickly start developing your own applications.

Method 1: Modifying a sample application

DSPLink ships with several applications to demonstrate its capabilities. Each example consists of a program for both the GPP and DSP. These can be found at the following location:

• dsplink/gpp/src/samples/
• dsplink/dsp/src/samples/

For this method we will be taking an example, making a copy (remaining inside the dsplink directory structure), and then modifying it. It is recommended to read the chapter, "Understanding the MAKE System" which is part of the DSPLink User Guide (dsplink/doc/UserGuide.pdf).

Copying an example

Let's say we want to use the "loop" example as a starting point. First, we can make copies of the "loop" directories. Let's call our new directory "loop_new". After the copy we now have the following directories:

• dsplink/gpp/src/samples/loop_new
• dsplink/dsp/src/samples/loop_new

Editing the DIRS file

The DSPLink build system utilizes a DIRS file to tell the make system what other directories it should go build. Let's take the following example:

> cd $DSPLINK/gpp/src/samples
> make

When we invoke make from the samples directory it will go into all the subdirectories specified by the DIRS file and invoke make there too.

If you want your newly created directory to be built along with all the other samples you could make an edit like this:

Before

DIRS  :=

ifeq ($(USE_CHNL), 1)
    DIRS += loop
        ifeq ($(USE_MSGQ), 1)
        DIRS += scale
        endif # ifeq ($(USE_MSGQ), 1)
endif # ifeq ($(USE_CHNL), 1)

After

DIRS  :=

ifeq ($(USE_CHNL), 1)
    DIRS += loop loop_new
        ifeq ($(USE_MSGQ), 1)
        DIRS += scale
        endif # ifeq ($(USE_MSGQ), 1)
endif # ifeq ($(USE_CHNL), 1)

Editing the COMPONENT file

The COMPONENT file is located in the OS-specific subdirectory (e.g. loop_new/Linux or loop_new/DspBios). There are several updates that need to be made to reflect our new directory:

• COMP_NAME affects the name of the directory where the intermediate object files get written. So by changing COMP_NAME to "LOOP_NEW" the generated object files will get placed in dsplink/gpp/BUILD/LOOP_NEW/OBJ.
• COMP_PATH is used by the make system to generate the filenames for compilation. If you forget to change this then you will end up compiling files from the wrong directory!
• COMP_TARGET should be updated so the name of our output executable is different than that of the original "loop" example, e.g. change it from "loopgpp" to "loopgpp_new".
• Additional compiler flags/defines, linker paths, libraries, etc. needed for the build should be specified here
• EXP_TARGETS lists files that should be copied to the export directory. The examples all export the main executable, so you'd need to modify the EXP_TARGETS to match the name of your file in COMP_TARGET, e.g. loopgpp_new.
• COMP_MAP_FILE (DSP only) gives the name of the map file to be output by the linker. You should change the name so it doesn't overwrite the map file generated by the original example.
• Remember to make updates to the COMPONENT file for both the GPP and the DSP!

Editing the SOURCES file

The SOURCES file is used by DSPLink's make system to specify your source files that need to be compiled. For example if you create myfile.c then you could modify the SOURCES file like so:

Before

SOURCES := loop.c

After

SOURCES := loop.c myfile.c

Method 2: Building a "stand alone" DSPLink application

Note: The following is mostly just some quick thoughts. It needs a lot more work! Feel free to contribute examples, etc.

Motivation

The easiest way to get started is "method 1" where you can expand upon an already working application. However, that's not always desirable. For example, one might already have a significant code base running only on the GPP side (perhaps ported from an earlier single-core project) and later decide to add some DSP functionality. In this case it is easier to start with the existing application and add to it.

Where are all the files buried?

Libraries

The libraries and drivers are located in the following locations:

dsplink/gpp/export/BIN/<OS>/<PLATFORM>/<VARIANT>/<DEBUG|RELEASE>
dsplink/dsp/export/BIN/<OS>/<PLATFORM>/<VARIANT>/<DEBUG|RELEASE>

For example, if you're building for a Linux target OS running on OMAP3530 you would find the "release" build at

dsplink/gpp/export/BIN/Linux/OMAP/3530/RELEASE
dsplink/dsp/export/BIN/Linux/OMAP/3530/RELEASE

You would need to add those paths to the linker search path for the ARM and DSP builds. You would then link in the libraries contained inside (dsplink.lib, component libraries)

Compiler Configuration

There are text files generated in the same directories as the libraries. These text files should be used to get a list of all the preprocessor search paths, preprocessor DEFINES, etc.

Method 3: Building a DSPLink application using a CCS project file

Motivation

Many application writers already have a significant code base running only on the GPP side (perhaps ported from an earlier single-core project) and later decide to add some DSP functionality. Also many application writers are more comfortable using a CCS project rather than a command line make based build system.

Steps to create a CCS project for building a DSPLink sample application

This discussion is relevant for BIOS 5.xx and CCS 3.xx

• Set the desired board in CCS setup
• Open DSP side CCS. Ensure that the correct version of code gen tools and DSP/BIOS is selected in the component manager. Ensure that the DSP/BIOS version and the value of environment variable BIOS_INSTALL_DIR match.
• Create a project. The steps are

Project -> New
   Give a Project name: DSPLinksamplebuild
   Give a location
   Executable - .out
   Give a target: TMS320C64XX

• Get the DSPLink include paths, compiler pre-processor defines and compiler options. There are two methods to do so.
• Method 1

Configure DSPlink using the dsplinkcfg script. This will generate a file CURRENTCFG.MK in the default location $DSPLINK/config/BUILD/CURRENTCFG.MK This file has defines

# TI_DSPLINK_DSP0_INC_PATH - This gives the include paths to be set in Build options of the project
# TI_DSPLINK_DSP0_DEFINES - This gives the compiler pre-processor defines to be set in Build options of the project
# TI_DSPLINK_DSP_COMMON_DEFINES - This gives additional compiler pre-processor defines to be set in Buildoptions of the project

• Method 2

Build DSPLink Build $DSPLINK/dsp/src in VERBOSE mode (make VERBOSE=1) Choose an example which mirrors the application needs. For e.g. if you are using RingIO IPC you can choose the RingIO sample. Choose debug or release build depending on your application needs. The pre-processor defines and compiler flags are different between the two. Build $DSPLINK/dsp/src/samples/ring_io

The build step will generate some textual files in the folder $dsplink/dsp/export/BIN/DspBios/<platform>/<gem>/<DEBUG|RELEASE>

# RING_IO_defines.txt - This gives the compiler preprocessor defines to be set in Build options of the project
# RING_IO_flags.txt - This gives the compiler flag to be set in Build options of the project
# RING_IO_includes.txt- This gives the include paths to be set in Build options of the project

• Set the build options of your project.
• Set the compiler flags that you have found in above step along with any application specific flags in Project->Build Options->Compiler.
• Set the compiler defines that you have found in above step along with any application specific defines in Project->Build Options->Compile->Pre-processor->pre-define symbol.
• Set the include paths that you have found in above step along with any application specific include paths in Project->Build Options->Compile->Pre-processor->Include search path.
• Inspect the linker step in the verbose build log to get the linker options to set in Build Options->Linker.
• Inspect the tconf command step in the verbose build log to get sample values for the -Dconfig.importPath and the -Dconfig.programName values to set in Build Options->DSpBiosBuilder.
• Add the dependant DSPLink libraries to the CCS project.
• Add the application specific tconf generated files to the project.

Sample CCS project for building a DSPLink sample application

Attached is a sample CCS project file File:DSPLinkSampleBuild.zip for the RingIO sample in release build for DSPLink version 1.61. In order to use this

• The DSP side of DSPLink needs to be built so all the dependent libraries like dsplink.lib etc are present.
• DSPLink supports multi-DSP configuration where processor Id assigned to DSP is specified at runtime and set accordingly for the DSP. 0 indicates the processor id used internally within DSPLink to denote the DSP in a configuration with one ARM and one DSP in the system. Update the RingIO tcf file to take argument 0. Set the value manually in file $DSPLINK\dsp\inc\DspBios\5.XX\DM6446GEM\dsplink-dm6446gem-base.tci.

<syntaxhighlight lang='javascript'> prog.module("GBL").PROCID = 0; </syntaxhighlight>

• To switch between debug and release, update the following the CCS project file manually

Source="dsp\BUILD\DM6446GEM_0\RING_IO\BIOS_DEB\ring_iocfg.s62"
Source="dsp\BUILD\DM6446GEM_0\RING_IO\BIOS_DEB\ring_iocfg_c.c"
Source="dsp\src\samples\ring_io\DspBios\5.XX\DM6446GEM\ring_io.tcf"
…
…
…
Source="dsp\BUILD\DM6446GEM_0\RING_IO\BIOS_DEB\ring_iocfg.cmd"
…
…
…
["dsp\BUILD\DM6446GEM_0\RING_IO\BIOS_DEB\ring_iocfg.cmd" Settings: "Debug"]