Printable View
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.
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.
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):
variable blabla = 0Code:
' ------[ 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 ]====---------------------------------
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.
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.
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 ;)
No, PBP will use CLRF when zeroing a variable.Quote:
Originally Posted by Art
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.
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 :)
Yes, var = var + 1 turns into an incf.
Here's a small program ...After compiling, a quick look in the .LST file reveals all.Code:B VAR BYTE
W VAR WORD
B = 0
W = 0
B = B + 1
W = W + 1
Code: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
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.
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. :eek:
In his defense, ... it was 2002. I had some strange ideas about PBP back then too.
Haha, It was likely intended to apply to 1-2K pics!
Um, all hell did break loose. The ISR routine was the problem BTW.
Maybe I need to post some code to claim that title.Quote:
It's probably the worst examples of PBP programming found anywhere on the internet.