|
|
View previous topic :: View next topic |
Author |
Message |
joe06 Guest
|
#locate allowed on 0x7F, 0xFF ? |
Posted: Mon Mar 10, 2003 4:57 am |
|
|
Hi All,
The compiler uses RAM locations 0x7F and 0xFF even if I use #reserve and #locate on these RAM locations, is it normal ?
here are my declarations :
#reserve 0x7F
#reserve 0xFF
#reserve 0x17F
#reserve 0x1FF
BYTE W_TEMP;
BYTE W_TEMP1;
BYTE W_TEMP2;
BYTE W_TEMP3;
locate W_TEMP = 0x7F
locate W_TEMP1 = 0xFF
locate W_TEMP2 = 0x17F
locate W_TEMP3 = 0x1FF
I use these 4 ram locations to save/restore W register content during interrupts (I've written my own ITR vector and ISR instead of using CCS int_xxx, for multiple reasons).
I need to preserve these locations during the ISR, CCS doenst care of my #reserve and #locate since it uses these locations for passing functions parameters into my ISR !
Any help greatly appreciated
joe.
___________________________
This message was ported from CCS's old forum
Original Post ID: 12487 |
|
|
R.J.Hamlett Guest
|
Re: #locate allowed on 0x7F, 0xFF ? |
Posted: Mon Mar 10, 2003 6:29 am |
|
|
:=Hi All,
:=The compiler uses RAM locations 0x7F and 0xFF even if I use #reserve and #locate on these RAM locations, is it normal ?
:=
:=here are my declarations :
:=
:=#reserve 0x7F
:=#reserve 0xFF
:=#reserve 0x17F
:=#reserve 0x1FF
:=
:=BYTE W_TEMP;
:=BYTE W_TEMP1;
:=BYTE W_TEMP2;
:=BYTE W_TEMP3;
:=
:=locate W_TEMP = 0x7F
:=locate W_TEMP1 = 0xFF
:=locate W_TEMP2 = 0x17F
:=locate W_TEMP3 = 0x1FF
:=
:=I use these 4 ram locations to save/restore W register content during interrupts (I've written my own ITR vector and ISR instead of using CCS int_xxx, for multiple reasons).
:=I need to preserve these locations during the ISR, CCS doenst care of my #reserve and #locate since it uses these locations for passing functions parameters into my ISR !
:=Any help greatly appreciated
What chip?...
The CCS compiler treats memory handling as a series of 'layers'. The top layer, comprises the values set in the chips specification (changeable with the device editor). This allways takes prefernce over the #reserve settings. Hence if (for instance), you need to put a value into the area normally used by the C scratch storage, you have to move this storage in the device editor, rather than using the #reserve format. The #reserve allocations, then comprise the second 'layer', followed by the normal memory useage for the code.
It is well worth remembering, that unless you absolutely 'must' use a particular location, it makes code much less likely to cause unexpected problems latter, to simply let the default C memory allocation take place. You can (for instance), code a storage area for your int handler, and transfer data to it, using code like:
static int INT_scratch[15];
#ASM
MOVFF FSR0L,INT_scratch
MOVFF FSR0H,INT_scratch+1
MOVFF FSR1L,INT_scratch+2
MOVFF FSR1H,INT_scratch+3
MOVFF FSR2L,INT_scratch+4
MOVFF FSR2H,INT_scratch+5
inside the normal 'C' syntax, without having to worry where the storage actually gets placed. :-)
Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12491 |
|
|
joe06 Guest
|
Re: #locate allowed on 0x7F, 0xFF ? |
Posted: Mon Mar 10, 2003 6:45 am |
|
|
I use a 16F877, I've tried to #locate 77, 78 without success, indeed the chip editor uses scratch ram at these addresses, I've also tried to #locate 79 to 7C without success, from what I observe these locations are reserved for fucntions parameters, saved/restored during itrs.
I cannot see any limitations on locations 7D and 7F, when using CCS ISR, 7F is used to save/restore W content, even if the #locate 7F is present.
Since I'm not using CCS ISRs, I do quite the same than CCS (save/restore 77 to 7B during ITRs, as well as W to 7F), anyway, CCS also uses 7F into my ISR ?! making my own ISR faulty.
:=:=Hi All,
:=:=The compiler uses RAM locations 0x7F and 0xFF even if I use #reserve and #locate on these RAM locations, is it normal ?
:=:=
:=:=here are my declarations :
:=:=
:=:=#reserve 0x7F
:=:=#reserve 0xFF
:=:=#reserve 0x17F
:=:=#reserve 0x1FF
:=:=
:=:=BYTE W_TEMP;
:=:=BYTE W_TEMP1;
:=:=BYTE W_TEMP2;
:=:=BYTE W_TEMP3;
:=:=
:=:=locate W_TEMP = 0x7F
:=:=locate W_TEMP1 = 0xFF
:=:=locate W_TEMP2 = 0x17F
:=:=locate W_TEMP3 = 0x1FF
:=:=
:=:=I use these 4 ram locations to save/restore W register content during interrupts (I've written my own ITR vector and ISR instead of using CCS int_xxx, for multiple reasons).
:=:=I need to preserve these locations during the ISR, CCS doenst care of my #reserve and #locate since it uses these locations for passing functions parameters into my ISR !
:=:=Any help greatly appreciated
:=What chip?...
:=The CCS compiler treats memory handling as a series of 'layers'. The top layer, comprises the values set in the chips specification (changeable with the device editor). This allways takes prefernce over the #reserve settings. Hence if (for instance), you need to put a value into the area normally used by the C scratch storage, you have to move this storage in the device editor, rather than using the #reserve format. The #reserve allocations, then comprise the second 'layer', followed by the normal memory useage for the code.
:=It is well worth remembering, that unless you absolutely 'must' use a particular location, it makes code much less likely to cause unexpected problems latter, to simply let the default C memory allocation take place. You can (for instance), code a storage area for your int handler, and transfer data to it, using code like:
:=
:= static int INT_scratch[15];
:= #ASM
:= MOVFF FSR0L,INT_scratch
:= MOVFF FSR0H,INT_scratch+1
:= MOVFF FSR1L,INT_scratch+2
:= MOVFF FSR1H,INT_scratch+3
:= MOVFF FSR2L,INT_scratch+4
:= MOVFF FSR2H,INT_scratch+5
:=
:=inside the normal 'C' syntax, without having to worry where the storage actually gets placed. :-)
:=
:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12492 |
|
|
R.J.Hamlett Guest
|
Re: #locate allowed on 0x7F, 0xFF ? |
Posted: Mon Mar 10, 2003 7:06 am |
|
|
:=I use a 16F877, I've tried to #locate 77, 78 without success, indeed the chip editor uses scratch ram at these addresses, I've also tried to #locate 79 to 7C without success, from what I observe these locations are reserved for fucntions parameters, saved/restored during itrs.
:=I cannot see any limitations on locations 7D and 7F, when using CCS ISR, 7F is used to save/restore W content, even if the #locate 7F is present.
:=Since I'm not using CCS ISRs, I do quite the same than CCS (save/restore 77 to 7B during ITRs, as well as W to 7F), anyway, CCS also uses 7F into my ISR ?! making my own ISR faulty.
:=
So use the device editor, and move the C scratch.
This allways has priority over the #reserve declarations.
Best Wishes
:=:=:=Hi All,
:=:=:=The compiler uses RAM locations 0x7F and 0xFF even if I use #reserve and #locate on these RAM locations, is it normal ?
:=:=:=
:=:=:=here are my declarations :
:=:=:=
:=:=:=#reserve 0x7F
:=:=:=#reserve 0xFF
:=:=:=#reserve 0x17F
:=:=:=#reserve 0x1FF
:=:=:=
:=:=:=BYTE W_TEMP;
:=:=:=BYTE W_TEMP1;
:=:=:=BYTE W_TEMP2;
:=:=:=BYTE W_TEMP3;
:=:=:=
:=:=:=locate W_TEMP = 0x7F
:=:=:=locate W_TEMP1 = 0xFF
:=:=:=locate W_TEMP2 = 0x17F
:=:=:=locate W_TEMP3 = 0x1FF
:=:=:=
:=:=:=I use these 4 ram locations to save/restore W register content during interrupts (I've written my own ITR vector and ISR instead of using CCS int_xxx, for multiple reasons).
:=:=:=I need to preserve these locations during the ISR, CCS doenst care of my #reserve and #locate since it uses these locations for passing functions parameters into my ISR !
:=:=:=Any help greatly appreciated
:=:=What chip?...
:=:=The CCS compiler treats memory handling as a series of 'layers'. The top layer, comprises the values set in the chips specification (changeable with the device editor). This allways takes prefernce over the #reserve settings. Hence if (for instance), you need to put a value into the area normally used by the C scratch storage, you have to move this storage in the device editor, rather than using the #reserve format. The #reserve allocations, then comprise the second 'layer', followed by the normal memory useage for the code.
:=:=It is well worth remembering, that unless you absolutely 'must' use a particular location, it makes code much less likely to cause unexpected problems latter, to simply let the default C memory allocation take place. You can (for instance), code a storage area for your int handler, and transfer data to it, using code like:
:=:=
:=:= static int INT_scratch[15];
:=:= #ASM
:=:= MOVFF FSR0L,INT_scratch
:=:= MOVFF FSR0H,INT_scratch+1
:=:= MOVFF FSR1L,INT_scratch+2
:=:= MOVFF FSR1H,INT_scratch+3
:=:= MOVFF FSR2L,INT_scratch+4
:=:= MOVFF FSR2H,INT_scratch+5
:=:=
:=:=inside the normal 'C' syntax, without having to worry where the storage actually gets placed. :-)
:=:=
:=:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12493 |
|
|
John P Guest
|
Re: #locate allowed on 0x7F, 0xFF ? |
Posted: Mon Mar 10, 2003 9:07 pm |
|
|
:=Hi All,
:=The compiler uses RAM locations 0x7F and 0xFF even if I use #reserve and #locate on these RAM locations, is it normal ?
:=joe.
On a few occasions I've tried using those locations that the compiler wants to have, and every time I've ended up regretting it. There are plenty of ways that you can kick the compiler into doing a better job, but for me this particular one has only ended up as a waste of time.
___________________________
This message was ported from CCS's old forum
Original Post ID: 12516 |
|
|
|
|
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
|