• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 259 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: MSP430 - Forcing a dependency on a non C component

Andrew McLaren
Intellectual 580 points

Tool/software: Code Composer Studio

Following on from a suggestion in this forum a couple of years back, I've been playing with some ideas for ensuring a common MSP variant is defined through multiple levels of projects (we build common code for multiple processors). The concept was to remove the specific MSP variant from each projects properties, and use some sort of common include file to provide the specific processor variant. 

The model I have been playing with has the following (I'm using the GNU toolchain, but don't think that matters)

  • All projects use a "Custom MSP Device", and all properties related to the specific processor (-mmcu etc) are set to null.
  • All projects include any compile options from a compiler options file. This can include anything that may vary across processors (-mmcu obviously, but also -mlarge and -code and -mdata regions etc)
  • Similarly with the linker command file, which is normally inserted automatically into the properties. This field is set to null, and a generic linker command file inserted into the linker -T options. This generic command file does nothing more than INCLUDE the appropriate linker command file for the processor variant.
  • I've located the two include files in a project of their own, which all other projects are dependent on.
  • The idea was that any change of processor is simply made in the compile and linker options files, and everything automatically builds with these, but...

I struggled to get the normal projects to detect any changes in the dependent options files. Then (a bit of a stab in the dark) I renamed these to .h's, and everything started to work as expected. I'm guessing that CCS automagically builds the inter project dependencies based on normal C file extensions (.c and .h). While this would work as a workaround, it seems a bit ugly. Is there any easy way to tell CCS that there are dependencies that are not standard C files?

A couple of secondary questions.

  • Is what I am doing sensible, or am I likely to trip over or break something in CCS.
  • CCS normally imports a copy of the linker command file directly into the project, rather than referencing it from the TI CCS directories. Any idea what the rationale behind this is? It does give the option of tweaking this on a per project basis (or I suppose archiving these as another artifact with production code), but I would have thought these were pretty static?

Thanks for any insights! Andrew

  • 0
    TI__Guru**** 173310 points

    Andrew McLaren said:
    I struggled to get the normal projects to detect any changes in the dependent options files.

    Are the options file passed via the "Read options from specified file" compiler option? If so they are not considered a dependency for the build system, hence changes to that file will not be treated as a requirement for project rebuild. I don't think there is a straightforward way to force dependencies on non source files so I don't have a good workaround to offer, but will let you know if I think of any other options. 

    Andrew McLaren said:
    CCS normally imports a copy of the linker command file directly into the project, rather than referencing it from the TI CCS directories. Any idea what the rationale behind this is? It does give the option of tweaking this on a per project basis (or I suppose archiving these as another artifact with production code), but I would have thought these were pretty static?

    That is the main advantage - copying it into the project directory allows user to edit and customize it at will while keeping it independent of the copy that comes with the CCS product.

  • 0 in reply to AartiG
    Intellectual 580 points

    Thanks for that.

    I've spent some time delving into the mechanics of how CCS builds projects, and once into the project makefiles, the focus on C based executables is readily apparent. With a bit of work on these (I suspect I'll need a custom makefile, but its only in one place), I think I can readily get CCS to manage something that is pure configuration.

    What I am vague on, is just how interproject dependencies are handled. Does CCS simply force a make on all dependent projects, and let the make within the project figure out what, if anything, is required, or is it something more complex?

    Thanks - Andrew