Migrating to CCSv4

Chinese (中文) translation

Overview 

CCSv4 is a major release and as a result it is quite different from previous versions. Therefore there are some migration steps that you need to go through to move your development from previous versions to v4. There are some tools to help you will migration such as the project import wizard however the overall environment is much different so you will need to adjust to it. This section will describe how some concepts have changed in CCSv4 and cover specific migration topics.

Migration Presentation: This presentation covers the majority of migration topics. Media:CCSv4Migration.pdf

Projects

CCSv3.3 Projects (.pjt): CCSv4 uses the Eclipse concept of projects. To help you import your existing projects into CCSv4 we have created a project import wizard. From the Project menu select "Import Legacy CCSv3.3 Project". This will launch a wizard that will guide you through the conversion process. If you don't want to convert your projects at this time one thing you may want to try is to instead create a standard make project that calls timake to build your existing pjt file. A standard make project is really just a wrapper project where you provide the build utility that you want to use and the parameters that should be passed to it for building and cleaning.

If you are importing a project that uses DSP/BIOS the import wizard will ask you which verison of DSP/BIOS you want the imported project to use.  It is recommended that you select DSP/BIOS 5.40.  This version of DSP/BIOS is compatible with previous 5.x verisons.  By selecting DSP/BIOS 5.40 you will enable the Run-time Object Viewer and Real-time Analysis debug features (for beta 2 RTA is just logs).  You can choose to use an older version of DSP/BIOS but you will not have either of these debug capabilities.

If you have a DVSDK project that has both a .tcf (DSP/BIOS configuration) and a .cfg (RTSC configuration for drivers...) the import tool in beta 2 will not allow you to import this project.  There are complications with using both forms of configuration in a project so the import tool will prevent this for now.

CCEv3 Projects: CCSv4 and CCEv3.x projects are very similar. If you are migrating from CCEv3.1 you should be able to import the existing project into your workspace with no issues. If you are importing CCEv3.0 projects there is an extra step to go through. Once you import the project you will need to create a target configuration for your project that says which debug connection to use (USB, parallel) and the device. In CCEv3.0 this information is stored in the workspace and when importing into v4 we have no way to extract this information automatically, in CCEv3.1 we moved the information to be relative to the project so that we could more easily transfer the information to new workspaces.

GEL

GEL is still present in CCSv4. At its heart GEL is the expression evaluator used by the CCS debugger. Everywhere you enter in a start address, variable name or condition on a breakpoint it is using GEL to evaluation that expression.

Changes: In CCSv4 GEL has changed in that as it is part of the CCS debugger and not part of the top level user interface you will not be able to run some of the old GEL functions that accessed the user interface such as GEL_WatchAdd() or the project related functions. However all of the debug related functions will still work.

GEL Startup Files: GEL is still used for target initialization files that you specify in the target setup tool.

GEL Automation: If you are using GEL for automation it is highly recommended that you convert these to Debug Server Scripting (DSS) scripts, as these scripts are much more robust, predictable and debuggable.  However you can still use your existing GEL automation scripts.

GEL Sliders, Dialogs and Menus: As GEL is in the debugger and the debugger is separated from the GUI interface we do not have the GEL slider, dialog and menu items in beta 1. The good news is that we are adding all of these features in beta 2. One suggestion as a temporary replacement for the dialogs and menu items is to create simple scripting console functions. For example if you had a GEL hotmenu item to reset your peripheral state you could very easily create a scripting console function "resetPeriph" that just called that GEL function. Then you could just type "resetPeriph" from the scripting console. You can even provide help for the function so that people who are not familiar with it can type "help resetPeriph" and get more information on what the function does.

GEL Console Output: In CCSv3.3 GEL_TextOut() output is directed to the GEL tab on the output window or sometimes to a specially named tab if a name was given in the GEL_TextOut() function. In CCSv4 this function still works and the output is shown in the console view. One change here is that all of the output goes to the console view, you cannot ceate a separate tab with a custom name and direct output there.

Workspaces

CCSv3.3 Workspaces: Workspaces in CCSv3.x are binary files that contain the serialized content from the windows in CCS. There is no way to import these into CCSv4.

CCEv3 Workspaces: There is enough change between CCEv3.x and CCSv4 that it is best to create a new workspace.

Scripting and Automation 

CCS Scripting: CCS Scripting was a COM library that sat on top of the CCS GUI. In CCSv4 that GUI is replaced with the Eclipse environment. Thus there is no way to run existing CCS Scripting scripts. We have a far better interface available in CCSv4 called Debug Server Scripting (DSS). This is an API that was designed for debug automation. It is much faster that CCS Scripting, more reliable, has better error handling and exception support and the scripts are even debuggable. The default scripting language for DSS is Javascript but you can also use Perl and Python if you prefer. There is a media wiki section on Debug Server Scripting on the main site.

CCS SDK: The CCS COM SDK was never designed for automation but there are instances where it was used for this. If you have CCS plug-in for automating CCS there are a few alternatives for you to consider in CCS. The first choice is to move them to DSS scripts. If you really want to keep a graphical interface as part of your solution you could create an Eclipse plug-in for that portion. There is more information on creating GUI plug-ins for CCSv4 in the plug-in section.

Import Configurations

CCSv3.x import configurations: It is not possible to use existing CCSv3.x import configurations (.ccs) files.  You will need to re-create these in the target configuration editor in CCSv4.  In CCSv4 we are trying to make creating target configurations a lot easier to create.  For example for most configurations you should really just have to select your device and connection (emulator or simulator) and the configuration tool will take care of the rest.  For more complex configurations there is a tool provided for building up advanced configurations from scratch. 

 

Deprecated Features 

There are some features that were present in CCSv3.3 that have not been carried forward into CCSv4.  These features are listed below:

• CacheTune: This was a feature that attempted to show cache hits/misses over time in a graphical format.  In CCSv4 we no longer have the graph but have improved the accuracy of our cache profiling capabilities.  When using the function profiler on many of our simulators you can select to profile the functions for a variety of cache events.
• Compiler Consultant: This tool supplemented the output from the C6000 compiler and tried to give advice on how you could improve your application performance.  This same information and much more is captured on the mediawiki site by these topics: CGT_Tips_&_Tricks_for_Beginners and Supercharged_Optimization.
  

 

 

---

CN Migrating to CCSv4