Bank switching in PIC mcu

Question

Usually I do a banksel before every GPR access but I find that I have many unecessary lines. So, the question is this. I do some calls to subroutines that access diferent memory banks than the calling routine. Is it a good idea to save in a GPR, the STATUS register, for maintaining the current bank and switch back to it before returning or what is the optimal way of doing this?

Answer 1

There are many ways of going about this, and alot will depend on how clever you want to be, how much code space you want to save, and how time critical your code needs to be. There's a trade off between trying to save code space / time, and then running the risk of being in the wrong bank at the wrong time accidentally.

I prefer the safe option here...

What I do is, for any Sub that is likely to change the Bank, then I write a small "Calling Sub" which backs up the GPR status. The "Calling Sub" then calls the "Real Sub", which can change the Bank as much as it likes. When the "Real Sub" exits, it returns to the "Calling Sub", which then restores the Bank back to what it was, before returning to your program loop

Psuedo Code:

CALL_MYSUB        BACKUP STATUS
                  BACKUP GPR
                  CALL MYSUB
                  RESTORE GPR
                  RESTORE STATUS
                  RETURN

You can get clever with the above and write a small Macro that replaces the Storing and Retrieving code, which simplifies how your code looks, and improves maintainability... It uses the same code space of course mind you.

Psuedo Code:

CALL_MYSUB        BACKUP_MACRO
                  CALL MYSUB
                  RESTORE_MACRO
                  RETURN

In theory, if you are likely to have any more than two instructions to backup, and two to Restore, then instead of a macro, you'd make a single Backup Routine, and a Single Restore Routine, and call these instead;

Psuedo Code:

BACKUP_CONTEXT    BACKUP STATUS
                  BACKUP GPR
                  BACKUP OTHER THINGS
                  BACKUP MORE STUFF
                  RETURN

BACKUP_CONTEXT    BACKUP STATUS
                  BACKUP GPR
                  BACKUP OTHER THINGS
                  BACKUP MORE STUFF
                  RETURN

RESTORE_CONTEXT   RESTORE MORE STUFF
                  RESTORE OTHER THINGS
                  RESTORE GPR
                  RESTORE STATUS
                  RETURN

CALL_MYSUB        BACKUP_CONTEXT
                  CALL MYSUB
                  RESTORE_CONTEXT
                  RETURN

You could of course, incorporate the above directly into each sub which requires it. But I preferred the above, as it allows you to call the sub without the Backup and Restore if you want, keeps your sub about what it is trying to do, allows you to place all of the similar calls in one place, allowing you to make changes in one place, and makes it obvious that the sub is going to change the GPR.

The only thing to be careful of here is making sure you don't have too many nested Calls, which would overflow the stack of course!

I hope this helps....

EDIT:

If all you need to do is backup your Bank Select Bits and nothing else, You may try the following...

Store only Bank Select Bits;

MOVF        STATUS,w        ;Get the Current Bank Select bits
ANDLW       B'01100000'     ;Remove all but the Bank Select bits
MOVWF       TEMP1           ;Store in a Temporary Register

Retrieve only Bank Select Bits;

MOVLW       B'10011111'
ANDWF       STATUS,1        ; Clear the Bank Select Bits   
MOVF        TEMP1,w         ; Get the Old Bank Select Bits
XORWF       STATUS,1        ; Restore Old Bank Select Bits

However, I've not got any of the environment here, so I can't confirm if this works 100%, but the maths is fine I think!

I have also assumed you are using the 16c77, which has RP1 at STATUS Bit 6 and RP0 at STATUS Bit 5.

Of course, if you need the IRP bit as well, then you'll need to store STAUTS Bit 7 - IRP aswell

You'll also need to make sure that TEMP1 is stored in GPR, so that it is unbanked.

Answer 2

I would suggest that the simplest approach is probably to state as global policy that unless specified otherwise, each routine will assume that RP0 and RP1 are clear on entry; IRP is set as appropriate for whatever is loaded in FSR if anything, and otherwise unspecified. On exit, unless specified otherwise, every routine should leave RP0 and RP1 clear and may do whatever it wants with IRP (though if a routine will never do anything with IRP, it may be useful for it to document that fact).

Code which "sits" in bank 0 will thus not have to do anything with the banking bits except when using FSR. Code which accesses another bank will have to reselect bank 0 before making any subroutine calls or returning to the caller.

In some cases it may be useful to have a few special methods which specify different behavior, but this "formula" should be pretty good in many cases. The key thing is to have a rule that most methods will follow, and make clear that any methods which don't use that rule are clearly documented.

Answer 3

I used two macros:

m_SaveBank macro Var

clrf Var
btfsc STATUS,RP1
bsf Var,RP1
btfsc STATUS,RP0
bsf Var,RP0

endm

m_RestoreBank macro Var

bcf STATUS,RP1
bcf STATUS,RP0
btfsc Var,RP1
bsf STATUS,RP1
btfsc Var,RP0
bsf STATUS,RP0

endm

The subroutine must first saves STATUS.RP1 & RP0 and then restore them on exit. W register stays untouched as most times carries data for the subroutine and STATUS bits other than RP0 & RP1 stay unaffected too. I spare eleven words this way, but i don't think there is any other alternative.