Project template

I have pretty much the same requirements as Pascal:

- A "common" shared folder (with sub-folders) that should be in a "template"

- A "common" DSP/BIOS configuration for the project that should be in a "template"

- Then user-specific files to be added to the template

I need the user to be able to *easily* take the template and make a copy that "links" to the shared folders (including a linked DSP/BIOS configuration), and allows to *add* files to the project. Ideally, I need many users to be able to create their own projects without the worry they will modify the template.

I have not found anything about this topic in the E2E since Pascal's post (which I assume is Jan 10, 2010, about 10 months earlier)... I hope that by "replying" it creates new activityan a TI person can respond.

Thank you,

Alvar

Hi Alvar, it's great to hear from you.  Please take a look at this wiki page on project sharing and let us know if that helps.  http://processors.wiki.ti.com/index.php/Project_Sharing

All the best

Cathy

Reposting for Alvar with corrected formating:

>Thanks for the reply; unfortunately the post did not help me, that was all information I knew already (both in "sharing" and "portable"

>projects). I think I need a combination of the two topics, and can't  figure out how to make that work out.

>I'll try to detail our original CCS2 configuration, to hopefully make things clearer, and to illustrate where I'm having problems:

>1) Our directory structure is maintained under SVN as:

>/trunk
> /Core
> /Projects

>2) Under projects there are two types of projects

> /Projects
> /"Individual" <projects for single users for testing before
> they go to ISS>
> /"ISS/Group#" <projects that will go to ISS, divided into groups of users that share one project>

>each project consists of:

> <project path>/Common <.c files>

> <project path>/Sat1 <.h file, .pjt file>

> <project path>/Sat2 <.h file, .pjt file>

> <project path>/Sat3 <.h file, .pjt file>

>Under "common" are .c files that all 3 satellites will use. In the template there is only one file (gsp.c)

>Under "Sat#" are .h files that define the satellite configuration, and

>.c files unique to each satellite. In the template there is only one H

>file (gsp.h) and the CCS2 .pjt file defining the project for each satellite.

>

>Each user is likely to have many projects of their own (each with 1 to 3 Sat# directory with individual .pjt files for each satellite).

>

>3) In CCS2 we had the .pjt file. When a user wanted to create a new project they would have to (for each satellite they planed to use):

> - Copy .pjt to the directory of the choosing

> - Edit .pjt in a text editor and modify:

> - "linked" files path to the correct relative path from where the

>.pjt is (eg, change ../../../ to ../../ in some cases)

> - changed the project name and .out/.map names so they are unique

> - Create a Windows Environment Variable called "CORE_DIR" which points to their version of /trunk/Core (only need to do this once)

>

>4) The user would then be ready with a new "personalized" project which would open in CCS and include all the essential "Core" files, plus

>create unique .out and .map files. This would be done by modifying only one file (.pjt) and creating whatever directory structure they wanted.

>

>5) While /Core is in SVN, I need to let users:

> - Choose their own location of /trunk and of /Core (which might change)

> - User their own versions of /Core (it should NOT be distributed with the project)

>

>With CCS v4 I keep having problems with:

>

>1) I don't know what files are ESSENTIAL for the user to be able to import a program into the "workspace". I really need it to be just the

>essential files.

>2) I have not been able to easily make changes to the relative links in

>a CCS v4 project --- I can't just open the .project and change the path

>in the link there; a "macro.ini" is created, and I can't get it to work

>right... plus I now need to modify more than one file.

>

>3) I can't figure out where to change the .out and .map file without

>having to do it inside the IDE; is this a 3rd file I need to modify?

>

>4) I need to include the BIOS configuration as part of CORE, not as

>part of the template. I can't figure out what files are the ESSENTIAL

>files to put into the /Core directory for the new BIOS configuration

>file (what used to be the cdb is now a "textual" file, plus other

>things get created). I have not tried enough of this step, so maybe

>this one is easy, but it would be nice to know that all I need to do is

>move the "textual" file and then create a link.

>

>Summary:

>- Biggest issue is for user to be able to have their own directory

>structure, which may include different levels of relative paths from

>what is in the template

> - A fix would be to enable use of an environment variable in the

>"link" (CORE_DIR), which would translate to an absolute path, but

