Program fails crossing code page

[Art]

Hi Guys,
Is there any obvious reason why my PBP program
Does not work when it becomes large enough to
Extend to the third code page (16f877a) ?

No vars are accessed in asm other than in the ISR.

I can finish it in the current code space, but it would be nice to use it.
The program is working as expected until just one
Instruction crosses the third code page.
Cheers, Art.

[Darrel Taylor]

Are you using the BRANCH statement in your program?
If so, use BRANCHL instead.

If not, what does the ISR look like.

PBP should have no problem using all pages.

[Art]

No Branch statements, in fact I don't remember ever using it.

ISR looks like this (should look very familiar to you, except I handled RB0 interrupt myself):

' ------[ This is the Interrupt Handler ]---------------------------------------
ClockCount:   ' Note: this is being handled as an ASM interrupt
@ INT_START                    
'
  R0save = R0                     ; Save 2 PBP system vars that are used during
  R1save = R1                     ; the interrupt
'
IF INTCON.1 = 1 THEN        'handle portb.0 interrupt
INTCON.1 = 0            'clear portb.0 interrupt flag
@ incf _extint,f        'increment external interrupt counter
goto overextint            'skip over timer interrupt handler
ENDIF                '
'
'
@ RELOAD_TIMER                    ; Reload TIMER1
@ incf _Ticks,f
    if Ticks = 100 then
@ clrf _Ticks
@ incf _Seconds,f
       SecondsChanged = 1
       if Seconds = 60 then
@ clrf _Seconds
@ incf _Minutes,f
       endif
       if Minutes = 60 then
@ clrf _Minutes
@ incf _Hours,f
       endif
       if Hours = 100 then
@ clrf _Hours
       endif
    endif
'
overextint:
'
  R1 = R1save                     ; Restore the PBP system vars
  R0 = R0save
@ INT_RETURN                      ; Restore context and return from interrupt

'-----====[ END OF TMR1 Interrupt Handler ]====---------------------------------

variable blabla = 0
was asmed to clrf statements because the last time I checked,
PBP zeros variables by copying a zero value to the variable like any other value,
wasting one instruction per "variable = 0" statement.

Shouldn't thew ISR always be at 0x04 vector? shouldn't be a problem accessing PBP vars in asm there.

[HenrikOlsson]

Hi Art,
Darrel is likely going to help you figure out the problem here is but I don't think the ISR is actually placed at locatoin 0x04. What's placed at that location is a GOTO to the adress where the ISR is actually located. So, if you're accessing variables from the ISR and doing so with ASM I think you need to take care of the bank/pages thing.

/Henrik.

[Art]

Wow, I'd be suprised if it was over the first page when it almost always needs to be accessed fast.
Currently, only LCD_Anypin is included before the include for the elapsed timer.

Easy to test though, there's nothing there that cannot be PBP.
I suppose I can give up 9 instructions of code space to gain half of the chip of useable code space

[Darrel Taylor]

variable blabla = 0
was asmed to clrf statements because the last time I checked,
PBP zeros variables by copying a zero value to the variable like any other value,
wasting one instruction per "variable = 0" statement.

No, PBP will use CLRF when zeroing a variable.

That ISR is from the original Elapsed Timer Demo, in which I had declared the variables without bank assignments, letting PBP assign the banks as needed.

By changing Seconds = Seconds + 1 to incf _Seconds,F, you have bypassed PBP's banking mechanism and it's likely you are overwriting other variables in RAM.
The few bytes that were gained, were probably the instructions changing banks.

If you declare the variables as BANK0 it would be ok.
Or if you put them back to PBP statements it will be ok.

[Art]

Nice to hear! Given I haven't tried it yet.
Does var = var + 1 translate to an incf instruction?
Maybe that is what I'm trying to remember...
It was years ago, I disassembled a PBP program
With the tool in ICprog for 16F84.

Great news anyway if I don't have to drop anything fancy
To gain space. Thanks

[Darrel Taylor]

Yes, var = var + 1 turns into an incf.

Here's a small program ...

B   VAR BYTE
W   VAR WORD

B = 0
W = 0

B = B + 1
W = W + 1

After compiling, a quick look in the .LST file reveals all.

                      00107 ; C:\PIC\ART\ASMVSPBP.PBP       00014   B = 0
                      00108         MOVE?CB 000h, _B
  00000000                M PREV_BANK = 0
0001   01BA               M         clrf    _B
                      00109 
                      00110 ; C:\PIC\ART\ASMVSPBP.PBP       00015   W = 0
                      00111         MOVE?CW 000h, _W
  00000000                M PREV_BANK = 0
0002   01B8               M         clrf    _W
  00000000                M PREV_BANK = 0
0003   01B9               M         clrf    (_W) + 1
                      00112 
                      00113 ; C:\PIC\ART\ASMVSPBP.PBP       00017   B = B + 1
                      00114         ADD?BCB _B, 001h, _B
  00000000                M PREV_BANK = 0
0004   0ABA               M         incf    _B,   F
                      00115 
                      00116 ; C:\PIC\ART\ASMVSPBP.PBP       00018   W = W + 1
                      00117         ADD?WCW _W, 001h, _W
  00000000                M PREV_BANK = 0
0005   0AB8               M         incf    _W,   F
0006   1903               M         btfsc   STATUS, Z
0007   0AB9               M         incf    (_W)   + 1, F

[Art]

Ah, nice to know. It looks like there was a time when this wasn't the case:
http://www.rcfaq.com/PIC/optimize.htm
Although incrementing a variable shouldn't have ever used three words unless a clrwdt was thrown in as well.

[Darrel Taylor]

That page has been pointed to several times around here.
It's probably the worst examples of PBP programming found anywhere on the internet.

Sure, the programs are smaller when you use some of those techniques.
But the savings come from bypassing the normal bank switching and page bit setting that PBP does to insure everything keeps working properly.

The examples are fine by themselves because they are never larger than 2K and variables are never outide of bank0.
But when you try to use them in your program that is bigger with more variables, all hell breaks loose.

There are a couple true statements on the page, but with so much bad advice, it's hard to find them?

My advice is to delete that bookmark from your favorites, and forget what you read.

In his defense, ... it was 2002. I had some strange ideas about PBP back then too.

[Art]

Haha, It was likely intended to apply to 1-2K pics!

Um, all hell did break loose. The ISR routine was the problem BTW.

It's probably the worst examples of PBP programming found anywhere on the internet.

Maybe I need to post some code to claim that title.