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.
Hello everybody
Is there any way to make easy stand alone project (independent from other common CCS files) .
I started from some TI example (never mind, TI2000 V/F control), which I changed later;
after that I want to use new example (vector control) with new parameters in files, but new include files will change my previous work.
Beside that any new version of CCS will bring changes in include files.
It will be so nice to have some "zip" tool which will automatically take all necessary files and make stand alone project.
Any recommendations?
Regards
Hi vlado,
Which include files are you concerned about? The RTS include files like stdio.h?
ki
This is a very interesting question, so thank you for posting it here. My development work is always on my computer where I do not change CCS version very often and do not change or update libraries very often. When I do change any of those, old programs still work exactly as they did before as long as I do not try to compile them again. And when I want to re-compile, I always want to use the latest version of CCS and Code Generation tools and DSP/BIOS and any device-support libraries.
I am not familiar with the f280... header files you listed, but usually header files that are provided with a library are not meant to be edited as part of your project. They should be included in the build process, but any project-specific parameters should be placed in other header files that are local to your project. This allows you to use those common files for many different projects without corrupting an older project by editing its common include files.
In this method of build projects, for each example project you want to make, you would create a new project folder to store all of your files that are unique to that project, including header files with your unique parameters and source files with your example programs. Then the project folder will be the "standalone" project that only reads the common files from other locations and does not alter any of those where they reside.
I am not sure that this explanation is what you want, but I would like to at least give you the chance to tell me one way or the other.
"They should be included in the build process, but any project-specific parameters should be placed in other header files that are local to your project."
Yes, it is the only way to have less Independence of TI library and header files changes.
There are many (header) files which are project specific (for pwm, capture, encoder..) but obviously there is no other way for solving this problem.
Thanks for comments.
If we have misunderstood your intent, you are welcome to describe it more and we can try to make other recommendations. Perhaps you are looking for Configuration Management tools or you want to put your project on a USB Flash drive for portability or you want to duplicate all of the relevant CCS tool/library tree within your local project or something else that you want to do. My posting above was based on what I thought you wanted, but more description or explanation why this is not what you were looking for, this will help me or someone else point you in the right direction for your requirements.
If you are looking for a tool that will search for dependencies in a project and collect the files in a specific location so that you can move them to another system to build and debug I do not know of such a tool (though that would be handy).
Typically when I make a 'portable' project I am willing to accept that the system that it will be built on later will have to have certain prerequesite requirements (i.e. a certain BIOS version, code gen version, etc) so that the very generic header files (such as stdio.h) and perhaps libraries that would normally be found in CCS are there. This being said, what I have done when I need to make a 'portable' project would be to copy the basic project files into a seperate folder somewhere on the system and try to build it, collecting files and putting them in the new folder based on the errors that come up trying to build in this seperate folder until it builds on its own. This way you can get rid of dependencies on files that are put relative to the project (i.e. it looks up two directories and than in an include folder or something) which are common in the complex multimedia projects I tend to work with.
Finally, here is such organization: I made one portable folder with all files (libraries, and basic source, header.. files) with appropriate local paths.
Application related files is to be added when I start new to solve new task.
If there are missing some files, they are added on "compile error based" principle, until there are no more errors.
It is something like in above (Bernie' s) post.
Thanks everybody.
It's weird replying to a 3 year old post. I don't know who involved in this thread is still in a position to respond.
Anyway, I'm new to CCS and the TMS320F2801 but not to coding and to IDEs. I inherrited a program written using CCS v3.3 for the '2801 and have to modify it. Whoever designed the software used the Example environment (tidcs\c28\DSP280x\v120) but left all kinds of modified and duplicate files and directories lying around, in addition to using the debug configuration for the released software and not providing any documentation.
Fortunately, we have the computer it was developed with. In production, the current method of loading these DSPs is to start CCS on the computer, open a certain workspace, load the '.out' file and program the device via the xds510pp. In order to verify that I had the complete, correct project as a starting point I created a new project in a separate directory and copied each file from the original project into it, making sure that the correct file was included by checking the path to each file in the original project using the project explorer. I then set all the new project build settings equal to the old project build settings and modified the paths to point to the new project directory so al the file paths are $(Proj_dir), $(Proj_dir)/Debug or $(Proj_dir)/Release.
Building the project results in no errors and one warning about the code entry point being other than '_c_int00', the same as the original project. The only problem is that the new software build doesn't work and the Flash checksum doesn't match the original.
I've been playing with it for a couple of days and can't find a problem.
Any thoughts?
Thanks,
Frank
Hi Frank,
Sorry for the delay. It is recommend to create a new thread in cases like this instead of adding on to an old thread that has been closed (answered). These closed threads tend to get passed over since we think the issues in the thread have been resolved.
Now back to your issue:
Frank Bell said:The only problem is that the new software build doesn't work and the Flash checksum doesn't match the original.
Could you describe "doesn't work"? I'm guessing that the program does not run as expected. How has this been verified? Does it not run at all or does it fail at a certain point?
Frank Bell said:Fortunately, we have the computer it was developed with.
Does this mean that the exact version of CCS originally used to create the project is still on there? And the same compiler version?
Thanks
ki
Hi Ki,
Thanks for the response.
On the original machine, CCStudio_v3.3 and tidcs (the example folder), are both folders on the C: root directory. Setup CCStudio v3.3 and SdConfig v3.3 had been run previous to my involvement to setup the IDE and emulator environments. The target application had been built based on the provided examples and the saved, along with a workspace. When production wanted to program a device with the application program, they started CCS with the Spectrum Digital XDS510PP emulator and a target board attached. They opened the saved workspace which included the application build and output file and ran the programmer. They would then mount the programmed, target system in an automatic calibration system which provided an indication of success or failure when the calibration cycle was complete.
When I was asked to look at this program, which is completely undocumented and uncommented, the first thing I did was to verify that a programmed target passed calibration and then read the checksum and copied the tidcs folder to my C: root directory. I installed CCS v3.3 (3.3.38.2) on my machine and set up the IDE and emulator as close as I could to the old, production setup. I loaded the workspace, built the project, programmed the target, ran the calibration and checked the checksum. Everything seemed to be OK.
Next, I went back to the old machine and made a list of all the files in the project so I could remove the project from the example folder. This included 24 .h files, 1 .lib file, 9 .c files, 3 .asm files, 2 .cmd files and 1 .pjt file. This compares to the example folder (C:\tidcs\c28\DSP280x\v120) and subfolders, which include 380 files in 75 hierarchical folders.
On my machine I made a new folder, copied all the project files into it and changed all the build option file pathways to point to the single, new directory instead of the original, various directories in the example folder.
Using CCS on my machine I built both projects, with identical files, without errors. They both had a warning regarding code entry point but that was all. The example environment project build passed the calibration test. The stand-alone environment project build did not pass the calibration test. The checksums from the 2 builds don't match. The identical list of files is present and I believe that all the build options are the same. I have a spreadsheet of the project explorer window contents. If you want I can send it.
Any help would be appreciated. Thanks,
Frank
Frank Bell said:I installed CCS v3.3 (3.3.38.2)
Note that this is the CCSv3.3 release version. There has been many service releases for 3.3 after this. But if this is the same version as on the original machine (where everything was working), then this should be fine - especially since the example project on your machine passed.
Frank Bell said:On my machine I made a new folder, copied all the project files into it and changed all the build option file pathways to point to the single, new directory instead of the original, various directories in the example folder.
Using CCS on my machine I built both projects, with identical files, without errors. They both had a warning regarding code entry point but that was all. The example environment project build passed the calibration test. The stand-alone environment project build did not pass the calibration test. The checksums from the 2 builds don't match. The identical list of files is present and I believe that all the build options are the same.
Could you generate a map files and ofd output (plan text file format to file) for both executables, zip them up and attach them here?
more details on ofd can be found in section 10.1 of:
http://www.ti.com/lit/ug/spru513e/spru513e.pdf
Thanks
ki
Hi Ki,
I copied the example direcetory to my computer and then created a new stand-alone project folder there. Version 3.3.38.2 of CCS was then used to build both projects, the example one which worked and the stand-alone one which didn't.
Thanks,
Frank
Frank,
Could you attach the memory map and ofd information to this thread?
Thanks
ki
Ki,
Attached are the map files from the successful example folder build (good build.map) and the unsuccessful stand-alone folder build (bad build.map). What is "ofd" information?
Thanks,
Frank
Hi Frank,
The details of OFD was in my last post. Here it is again;
Ki-Soo Lee said:Could you generate a map files and ofd output (plan text file format to file) for both executables, zip them up and attach them here?
more details on ofd can be found in section 10.1 of:
Thanks
ki
Ki,
I don't see the'zipfile' instruction in your previous post. That's why I just attached the .map files. Did you get them or do non-zip files get blocked? Also, I have no experience with CCS command line. Entering the command from a DOS promt resulted in an error.
Thanks,
Frank
Ki,
I don't see my latest reply posted here. I attached map files for the successful and unsuccessful builds. I'm attaching them here again. I also mentioned in the last post that I don't know how to run the command line interface. The command window within CCS is for debug commands only and opening a DOS command window resulted in an unknown command error when I tried to execute the ofd2000 command.
Thanks,
Frank
Frank,
There is no file attached to either post. What method are you using to try to attach the file?
When editing your reply, you may click on the Options link above the previous post ("Compose | Options | Preview |") and there is an option to attach a file. If this is how you are doing this, then rename the file to use the .txt extension and try again.
Regards,
RandyP
Hi Randy,
I clicked the 'Insert File' icon above the text entry window of the reply screen. I attached two '.map' files to the first reply and zipped the files before attaching the single '.zip' file to the second reply.
I've attached the same zipfile to this reply using the same method and gotten an 'upload successful' response, the same as received before.
Thanks,
Frank
Frank,
There is still no file attached. Please try the method I described in my previous post.
Regards,
RandyP
Good Morning Randy,
Did you get the zipped .map files from my last Tuesday post?
Thanks,
Frank
Frank,
Your attachment does now appear on this thread. That was what I was trying to help you with. I do not know the answer to your actual question. You will want to refer back to Ki-Soo Lee's replies to your posts on this three-year-old thread, and perhaps to the information in the earlier part of the thread if those are applicable to your question.
I am still concerned about the problems that you and others have had with attaching files. It works in some cases and not in other cases.
Sorry that I am unable to help further.
Regards,
RandyP