 |
 |
| View previous topic :: View next topic |
| Author |
Message |
RLScott
Joined: 10 Jul 2007
Posts: 465
|
| Special recognition of FSR0 register address |
 Posted: Sun Aug 23, 2015 8:09 am |
 |
|
My ISR is #INT_GLOBAL, therefore I am responsible for saving whatever needs saving. So I was saving and restoring the FSR0H and FSR0L register in a PIC18F24K22. In the restore, I noticed that it compiled like this:
| Code: |
.................... FSR0L = savedFSR0L;
01E0: CLRF FEA
01E2: MOVFF 4E,FE9
.................... FSR0H = savedFSR0H;
01E6: MOVFF 4D,FEA
|
I thought it curious that there was a CLRF FEA at the beginning. So I experimented. I defined my own symbol of:
| Code: |
#byte myfsr0 = 0xfe9
|
and it compiled the same way, with a seemingly unnecessary CLRF FEA at the top. Then I changed 0xfe9 to 0xfe3, and now the CLRF is no longer emitted by the compiler. So the compiler must be explicitly checking target addresses for 0xfe9 and doing something special with it. Why?
By the way, I eventually sidestepped the whole question by saving and restoring FSR0 as 16-bit words:
| Code: |
#word FSR0 = 0xfe9
unsigned int16 savedFSR0;
.................... savedFSR0 = FSR0;
0022: MOVFF FEA,50
0026: MOVFF FE9,4F
.................... FSR0 = savedFSR0;
0206: MOVFF 50,FEA
020A: MOVFF 4F,FE9
|
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19337
|
|
| Posted: Sun Aug 23, 2015 10:29 am |
|
|
The compiler knows that the FSR, is a 16bit register.
You have to remember that #byte, will generate a 8bit variable at an address, or if there is already a variable of the same name, it locates this at the address, and does not change the variable size.
The compiler knows the register is 16bit, so when you write an 8bit value to this, it knows it has to clear the high byte..... |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Tue Aug 25, 2015 2:00 pm |
|
|
| Ttelmah wrote: | The compiler knows that the FSR, is a 16bit register.
You have to remember that #byte, will generate a 8bit variable at an address, or if there is already a variable of the same name, it locates this at the address, and does not change the variable size.
The compiler knows the register is 16bit, so when you write an 8bit value to this, it knows it has to clear the high byte..... |
It still seems strange that the compiler would ignore my explicit instruction to address FSR0L as an 8-bit target of the move. Does this happen with every 16-bit register pair, like TMR1L? Even if I have a 16-bit variable in my program (not a SFR), I expect that when I ask the compiler to address only one byte of that variable, I expect the compiler to do it without touching the other byte. Something like:
| Code: |
unsigned int16 var;
#byte var_L = var
var_L = 25;
|
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19337
|
|
| Posted: Wed Aug 26, 2015 1:50 am |
|
|
it's specific to the FSR only, and relates to an erratum. Problem is finding it. It doesn't apply to your chip, but I suspect CCS coded the fix as 'generic'.
On certain chips if writing to FSR0L, you must write to FSR0H the instruction before. So if you do an 8bit access to FSR0L, they write FSR0H (clear it). Stupid thing is that if you reverse the accesses (so you are writing to FSR0H the instruction before), it still leaves the clear there!.....
Also, beware that CCS will have the 'Don't use RETFIE 1' erratum ticked for your chip. This is because it applies to chips like the 8722, and it got left on for the K22. If writing your own global handler, you want this turned off.... |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Fri Aug 28, 2015 10:09 am |
|
|
| Ttelmah wrote: | it's specific to the FSR only, and relates to an erratum. Problem is finding it. It doesn't apply to your chip, but I suspect CCS coded the fix as 'generic'.
On certain chips if writing to FSR0L, you must write to FSR0H the instruction before. So if you do an 8bit access to FSR0L, they write FSR0H (clear it). Stupid thing is that if you reverse the accesses (so you are writing to FSR0H the instruction before), it still leaves the clear there!.....
Also, beware that CCS will have the 'Don't use RETFIE 1' erratum ticked for your chip. This is because it applies to chips like the 8722, and it got left on for the K22. If writing your own global handler, you want this turned off.... |
Wow, thanks for all the research! Good to know.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Fri Aug 28, 2015 10:22 am |
|
|
| Ttelmah wrote: |
Also, beware that CCS will have the 'Don't use RETFIE 1' erratum ticked for your chip. This is because it applies to chips like the 8722, and it got left on for the K22. If writing your own global handler, you want this turned off.... |
I don't know where that tick box is, but that could be because I am using command-line PCH in MPLAB, not the PCW IDE. In any case, my ISR ends with a #ASM where I explicitly call for RETFIE 1, which does get encoded into as Hex(11), or RETFIE 1.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
|
|
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
