 |
 |
| View previous topic :: View next topic |
| Author |
Message |
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
 Posted: Fri Jul 25, 2014 6:59 pm |
 |
|
Ttelmah...
You seems to only use the command line compiler for your projects.
Is there any downside using this method?
I might switch to that so I could do some scripting to insert build number instead.
Do they have a manual for the command line parameters. I think the manual is for the IDE that they supply with PCWHD.
thank you!
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 20063
|
|
| Posted: Sat Jul 26, 2014 1:14 am |
|
|
No.
I think PCM_programmer does as well.
I actually use the IDE too (which I don't think he does), but have a simple shortcut on the desktop, to a very short script, which does my 'send to customer' build. This also moves the result onto the network, where it can be emailed for testing, and saves the source files into an archive. When I've got the code to the point where it compiles OK, and is ready to send, I click this, which automatically generates a new 'version' in the archive, and updates the serial. This way, if he comes back and says 'V23 was OK, but there is a problem in this function on V24', I have the hex, lst, and sources, for each, together with a record of what changes between versions (I run a header file, with a 'text note' of what I changed between versions), so it has lines like:
V23 Using 5.010, updated menu display (parseadio.h)
I record the compiler used as well, and archive this with the code. In this case 'parseadio.h', was where the changes were made.
This is vital for me, since I probably have five or six projects 'live' at a time, waiting for testing, and perhaps several hundred 'historical' projects that I may have to go back to. Had one yesterday, where there was a query about the ability to handle a several decade 'over-range', on a routine written nine years ago. I've got code in the archive (in assembler), that dates to before Microchip even officially launched the PIC! (I had to point out to them when they did a 'history of the PIC' on their website, that I had product using some of the chips before the first date they gave...).
I actually prefer the control the scripting gives, since you can be confident of which compiler is being used, which version include files are being used, etc. etc.. Problem is that CCS in the IDE, will generally keep using the include files for when a project was first built, not changing these with a compiler version upgrade, and with the ability to change compilers used in the IDE, you can be very unsure 'which compiler version', 'which include version', etc..
Dangerous, and makes keeping 'track', of where a problem actually appears from, very difficult. So you may be using V5.026, but are you actually using it's include files?.
It's like 'not using the Wizard', but instead writing your own simpler include file for the processors, and just loading one of these to start the project. far less likely to give hidden problems.... |
|
|
jgschmidt
Joined: 03 Dec 2008
Posts: 184
Location: Gresham, OR USA
|
|
| Posted: Sat Jul 26, 2014 8:20 pm |
|
|
As drolleman said, use __date__, __time__, and/or __file__. I generally reserve a pin for serial debugging and displaying this information is ALWAYS my second step after LED blink testing. Any systems with a display will show this at power-up. Since I archive by date/time stamp, it's easy to match up a system with it's source code.
_________________
Jürgen
www.jgscraft.com |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Sun Jul 27, 2014 9:54 am |
|
|
| Quote: | No.
I think PCM_programmer does as well.
I actually use the IDE too (which I don't think he does), but have a simple shortcut on the desktop, to a very short script, which does my 'send to customer' build. This also moves the result onto the network, where it can be emailed for testing, and saves the source files into an archive. When I've got the code to the point where it compiles OK, and is ready to send, I click this, which automatically generates a new 'version' in the archive, and updates the serial. This way, if he comes back and says 'V23 was OK, but there is a problem in this function on V24', I have the hex, lst, and sources, for each, together with a record of what changes between versions (I run a header file, with a 'text note' of what I changed between versions), so it has lines like:
V23 Using 5.010, updated menu display (parseadio.h)
I record the compiler used as well, and archive this with the code. In this case 'parseadio.h', was where the changes were made.
This is vital for me, since I probably have five or six projects 'live' at a time, waiting for testing, and perhaps several hundred 'historical' projects that I may have to go back to. Had one yesterday, where there was a query about the ability to handle a several decade 'over-range', on a routine written nine years ago. I've got code in the archive (in assembler), that dates to before Microchip even officially launched the PIC! (I had to point out to them when they did a 'history of the PIC' on their website, that I had product using some of the chips before the first date they gave...).
I actually prefer the control the scripting gives, since you can be confident of which compiler is being used, which version include files are being used, etc. etc.. Problem is that CCS in the IDE, will generally keep using the include files for when a project was first built, not changing these with a compiler version upgrade, and with the ability to change compilers used in the IDE, you can be very unsure 'which compiler version', 'which include version', etc..
Dangerous, and makes keeping 'track', of where a problem actually appears from, very difficult. So you may be using V5.026, but are you actually using it's include files?.
It's like 'not using the Wizard', but instead writing your own simpler include file for the processors, and just loading one of these to start the project. far less likely to give hidden problems.... |
Very interesting!
I finally found the manual for the compiler (ccsc.chm file).
So I could start doing automated compiling and backup.
Maybe I could write a small program that take place between the IDE and the compiler (Ccsc.exe). I'll try naming my program Ccsc.exe and then redirecting the command from the IDE to Ccsc2.exe while modifying the source code (increase version) and moving files.
| Quote: | | As drolleman said, use __date__, __time__, and/or __file__. I generally reserve a pin for serial debugging and displaying this information is ALWAYS my second step after LED blink testing. Any systems with a display will show this at power-up. Since I archive by date/time stamp, it's easy to match up a system with it's source code. |
I'll see what CCS have to offer in the next version.
It's a nice workaround you proposed.
But in another way, if nobody talk... no software gets right!
Thanks guys! 
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 20063
|
|
| Posted: Sun Jul 27, 2014 11:18 am |
|
|
This was the area I haven't investigated.
I think the IDE calls pch/pcd etc directly, which was why I suggested possibly it might be practical to redirect the use of these.
However 'guessing' only... |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Sun Jul 27, 2014 11:30 am |
|
|
| Ttelmah wrote: | This was the area I haven't investigated.
I think the IDE calls pch/pcd etc directly, which was why I suggested possibly it might be practical to redirect the use of these.
However 'guessing' only... |
I only see Ccsc.exe that is related to the compiler in the program folder...
Oh I've see the DLL folder (with pcd, pcb , pch and pcm) that might be a little more complicated...
Also I could write my own app to bind it to a global hotkey (CTRL+ F9) or intercept the F9 key directly, modify the source file then after that send a F9 keypress to the CCS IDE window.
Btw, I find kind of ironic to write a C compiler in Delphi (By my experience, it's a 2006-2010 era Delphi default build icon).
It's nice to see some people still use it beside me
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Tue Aug 12, 2014 4:30 pm |
|
|
Good news!
| Quote: | In the next release you can use __BUILDCOUNT__ as long as you have global
defines enabled for the project (OPTIONS > PROJECT OPTIONS > GLOBAL DEFINES). |
Thank you everyone and CCS
Have a nice day!
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Sun Oct 19, 2014 6:29 pm |
|
|
Kind of follow up...
__BUILDCOUNT__ still not showing in pcwhd 5.027.
I'm not currently at my work desk to check the new version 5.030.
Can somebody confirm they implemented it in the newest release?
Thank you!
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Mon Oct 20, 2014 2:03 am |
|
|
| ELCouz wrote: | Kind of follow up...
__BUILDCOUNT__ still not showing in pcwhd 5.027.
Can somebody confirm they implemented it in the newest release?
|
I'm using 5.27 and I can confirm __BUILDCOUNT__ certainly works in 5.027 if used as CCS describes. You must enable global defines in the project options, whether you use your own global defines or not.
I do have one or two issues with it: the build number is stored in the project file. If the project is compiled from more than local working copies on different PCs, such as when using SVN or other version control systems, then the build number is not guaranteed to be unique. That's to be expected but is a potential irritation. Also, the project file changes every build, which creates further issues with version control. On the whole though, its a big step forward. |
|
|
VernonAMiller
Joined: 11 Sep 2014
Posts: 25
Location: Contoocook, NH
|
|
| Posted: Mon Oct 20, 2014 6:41 am |
|
|
If you use a source control system, it can provide this capability. For example, many places I know use Subversion, which works nicely. It provides a unique build number that changes with every check-in, and if you need to re-create a particular build tree, you can just give that build number back to Subversion and it will pull out the correct revs of all files to exactly create that tree.
Admittedly, what I see are normally bigger projects. This might be too complicated for what we're talking about here, and you'd have to do it by command-line and scripting as it probably wouldn't integrate into the CCS IDE, but if you are doing big projects it's sure worth thinking about.
VAM |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
