|
|
View previous topic :: View next topic |
Author |
Message |
seidleroni
Joined: 08 Sep 2008 Posts: 21
|
Have used CCS for years, need to use C18 for one project... |
Posted: Thu Oct 01, 2009 6:19 pm |
|
|
I have used CCS's compiler for years (5 years to be exact) and have been very happy with it. However, for a "side job" I am required to use C18. What are some of the things I should know, or "gotcha's" which need to be on my mind. I am looking for specific details. Using CCS for this is out of the question.
What are the major differences when using C18 when one is used to working with CCS? |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Thu Oct 01, 2009 11:22 pm |
|
|
If you are planning to use the student edition then expect the code size to increase significantly one the grace period expires. Based on my experience (your mileage may vary) Code developed for CCS is about 25% larger when ported to C18.
If you are doing anything fancy, such as developing a bootloader, then the C18 linker script is a real pain. Every time you change PICs within the same family, you need to change linker scripts. If the linker script is modified for your application, such as a bootloader, then you must modify a linker script for every variant. This is not the case with CCS.
CCS has lots of Macros and, when they work, are a real time saver. You need to do this yourself with C18 although there are some low level macros to help.
There is no equivalent to the #use RS232 in C18, you need to do your own ground work. C18 does not automatically set TRIS for you.
Working with linker scripts to place variables at specific locations or map to registers is messier with C18 but on the other hand, if you do write to registers directly, which is something I do all the time, you do not have to specify where the register exists as this is done for you in the C18 header file for the PIC. This is a great time saver.
C18 lacks the driver support of CCS.
I sell drivers for CCS and C18. Typically I develop first for CCS and then port to C18. If find it quicker to develop and debug in CCS. Once this is done and I know the logic is correct, I then port to C18. Note this is only true for the C18 family. For the PIC24 even today the CCS version is not up to scratch compared to the C30 compiler. I finally gave up working on porting my file system to PCD (for the time being) because I could not get it running. I took this non running code and ported it to C30 and it ran first time.
A couple of months ago I upgraded my CCS compiler because I received a email from CCS heralding the arrival of 4.1 and I thought this would let me get on with the file system port. However there is no 4.1 release and my software still does not run on 4.099 (yes I am annoyed that I upgraded to a product that does not exist). _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
seidleroni
Joined: 08 Sep 2008 Posts: 21
|
|
Posted: Fri Oct 02, 2009 6:13 am |
|
|
I will be using the "full" version, not the student edition.
What kind of macro's does CCS provide that C18 does not? Would it be terribly difficult to do them myself? Also, I don't believe I will need to develop a bootloader, as one is not necessary for this project.
For instance, is it just a matter of changing syntax, or is there stuff which is vastly different? If so, what? |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Oct 02, 2009 11:17 am |
|
|
I found the same things with C18.
I converted a project from C18 once to CCS because of the lack of easy "streams" support via #USE RS232.
When I finished the conversion, not only was my 2 streams worth of life easier, but I got back about 30% PROM space on the PIC.
CCS does a lot of things for you. And that's nice -- just always know to look at the resulting code.
I just analyzed read_program_memory and found it's very wasteful for single reads. (about 30 instructions) that if I set up the transaction myself, I could optimize the read down to about 8 instructions.
However, if I had to do multi-byte reads, their code is spot on.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
seidleroni
Joined: 08 Sep 2008 Posts: 21
|
|
Posted: Fri Oct 02, 2009 11:54 am |
|
|
Yes, but what else did you like (other than #USE RS232) that C18 did NOT have that CCS did have (or vice versa?) |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Oct 02, 2009 12:05 pm |
|
|
Because I didn't dig too deeply, I probably didn't find a lot of other things I didn't like..
But the general impression I got was that I would have to write a lot of basic stuff myself from scratch or the libraries included would make things only marginally easier.
As asmallri states, CCS seems to make better use of memory and code typically is a lot tighter than with C18. I've actually hand checked this stuff myself (not just looking at how much less space PCH compiled code takes, but WHY)
Also, as asmallri said, PCD is another matter. I'm find PCD is still in the growing stages and C30 would probably be easier with as many routines as I end up having to write myself.
However, I expect with all my bug reports with PCD that it eventually will be just as nice to use as PCH rendering C30 back to the PITA ranks as C18.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
seidleroni
Joined: 08 Sep 2008 Posts: 21
|
|
Posted: Fri Oct 02, 2009 12:09 pm |
|
|
What "basic stuff" are you referring to would you have to write yourself? |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Oct 02, 2009 12:18 pm |
|
|
When I used C-18 last, printf only went to stdout.
If you had more than 1 output stream, you could set up the second stream, but then you'd have to write something to printf to it.. C18's built in printf at the time didn't handle sending to someplace other than stdout.
Eww...
It was 4 years ago.. so all the other itchy stuff is escaping me now..
I vaguely recall having to write my own interrupt handler.
I also recall that all the headers were essentially geared towards bit-twiddling everything by bit.
I just remember looking at stuff thinking, "this isn't very C -like. It looks like someone took ASM libraries and scripted them into C"
In fairness, it could be a lot different now... and it could have also been my limited exposure back then and needing to get something done quickly. _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Fri Oct 02, 2009 3:52 pm |
|
|
seidleroni wrote: | What "basic stuff" are you referring to would you have to write yourself? |
Here is an easy way to see what will be different. Look at one page of your own code that does something with a peripheral. Put a line through every line that you would expect to see unchanged in any way running on a PC or a MAC. Whatever you find is different will be the same difference between C18 and CCS.
See anything with "set_up", bit_set, bit_clear, #use, or anything PICish
Expect some of your variables types to be a different size (short), there is no BOOLEAN in C18
There are lots of differences. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|
|
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
|