|
|
View previous topic :: View next topic |
Author |
Message |
valemike Guest
|
using #device *=16 on PCM causes Out of ROM error |
Posted: Thu Apr 01, 2004 9:12 am |
|
|
(PCM)
I am making a new post on this because have encountered a new problem while solving a previous post.
Here's how it goes:
Previously using the default 8-bit pointers lets me compile just fine, but then i end up not being able to access the entire range of pointer address space.
So I decided to use the directive #device *=16
to make 16-bit pointers.
So now, I end up breaking something else:
Code: |
fxn_state_program_entry
Seg 0800-0FFF, 0547 left, need 0963
Seg 1000-17FF, 0800 left, need 0963
Seg 1800-1FFF, 0800 left, need 0963
Seg 0000-0003, 0000 left, need 0963
Seg 0004-07FF, 0013 left, need 0963
main
*** Error 71 "C:\mikedownloaded\zec\zec_example_separated.c" Line 1713(0,1): Out of ROM, A segment or the program is too large
|
Now i'm totally lost on how to interpret what the error above means. Is there a problem in fxn_state_program_entry()? Or is it in main()? I looked at the FAQ, and tried using the #separate directive to inhibit INLINE optimization of some of my suspect functions, but then I get similiar errors with other functions, and it goes on and on.
What is the strategy to avoid this?
1. Break up my really big functions into smaller chunks?
2. Use the pricier 18F micro equivalent? (I like this one better!) |
|
|
SteveS
Joined: 27 Oct 2003 Posts: 126
|
|
Posted: Thu Apr 01, 2004 10:26 am |
|
|
Adding the #device *=16 directive added code and evidently made a function overrun where it once fit. fxn_state_program_entry() looks to be the culprit - so break it up somehow into smaller functions. You may need to explicitly force the smaller functions as #separate, or else the compiler may just try to 'inline' them, putting you back where you started.
Yes, another reason to go to the 18F!
-SteveS |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Apr 01, 2004 11:57 am |
|
|
Using 16-bit pointers will generate more ASM code.
For example, take this simple program:
Code: | #include <16F877.h>
#device *=16 // enable 16-bit pointers
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock = 4000000)
char array[10];
//=====================================
main()
{
*array = 0x55;
while(1);
} |
Here is the code generated without 16-bit pointers.
(ie., without the #device *=16 statement).
Code: |
........ *array = 0x55;
000A 3020 00283 MOVLW 20
000B 0084 00284 MOVWF 04
000C 3055 00285 MOVLW 55
000D 0080 00286 MOVWF 00 |
Here is the code with 16-bit pointers.
Code: |
........ *array = 0x55;
000B 01FA 00285 CLRF 7A
000C 3020 00286 MOVLW 20
000D 0084 00287 MOVWF 04
000E 1383 00288 BCF 03.7
000F 187A 00289 BTFSC 7A.0
0010 1783 00290 BSF 03.7
0011 3055 00291 MOVLW 55
0012 0080 00292 MOVWF 00
|
So depending on how much pointer usage you do,
your program could easily expand in size.
---------------------------------------------------
I think the problem is that you are converting a PCH program
to a PCM program. In the 18F series PICs, you have many
more resources than in the 16F. I wonder if this is part of
your problem. The 18F series has 31 stack levels, whereas
the 16F has only 8. When you ported the PCH code to PCM,
I believe you may have added a lot of #separate statements
to the code, in order to make it fit in the 16F877 ROM segments.
But when you use #separate, the CCS compiler no longer does
stack checking. It will let you use more than 8 stack levels without
complaining. This will cause your program to blow up or behave
erratically. If you use #separate, you need to check the top of
the .LST file, to see your stack usage. It must be no more than
8 levels with a 16F877. You have to manually do this check,
every time you compile your code. |
|
|
valemike Guest
|
|
Posted: Thu Apr 01, 2004 1:09 pm |
|
|
Thanks PCM and Steve for your hints.
I'm going to try making my functions smaller now.
The only reason i started using #separate today (prior to that i never used it) was to try to fix the compile errors i encountered when i chose #device *=16 for 16-bit pointers.
I will try to stop using the pointer in my suspect function, since it is very very long. After all, these pointers just reference global variables anyways, so might as well just manipulate them directly rather than thru a pointer. We'll see how it goes... |
|
|
|
|
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
|