CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

FSR Problem

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
reash



Joined: 17 Sep 2007
Posts: 8

View user's profile Send private message

FSR Problem
PostPosted: Thu Aug 09, 2012 7:22 am     Reply with quote

Hello.

Anyone have any idea why I would get this in the disassembly listing?
Code:

3731:                  FSR = PADDRESS
  0072    0846     MOVF 0x46, W
  0073    0084     MOVWF 0x4
  0074    1383     BCF 0x3, 0x7
  0075    1847     BTFSC 0x47, 0
  0076    1783     BSF 0x3, 0x7

Don't understand why it created those last three lines. Why in the world is it checking RAM location 0x47, bit 0? That location is completely irrelevant.

Using PIC16F886. CCS compiler version 4.130.

Thanks,
Ryan
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Aug 09, 2012 8:37 am     Reply with quote

Remember the FSR, also needs the IRP bit set to give a 'full' address.
PADDRESS is an INT16 (hopefully, it _needs_ to be, since the combination of FSR, plus IRP, uses 9bits), so it copies the low byte into the FSR, then takes bit0 of the high byte, and copies this to the IRP (bit 7 of the status register).

The compiler is doing exactly what is needed to use the FSR.

Have a look at figure 2.8 in the data sheet, which shows how the 9bit memory address is constructed for direct addressing, and when using the FSR.

Best Wishes
reash



Joined: 17 Sep 2007
Posts: 8

View user's profile Send private message

PostPosted: Thu Aug 09, 2012 9:27 am     Reply with quote

Yes, I know indirect addressing uses both the FSR and the IRP bit. But I didn't think it would _automatically_ try to use anything for the IRP. PADDRESS is just an INT8. The compiler should not automatically try to use the adjacent byte to find the IRP bit. If you want to change the IRP bit, that should be done manually. You shouldn't have to make an INT16 just for the sake of the IRP bit. Regardless, my solution was just to force the IRP bit back to 0 in the following instruction. After all, when writing this code directly in assembly, you would write to the FSR and IRP directly. I was just curious as to why they would assume the next byte would contain the IRP bit, especially when my variable 'PADDRESS' was already defined as INT8. Very unexpected.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Aug 09, 2012 9:56 am     Reply with quote

You can.
If you just declare the FSR as a #byte but use a different name, you can write the byte to it without touching the IRP.
CCS treats FSR as a reserved word, for the _entire_ register.
So:
Code:

#byte myFSR=0x4

myFSR=val;


Generates:
Code:

012B:  MOVF   27,W
012C:  MOVWF  04


(val is an int8 variable at location 27 for me).

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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