View previous topic :: View next topic |
Author |
Message |
levdev
Joined: 19 May 2010 Posts: 36 Location: UK
|
PIC18F26K22 ROM usage |
Posted: Sat Feb 05, 2011 2:12 am |
|
|
I've just recently modified the design of an existing product, and switched from the PIC18F26K20 to the PIC18F26K22. Both of these devices have 64K program memory.
Nothing in my code has changed except
Code: | #include <18F26K20.h> |
has changed to
Code: | #include <18F26K22.h> |
Previously it compiled into 3714 lines of code using 10% ROM, now it compiles into 3801 lines of code using 90% of the ROM.
Can anyone help me to explain why the ROM usage is claiming to have increased so significantly when the actual compiled code length has hardly changed. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
levdev
Joined: 19 May 2010 Posts: 36 Location: UK
|
|
Posted: Sat Feb 05, 2011 6:16 pm |
|
|
Compiler version is 4.118.
Have read the other thread thanks for the link (not quite sure why I didn't find that post when searching about this problem). It seems to be the same problem for the same device, but doesn't give a solution.
I have opened this part in the device editor and it shows under memory:
Program(words) : 32768
which I think is correct, and is the same as the PIC18F26K20 which does not have the same problem. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Feb 06, 2011 3:04 pm |
|
|
I made a test program which will allow me to work on the problem:
Code: |
#include <18F26K20.h>
#fuses XT,NOWDT,PUT,BROWNOUT,NOLVP
#use delay(clock=4000000)
#include <math.h>
//======================================
void main(void)
{
float a, b, c;
a = sin(b);
a = tan(b);
a = ceil(b);
a = exp(b);
a = log(b);
a = sqrt(b);
a = floor(b);
a = fmod(a, c);
while(1);
}
|
With PCH vs. 4.118 for the 18F26K20, this program compiles to about
10% of ROM. Here is the first part of the .LST file:
Code: |
CCS PCH C Compiler, Version 4.118, xxxx 06-Feb-11 13:00
Filename: C:\Program Files\PICC\Projects\PCH_Test\PCH_Test.lst
ROM used: 6584 bytes (10%)
Largest free fragment is 58952
RAM used: 16 (0%) at main() level
102 (3%) worst case
Stack: 4 locations
*
00000: GOTO 186E
.................... #include <18F26K20.h>
|
Then I changed only the #include line (to 18F26K22.h) and this is what I get:
Code: |
CCS PCH C Compiler, Version 4.118, xxxx 06-Feb-11 13:02
Filename: C:\Program Files\PICC\Projects\PCH_Test\PCH_Test.lst
ROM used: 6588 bytes (10%)
Largest free fragment is 58948
RAM used: 16 (0%) at main() level
102 (3%) worst case
Stack: 4 locations
*
00000: GOTO 186E
.................... #include <18F26K22.h>
|
It's only different in the reported ROM size by 4 bytes.
Run this test and see what you get. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Feb 06, 2011 3:07 pm |
|
|
With regard to the other test, when I run the program shown below
I get the following result, which is 64K of ROM:
Quote: |
ROM size is: 00010000
|
Code: |
#include <18F26K22.h>
#fuses INTRC_IO,NOWDT,PUT,BROWNOUT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, UART1, ERRORS)
//======================================
void main(void)
{
printf("ROM size is: %lx \r", getenv("PROGRAM_MEMORY"));
while(1);
}
|
If you don't get the same results as I get in this post and the previous post
then you may have a defective sub-version of vs. 4.118. Re-download
the file from CCS and install it. See this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=44550&start=15 |
|
![](templates/subSilver/images/spacer.gif) |
levdev
Joined: 19 May 2010 Posts: 36 Location: UK
|
|
Posted: Sun Feb 06, 2011 5:16 pm |
|
|
Thanks for your reply. I ran your first test program and got the same results, 10% ROM for both the 18F26K20 and the 18F26K22.
However, I re-ran the test with my code and still had the original problem.
So I realise there must be something different in my code, and so took the scientific approach of deleting stuff until the problem went away. Which it did when I deleted the line:
You can see the same problem will occur with your test program. Having this directive with the PIC18F26K20 doesn't make much difference, but with the PIC18F26K22 increases the supposed ROM usage to 90% (although the output code is still the same size).
So I feel like we are getting closer to the problem but I still don't understand this, and it's going to cause me a big problem soon as my code grows a bit more in coming days I wont be able to use the debug mode of the ICD. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Feb 06, 2011 5:29 pm |
|
|
Quote: |
So I realise there must be something different in my code, and so took
the scientific approach of deleting stuff until the problem went away.
Which it did when I deleted the line:
#device ICD=true
|
I don't know how to solve this. Ask CCS if they know about it. |
|
![](templates/subSilver/images/spacer.gif) |
levdev
Joined: 19 May 2010 Posts: 36 Location: UK
|
|
Posted: Mon Feb 07, 2011 1:57 am |
|
|
OK, will email ccs with the details today. Thanks for your help getting this far. |
|
![](templates/subSilver/images/spacer.gif) |
|