• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 1120 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.

example projects from Linux to Windows

Hank Barta
Intellectual 970 points
Other Parts Discussed in Thread: CONTROLSUITE

I've run into a bit of awkwardness when moving an example project from Linux to Windows (CCS 6.2) Here is what I did:

1) Import the project from the /opt/ti/... directory tree. I was careful to check the box to "copy the files to the project directory." I checked the source files and found that the C file which included main() had not been copied. I did this manually and then deleted the file from Project Explorer. After deleting the reference from the project, CCS picked up the file from the project directory and built without difficulty. I did not bother with support files such as F2837xD_CodeStartBranch.asm because I had no intention of modifying them.

2) Move the project to Windows (via git/bitbucket) and try to build. I get errors like:

gmake: *** No rule to make target 'C:/opt/ti/controlSUITE/device_support/F2837xD/v190/F2837xD_common/source/F2837xD_CodeStartBranch.asm', needed by 'F2837xD_CodeStartBranch.obj'.

This occurs for all support sources. Since the path starts with "C:/opt/ti/..." it is obvious that CCS did not create an installation independent reference for the files. Examining the file properties I see the file path is

PROJECT_LOC\..\..\..\..\..\..\..\opt\ti\controlSUITE\device_support\F2837xD\v190\F2837xD_common\source\F2837xD_CodeStartBranch.asm

It baffles me that the file is located relative to the project directory and not the installation directory since the file is in the installation path. It also hard codes part of the path that is system specific. Both of these make the project highly non-portable.

My knee jerk reaction is to suggest submitting two bug reports:

  1. Have CCS copy all source files to the project directory when the check box to copy sources is checked.
  2. Have CCS locate all files that are in the CCS install directory using a macro that specifies the install directory. ("PROJECT_LOC\..\..\..\..\..\..\..\" is ugly beyond words.)

If there are reasons for the behavior I have encountered, I'd be happy to hear them.

best,

hank

  • 0
    TI__Guru**** 173310 points

    Hank Barta said:

    Examining the file properties I see the file path is

    PROJECT_LOC\..\..\..\..\..\..\..\opt\ti\controlSUITE\device_support\F2837xD\v190\F2837xD_common\source\F2837xD_CodeStartBranch.asm

    That is surprising because when I import example projects in Windows, and examine the file property of F2837xD_CodeStartBranch.asm, I see this:


     

    where INSTALLROOT_F2837XD is set to the root of the F2837XD device support folder relative to the original project root directory as shown below:

     

    During project import, CCS looks at the original project location and sets the root folder relative to it. That way even if users install ControlSuite to different paths, the INSTALLROOT_F2837XD variable will always be set to the correct directory using relative paths, and will allow users to import projects no matter where their ControlSuite is installed.


    Regarding moving a project from Linux to Windows, let me give this a try and see if I can reproduce your observations. 

  • 0 in reply to AartiG
    Intellectual 970 points

    Hi AartiG,

    Thank you for looking into this. At the moment I am importing another project into a workspace using "Import CCS project" from CCS 6.2. I navigate to the directory under C:\ti to find the project, check the "Copy projects into workspace" checkbox and import. The resulting project file contains

    hank.barta@US-L16-0171 ~/Documents/test/neo_dsp_bringup
$ tree -a flash_programming_cpu01
flash_programming_cpu01
├── .ccsproject
├── .cproject
├── .project
├── .project~
├── .settings
│   ├── org.eclipse.cdt.codan.core.prefs
│   └── org.eclipse.cdt.debug.core.prefs
├── CPU1_FLASH
└── targetConfigs
    └── TMS320F28377D.ccxml

3 directories, 7 files

hank.barta@US-L16-0171 ~/Documents/test/neo_dsp_bringup

    None of the 

     - 9 .C files

     - 2 .ASM files

     - .CMD file

     - header file (F28x_Project.h)

    is copied to the directory tree.

    flash_programming_cpu01.c is referenced via 'INSTALLROOT_F2837XD\F2837xD_examples_Dual\flash_programming\cpu01\flash_programming_cpu01.c.' That should work when moving between Linux and Windows, but if I commit the project to git, any changes to that file will not be included. Further (and worse IMO) any changes to the file trash the original copy installed as part of the TI S/W installation.

    I have to manually copy these files, delete them from the project and let CCS add them back in. 

    It would be very cool if "Copy projects into workspace" did all of this for me.

    best,

    hank

  • 0 in reply to Hank Barta
    TI__Guru**** 173310 points

    Hank Barta said:

    None of the 

     - 9 .C files

     - 2 .ASM files

     - .CMD file

     - header file (F28x_Project.h)

    is copied to the directory tree.

    That is correct. This is the expected behavior due to the way the example projects were designed and the file structure of ControlSuite. Most or all of the source files are linked to the project and since they do not physically reside in the project folder, they do not get copied over even when the "Copy projects to workspace" checkbox is enabled during import. Some more info on this is in this wiki section: 
    http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Importing_projects

    Hank Barta said:
    Further (and worse IMO) any changes to the file trash the original copy installed as part of the TI S/W installation.

    If the file remains as a linked resource, then yes any changes will over-write the copy that was installed originally with ControlSuite. Looking through the examples under the different F28x devices, I see that the location of the main source file is within the project folder for some devices (like f2806x, f2802x etc), however for F2837xD even the main source file is linked to the project. In addition, apart from the main source file, all other peripheral source files are linked to the project as well. 

    I agree that there isn't a simple method for the project to "automatically" make a copy of all its resources. Currently this process is manual but we are looking at ways to improve this in the future.

    A couple of details that might be of interest to help with this:
    - To identify and get a copy of all source files in a project, including linked resources, you could export the project to an Archive file. The archive will have a copy of all files in the project, whether copied or linked. 
    - You could make a copy of the entire examples folder within ControlSuite and work with the copied version so changes do not impact the original copy:
    http://processors.wiki.ti.com/index.php/Creating_copy_of_example_project


    Hope this helps! I understand this is not the ideal solution but hopefully these tips help alleviate some of the inconveniences.

  • 0 in reply to AartiG
    Intellectual 970 points

    Hi AartiG,

    Thanks for the additional information. I think the next time I 'clone' one of the example projects I will try the 'archive' strategy. It seems like it would be easier than individually copying project files one at a time.

    If TI keeps a list of 'things customers whine about' please add my comment about not copying all project files.

    thanks,

    hank