>different for each user; but I can't figure out how to get environment

>variables into the link locations (I got it to work for -include in

>the linker configuration, but can't get farther).

>- Second, the user needs to be able to easily rename the project and

>the output files, preferably all from one place (same place as where

>relative path was fixed)

>- Third, I need to figure out the easiest way to package the

>ESSENTIAL/MINIMAL number of files to distribute to users, with clear

>instructions on how to personalize their project from the template.

>

>Maybe (hopefully) this is all easy, and I'm just having problems understanding the new "nomenclature" for CCS v4. At this point, though,

>I do need more help, so that I'm not using all my time on this issue and can complete the rest of the CCS v4 migration process for SPHERES.

>

>Thank you!

>

>Alvar

Alvar,

We do have the concept of a project template in CCSv4.2 (currently in release candidate).  There is a wiki topic under construction.  Someone will reply with a link to it shortly.  

Regards,

John

Alvar,

As John mentioned CCS 4.2 has the concept of a project template. I started putting together this wiki page on creating/using templates. The page is still under construction, but it does include some examples and should give you an idea of how templates work. I am not sure if this will satisfy all your requirements, but sounds closer to what you are looking for than a portable project.

The idea is that you can create project templates consisting of a set of source files/build options etc., and users can select that template as part of their new CCS project wizard. That will create a project in their workspace with the set of source files/build options defined in the template. If they wish, they can add additional files to the project, but it allows each user to work with their own "copy" of the project, rather than from a shared project.

Aarti and John - Alvar sent in some additional questions.

- In CCS2 we used the Visual Linker, so we:

- Ran the project, which created a .cmd from a .cdb

- Then ran again and created an .rcp

- Edited the .rcp using the GUI to specify memory sections

- In CCS4 I can compile without a .cmd file at all, so my guess is that its using some "default" configuration. I just can't find any easy steps to follow to:

a) Find a "default" .cmd file

b) Modify it to specify memory allocation (and check where things are)

Can you help me out here?

Let me know if any part of the question is not here.

Thanks!

Alvar

PS, as I mentioned, I have CCS4 compiling our "core" software; however, the DSP randomly enters into a weird mode where the program counter seems to reset to 0, since "main" is run again, BIOS then starts, and then it resets again... its a tough one to debug, but I'm guessing a memory overflow or something similar, so I want to check and potentially configure the .cmd file first

PSS, still have not had time to look into the templates of 4.2...

when I installed 4.2 I discovered I can NOT open 4.1 projects easily (maybe because I had the same "workspace" directory)? it complains that a different "compiler" was used to build the project previously... I have to attack one problem at a time, I can't have different projects to test different things, I need to get one working and then another one...

If this is a BIOS app there will still be a .cmd file that is generated.  It will be in a folder that has the same name as the build configuration.  i.e. "Debug"  The memory layout that is used matches whatever platform that was selected when creating the BIOS configuration file (.tcf).  This files are generated and cannot be modified.  You can double click on the tcf file in the project and it will open up the tcf file in an editor.  If they expand System and then MEM it shows the memory blocks and this can be modified.

John

John,

Thanks for the reply, but it does not really solve my problem.

I have already modified the System->MEM sections to match my hardware.

However, my problem is as follows:

- In the past we were able to specify individual code sections and where they would go

- with CCS2 we specifically had to move .switch from IDRAM (internal) to SDRAM (external), because long switch statements would cause a problem if stored in internal RAM; this was a bug at the time, and it was acknowledged by the TI team at the time as a bug, but I have no indication if it was fixed or not.

So:

- is the .switch section fixed?

- how can I specify memory sections if they have not been explicitly defined in the TCF file?

- How can I see the resulting memory allocation?

-- In CCS with "visual linker", after a program was compiled/linked, I had a visual representation of the memory allocation. Are there any tools in CCS4 where I can see that information clearly? Or do I have to use the .map file and figure it out myself?

I am having a hard time finding what I'm guessing is a memory "overrun" problem, because at some *random* point the DSP enters a weird cycle of the program stack pointer jumping to 0, then BIOS is loaded, then the program goes back to 0.

Because my system is already embedded, I don't have access to JTAG or other information, so I have to debug with an embedded system only by either commenting things out (so far no luck), or by studying memory allocation and see if I can find the problem.

