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.

Defining C variables and constants in tconf script

Using CCS 4.0 and DSP/BIOS 5.41, how can I define a constant or variable in the generated C code based on values computed in the tconf script? It doesn't matter if it's an enum, #define or global int variable in my current case.

Thanks,

Martin Alnes

  • I'm not sure if I understand exactly what you want to achieve with that. Can you give me an example of variable/constant you want to use in the tconf? 

  • Basically I just want to select between a combination of configurations in _one_ place and have all aspects of build, target and source code configuration follow.

     

    I'm running the same code on two evaluation boards with 6747 and 6748 DPSs, and want a variable in the C code to select between two behaviours. At the time of writing this I had to remember to

    1) switch build configuration,

    2) flip a #define in a header to switch between code behaviours,

    3) and switch target configuration,

    I figured out how to make (2) follow from (1) by making a #define in the build configuration, but am still curious if I can do this from the tconf file to reduce the amount of work in the case of many build configurations. Point (3) has nothing to do with this post, but it would be nice to have that follow from the build configuration as well (the targets need different libraries and thus different build configurations).

     

    There are currently two code behaviours I switch between:

    A) I make a global variable "Int ERAM" and set it equal to "SDRAM" or "DDR" depending on which board I'm running (better solutions to this are welcome!)

    B) usefoo.c is only built with the build configuration testfoo because it depends on the library libfoo, and calls to usefoo functions must be avoided in other build configurations.

    Alternative solutions to (B) are to add dummy implementations of usefoo functions to all the other configurations, or to have custom main source files for different builds. But these projects are just for quick and dirty testing, and sometimes a quick hack with a #define is more valuable than a good architecture.

  • Martin,

    You are on the right track here and there are a couple of ways to do this.

    As you are already doing, one way is to have multiple CCS configurations, each with its own set of build options (dependent on the #defines) and source files. You did not mention which version of CCS you are using, but both CCS 3 and CCS 4 allow you to exclude certain files from build for a certain build configuration. So you can have the same set of source files in the project and add/exclude them from build based on your configuration.

    Another way to do this, which helps avoid multiple configurations is to use conditional processing directives in the linker and DSP/BIOS. Newer versions of code generation tools include support for preprocessing directives such as #define, #include, and #if/#endif in the linker command file.  BIOS also allows environment variables to be defined and accessed from a Tconf script. For example, this command defines global variable var1 for use within Tconf:

    tconf -Dvar1=value1 
    

    To access this variable within tconf, the following expression is used:

    environment["var1"]
    

    These environment variables are only used by tconf during the configuration and build process. More details on this are in the DSP/BIOS 5.30 Textual Configuration (Tconf) User’s Guide, http://www.ti.com/lit/spru007, Section 2.2.1 "Environment Array Variables".

    This article elaborates a bit more on this topic: http://tiexpressdsp.com/index.php/Using_Preprocessor_Support_in_Linker. Note that it is written for a C2000 target, but should give a general overview of how to use these #defines in your build environment.