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.

CODECOMPOSER: Sysconfig: How to best manage build variations.

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: SYSCONFIG

Hi

We we use sysconfig to setup our project for the target.

We have two versions of the HW, with small differences, and need to make separate bulds for those two versions.

In a normal handwritten configuration, we would have one .C file with all the shared setting, and the two files for each build with the few settings that differ, (some might go to use of #ifdefs).

How to do something similar with sysconfig?

We would like to avoid doing a complete copy of all configurations in sysconfig, as that would lead to a manual sync of all the shared parts. thus more maintenance (future might bring more HW versions).

I did a fast test and split the content of the foo.sysconfig file, into two files, but that did not appear to work at least not without some magic spells.

But Maybe there is another clever way to achieve this separation?

As an example case. please assume we have a sysconfig setup with

  • RAM allocation (two cores),
  • SPI setup
  • SCI setup
  • EPWM setup
  • Some simple GPIO setup
  • ADC setup.

The difference between the two hardware's is

  • Two ADC channels has swapped pins.
  • SPI has changed the pin for CS.
  • One HW has an extra SCI.

NB: The actual MCU is a F28379D, I did not put that in topic, as i assume the answer is sysconfig specific and not MCU specific.

  • Hello,

    We would like to avoid doing a complete copy of all configurations in sysconfig

    Are you referring to build configurations? Build configurations are actually the recommended technique for your environment. You would have a different build configuration for each version of the HW. You would have two different sysconfig files, one for each HW. You would exclude the non-relevant version of the file for each build configuration. You could do this for the source files that differ for each HW (or have a singular file with #ifdefs and specify the define in the build options for each build configuration). 

  • Build configurations is one way to select and exclude files, yes I know.

    I am specifically referring to the sysconfig setup.

    And I am looking for a more granular way to handle variations.

    The default brute force approach is to just have two different sysconfig files, and select the active using build configurations.
    But that would leave me with two files that are 95% identical, and all future changes to the identical parts now has to be manually synchronized.

    Experience tells me that when you have the same information repeated in two locations, they tend to get out of sync, and if that then expands to three locations the the chance of errors due to missing sync goes up exponentially.

    As you mentioned for normal source files, I could utilize `#ifdefs` to single out the 5% difference, or even better split the source files, so the variance in contained in a separate set of files.

    Ideally I would have 

    hw_1.sysconfig
    hw_2.sysconfig
    common.sysconfig

    And then

    Build config 1 include :

    hw_1.sysconfig
    common.sysconfig

    Build config 2 include :

    hw_2.sysconfig
    common.sysconfig

    But as far as I can tell that is not possible. But are there any way to achieve similar results?

  • I've brought this thread to the attention of the sysconfig experts for further comment.

    Thanks

    ki

  • Martin,

    There are mechanisms available in the .syscfg files to let you do what you are saying.  The catch is that if you then use the GUI to edit the file, it will write over your changes and you will lose your partitioning.  However, I believe you could have the above three files, have them all editable separately in the GUI, and then tie them together with another two files hand-authored files that you never use the GUI to edit.

    If you open a .syscfg file in a text editor, you will see that it is simply JavaScript.  It should be relatively intuitive as to what it is setting up.  You can then create a script like this:

    system.getScript("./hw_1.js");

    system.getScript("./common.js");

    which would load the two other files and run them (note they need to have a .js extension).  You would then need an equivalent one for the other configuration.  The build configuration would then switch between which the two files you just created is active.

    If you were to use the GUI to edit one of the sub scripts, you would just see it's content and would be able to change stuff accordingly and save.  If you opened the hand-authored file in the GUI, you would see everything, but saving would destroy your changes.

    Darian

  • This sounds like exactly what I was looking for, great :-).

    A Follow up question is then, as other people will be editing this project too. Is there anything I could add to this hand-crafted main file, that would trigger an error or warning if opened in the GUI?
    Some variable that is only there or have a specific value, when opened by the GUI

    I am not strong on javascript (but a fast learner), but a similar thing in C would be something like

    #ifdef  SYS_GUI_VER
    #error Do not edit in gui.
    #endif

    I know I would have to write the check in javascript, the above C example is only to illustrate what I am looking for.

  • if(typeof window !== "undefined") {
        // throw new Error("This file should not be edited in the UI");
        alert("You can view this, but don't save");
    }

    Uncomment the second line if you don't trust your co-workers to pay attention to the alert message.

    Darian

  • Just a dummy reply, to keep the thread open.
    I has been interrupted by a bug-fix task that was urgent, and stopped me from evaluating this answer.
    Will return to this soon.