Thank you for your help.

Alvar

PS, in CCS we had to tell the visual linker to NOT fill the stack with "C0FFEE", but I think that was a visual-linker specific issue, and my program size with CCS4 did not increase substantially, so I think I don't have to do that... but I can't find anywhere in the TCF editor to confirm that the stack should not be pre-filled.

Alvar,

It is possible to have multiple linker command files in your project so you could use your own file to specify additional sections that are not explicitly defined in the generated cmd file.

The map file is the best thing today for seeing the memory allocation.  The visual representation that Visual Linker provided is not available.  There are some tools for looking at memory usage as well that might help: http://processors.wiki.ti.com/index.php/Code_Generation_Tools_XML_Processing_Scripts

The 0xCOFFEE issue will not be present any longer as that was Visual Linker specific.

I am not familiar with the .switch problem you mentioned.  Was this a compiler issue, or BIOS issue?

Regards,

John

John,

I'll try to work with the .map file and hte tools you mention (will have to wait to next week though)...

Below is the "history" of the .switch problem, which dates back to 2006 and was an issue with the compiler:

Hi Alvar,

This is regarding your SR#1-229450566 opened with TI Technical Support.

Regarding your query about, Basically, the problem lies in switch/case statements.  When I have a switch/case with more than 9 cases, my program crashes.  With less it works fine.

Alvar, this is a known issue. You have to list .switch section in linker command file and place it somewhere not in internal program memory. This happens when the number of cases, in the switch statement, reaches the point where the .switch section is generated in the map file. I believe this should take care of the issue.

I hope this helps in resolving your issue.

If you have any further queries, do feel free to contact me.

Regards,
Natarajan Ravichandran
 
Texas Instruments
SDS Technical Support
support@ti.com
+1-972-644-5580
 
-----Original Message-----

From:  alvarso@MIT.EDU
Sent:  2/7/2006 02:39:11 AM
To:  support@ti.com
Subject:  RE: Service Request # 1-229450566


Hi Navaid,

Thank you for the contact!  My phone dropped the call last week, and it was
an extremely busy time... I found a work-around, very un-elegant, but made
things work at the time.  Still, I would like to go over this with you,
since the work-around makes my code very clumbersome and hard for people to
read in the future.

Basically, the problem lies in switch/case statements.  When I have a
switch/case with more than 9 cases, my program crashes.  With less it works
fine.  As an example:

         switch(a)
         {
                 case 'a':
                 case 'A':
                         // do something
                         break;
                 case 'b':
                 case 'B':
                         // do something
                         break;
                 case 'c':
                 case 'C':
                         // do something
                         break;
                 case 'd':
                 case 'D':
                         // do something
                         break;
                 case 'e':
                 case 'E':
                         // do something
                         break;
                 case 'f':
                 case 'F':
                         // do something
                         break;
                 case 'g':
                 case 'G':
                         // do something
                         break;
                 case 'h':
                 case 'H':
                         // do something
                         break;
                 default:
                         // do something
         }

will work fine.  BUT if I add a single statement, even if the only thing it
does is to "break":

         switch(a)
         {
                 case '0':
                         break;
                 case 'a':
                 case 'A':
                         // do something
                         break;
                 case 'b':
                 case 'B':
                         // do something
                         break;
                 case 'c':
                 case 'C':
                         // do something
                         break;
                 case 'd':
                 case 'D':
                         // do something
                         break;
                 case 'e':
                 case 'E':
                         // do something
                         break;
                 case 'f':
                 case 'F':
                         // do something
                         break;
                 case 'g':
                 case 'G':
                         // do something
                         break;
                 case 'h':
                 case 'H':
                         // do something
                         break;
                 default:
                         // do something
         }

then my program crashes (the processor reboots itself, although I have not
figured out if it does it on its own or if its a watchdog I have on it; but
the program definitely does NOT work).

If I have no break, and I simply make the statement:

                 case '0':
                 case 'a':
                 case 'A':

then it works fine.

I can send you the whole project, if you want; although since we use custom
embedded hardware, I'm not sure how you could simulate/replicate the
project itself... but I can send it.

Thanks for the help,

Alvar