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.

CCS: Can I define C/C++ preprocessor macros in a target config file?

Other Parts Discussed in Thread: MSP-EXP430F5529LP, MSP-EXP430FR6989, MSP430FR2633

Tool/software: Code Composer Studio

Amongst my team we each have several different LaunchPad kits and am trying to set up some common code that can compile automatically to each one. That is, I want to be able to set up our code so that some of the common functionality is pre-configured and we just have to activate the right target configuration. Obviously this doesn't completely scale for the things that are completely different between the boards, but all of them support some sort of $X or $Y but sometimes allocated differently.

For example, my MSP-EXP430F5529LP has its LEDs on P1.0 and P4.7, and its switches on P2.1 and P1.1. But my MSP-EXP430FR6989 has its LEDs on P1.0 and P3.7, and its switches on P1.1 and P1.2. Others on the team have different setups, but they all have a couple switches and blinkenlights and serial peripherals in common.

I don't want to have to maintain separate branches or revert our code to a different patch each time one of us goes to work on it and switches between boards. Is there a way using the ccxml files in the targetConfigs folder, or some other mechanism, to define a per-target header file or per-target preprocessor definitions for things like  `MY_LED2_PORTOUT_ADDR`?

Does anyone else use this work pattern or is it only really supported to pick one particular board that everyone ends up using even during the prototyping/experimentation phases of a project?

  • CCS allows multiple different build configurations to be used in a project - see Creating and Managing Projects. By default, when a project is created you have two build configurations named "Debug" and "Release" but you can create new build configurations / rename then.

    For MSP430 based projects different build configurations can target different devices, and each build configuration can have a different target configuration file. If you change the device then CCS automatically adds a linker command file / target configuration file for the new device.

    https://github.com/Chester-Gillon/E2E_example_projects/tree/master/MSP430_crash_on_enable_disable_timer_int is an example of a project with multiple build configurations, with the device name as part of the build configuration name.

    CCS also creates a macro named __<device_name>__, e.g. __MSP430FR2633__, which can be used as conditional compilation in the C source code. E.g.:

    /* The pin toggled to indicate the program is still running */
    #define LED_OPERATIONS_PORT                 P1OUT
    #define LED_OPERATIONS_PORT_DIR             P1DIR
    #ifdef __MSP430FR2633__
    // CAPTIVATE-FR2633 LED1
    #define LED_OPERATIONS_MASK                 BIT7
    #else
    #define LED_OPERATIONS_MASK                 BIT0
    #endif

    If you have multiple variants of boards using the same MSP430 device then you would have to add your macros to different build configurations to differentiate the board variants using the same MSP430 device.

    Note the above example project was created in CCS 10 and used the MSP430 v20.2.1 compiler. You might get errors importing it into a previous version of CCS.

  • Thanks, these are helpful tips! For now I've just used the device name macros to trigger a more semantic (and potentially migrated to a more robust solution later on) definition, e.g.

    #if __MSP430F5529__
    // assume MSP-EXP430F5529LP board
    #define NATE_LP_F5529 1
    #endif

    For now this is a great solution, as things converge we can investigate setting up separate build targets but more specific hardware will likely be nailed down better by that point anyway. Appreciate the general hints since some of this code will remain for reuse even once that happens however.