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.

CC1310: SDK version in defined symbol

Part Number: CC1310

Simplelink team,

A customer is transitioning from one SDK version to the other, and wants to be able to read in their application code which version is being built with a #IF statement.  It would be ideal to be able to switch back and forth by just checking the box for the SDK version.  Is there a defined symbol in the SDK to state which version of the SDK is being used for the build?

The goal is to do this without a Predefined Symbol in each project.

Thanks,
Darren

  • No, there is no SDK level predefined version symbol that can be propagated to each project. The only possibility would be to check the COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR define which identifies the SDK location. As far as adding the compiler token, this might be possible using XDC tools configuro by first checking the linker option values, parsing the version, and adding that as a compiler option. However, this may be more overhead than just manually updating a predefined symbol since configuro runs on top of an old eclipse tool that doesn't have the best documentation.

  • This just bit me too. Because resource explorer stopped running on CCS7.4 I was forced to upgrade to CCS8.1 and the resource explorer there would not have anything to do with 1.60 SDK, forcing me to 2.20. Meanwhile the client hasn't upgraded from 1.60 and I really needed a way to detect the SDK version to enable them to build without blowing up over various structure changes in CC1310_LAUNCHXL.c. It's VERY surprising there is no versioning accessible to applications if you've got unstable interfaces.
  • And it goes without saying, but I'll say it anyway, that COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR won't get the job done, so in my opinion this is NOT resolved.
  • Pete: You should be able to use 1.6 with the resource explorer by selecting the version in the package picker up in the upper right corner.
  • The resource explorer stopped being available with CCS 7.4. I took a screen shot of the official withdrawal of support but can't find it at the moment. I tried very hard to make SDK 1.6 work with CCS 8.1, but after installing it CCS didn't seem to make it visible. That last bit could easily have been something I missed, but if the "picker" is the part of the explorer that offers various SDKs I can confirm that even with 1.6 installed the picker would only show me 2.20. This was very different from the behavior with 7.4 where I could see both 1.60 and 2.20 at the same time and choose between them.

    But we're hijacking the issue. My issue is like Darren's and I'm not in the position to ask my client to figure out how to parse a pathname and discriminate between blah blah 1_60 and 2_20 (we're not even using the same OS and I couldn't guess what their pathnames look like, I'm that ignorant about OSX). So I'm sending .out files until they're able to upgrade.
  • Hi Pete, 

    I am not seeing the same problem you are on CCS 8.1. I am able to select the 1.6 version of the SDK. If you are not seeing it at a project level I would suggest going to Windows -> Preferences from the CCS navigation bar then in the preferences window Code Composer Studio -> Products and making sure the SDK was discovered. If the 1.6 SDK is not listed under installed products, try clicking rediscover. If that does not work you can add the parent folder to the list of discovery paths and try rediscovering. 

    I am also not seeing the issue you are having with Resource Explorer. There is an eye icon in the top right corner that gives a tour of the Resource Explorer - this will show you how to change the package version. Scrolling down on the homepage there should be an icon for each available software package where you can select the version. By default the version is latest. 

  • Darren,

       I apologize for including the cause (and semi-editorials) about what forced me to need a conditional compilation symbol: it wasn't really germane and has distracted us, but now I need to clarify. However the bit at the end about the above mentioned path variable will be my exit from the thread.

    AJB,

       Thanks for all the tips. Unfortunately my reality doesn't match yours. In prefs/products the 1.60 SDK is clearly shown, however, while the "scroll down in the explorer picker" action does show the CC13x0 SDK as defaulting to 2.20 SDK , it allows for no other choice.There is no dropdown behavior (as there was with CCS7.4) allowing selection of the other installed SDKs. I have 2.30 installed, it shows up in the installed products under prefs but not in the menu. (This is all with CCS 8.1.0.00011).

        But to be clear, THIS is what hosed me and forced the CCS upgrade that in turn forced me away from the 1.60 SDK and got me ahead of my client:

     

    The update instructions link  mentioned above (that clearly implies it's going to help you update the resource explorer)  takes you to the page for updating CCS. 

    Now, back to the issue: how to detect the SDK version at C preprocessing time? What mechanism would somebody actually use to employ the workaround to do with the SDK pathname makefile variable mentioned above? It's in a zillion makefiles, but only in the 2.20 and 2.30 directories. It's not present in the 1.60 directory, let alone passed via -D to compiles. It's only used with -I compiler switches.

  • Mystery solved. I just installed CCS 8.1 on Windows 7 with multiple SDK versions and it behaves exactly as AJB describes above. I failed to mention I use CCS with Linux.