CHK?RP, RST?RP, banksel, STATUS,RP?, BSR ...
With so many BANK options, we may need a government bailout! :D
<hr><pre>MyVarW VAR WORD<br>MyVarB1 VAR BYTE BANK1</pre>When you create a variable in PBP, you have no idea where that variable is located in RAM. (unless you specify the bank)
Normally PBP takes care of all that for you. But when working with ASM it's up to you to figure out where they are..
For 16F's, you have to change the STATUS,RP0 and RP1 bits.
For 18F's, the value of the BSR selects the bank.
The new 16F1xxx chips also have a BSR.
It can be pretty confusing to find just were those variables are.
With MPASM, you can use banksel to find which bank they are in.
The following line will select Bank1, because that's the bank that was specified for the MyVarB1 variable above.
banksel _MyVarB1
At this point, you can use any of the opcodes like MOVF, MOVWF, ADDWF, SUBWF etc. on the MyVarB1 variable.
Then if you want to access another variable, you'd do the same thing again with that variable's name.
movlw 10h ; load 16 into WREG
banksel _MyVarB1 ; find the bank for MyVarB1 (bank1)
movwf _MyVarB1 ; put the value in the variable
movlw 20h ; load 32 into WREG
banksel _MyVarW ; find the bank for MyVarW (unknown)
movwf _MyVarW ; put value in lowbyte
clrf _MyVarW + 1 ; clear the highbyte
For each one of those banksel's it will generate a MOVLB xx opcode to load the BSR register (with 18F's and 16F1's). With 16F's it takes two instructions to set both bits in the STATUS register.
It won't matter if it's already pointing to that bank, it'll still add more code to change to the bank it's already in. For long ASM programs with variables in unknown banks, the extra code can really add up.
Enter CHK?RP.
This does the same thing as banksel, except that it keeps track of what bank it's in, and only generates code if it actually needs to change banks.
It does this by setting the ASM variable PREV_BANK every time it changes banks.
In some circumstances, this can save a lot of code space.
Of course, there are good and bad with both methods.
With CHK?RP, since you don't know whether it will be generating code or not, it becomes difficult to add up instruction cycles for the "Time critical" routines. Whereas you always know that banksel will generate code, so you can just add those in to calculate real time.
With banksel, it's very important, that you return the bank to 0 before exiting ASM.
The PREV_BANK variable will still say it's in bank0, so if you don't make sure it's really in bank0, PBP will get very confused.
When using CHK?RP, you don't have to put it back to bank0 because PBP knows what bank it's in, and will just continue on.
RST?RP will reset back to bank0, if you were using CHK?RP.
It also updates PREV_BANK.
It will have no affect after a banksel.<hr>
There are many problems that can happen when using CHK?RP and goto's or branch's in the asm routine.
If you jump over a CHK?RP with a goto, then PREV_BANK won't reflect the correct bank, and the next CHK?RP may not select the correct bank.
PBP overcomes that with the L?GOTO, L?CALL and LABEL?L macro's, which I won't go into here, but you can probably guess that I'm leaning towards you using banksel. It's really much easier.
Just make sure you put it back to bank0 when you're done.
banksel 0
HTH,
P.S. Unless you are using other PBP macro's like MOVE?BB, BIT?GOTO etc. in which case it's best to use CHK?RP.
Where's that bailout when you need one?