16F877 RAM Question

[Melanie]

PBP uses the same couple or three dozen variables over and again for it's routines. They are reused. Those variables aren't created again if you use the routine in several places. In an 16F877, with 370 bytes, you should have at least 330 bytes of RAM that you can assign for your own use. This all depends on your code, but you have to be doing some pretty drastic things, or have some huge arrays assigned to use up that much resource.

Btw... PBP doesn't swap RAM into codespace. RAM is RAM, and codespace is codespace, the two aren't mixed unless YOU deliberately do it in your program.

[Art]

Hmm

ADR var word : dat var byte : EEunit var byte		'define I²C address, data & unit variables
delay var byte						'define delay time variable
T1 var byte : T2 var byte : T3 var byte			'define real time buffers
T4 var byte : T5 var byte : T6 var byte			'
A1 var byte : A2 var byte : A3 var byte			'define alarm time variables
A4 var byte : AA var bit  : AL var bit			'define alarm condition variable bits
D1 var byte : D2 var byte : DB var byte			'define display digit buffers
D3 var byte : D4 var byte				'
D5 var byte : D6 var byte				'
B0 var byte						'define GPS data bytes
B2 var byte : B3 var byte				'
B4 var byte : B5 var byte				'
B6 var byte : B7 var byte				'
DP var bit 						'define decimal point status bit
JS var bit						'define joystick status variable
DC var byte						'define display comparison variable
RC var byte						'define real time clock comparison variable
mode var byte						'define mode variable byte
colcnt var byte						'define colon delay counter variable byte
sndbuff var byte					'define sound buffer value variable byte
soundcalc var byte : snd var byte			'define sound calc variable byte
L0 var byte : L1 var byte : L2 var byte			'define variables for Lat & Longitudinal coordinates
L3 var byte : L4 var byte : L5 var byte			'
L6 var byte : L7 var byte : L8 var byte			'
L9 var byte : LA var byte : LB var byte			'
LC var byte : LD var byte : LE var byte			'
LF var byte : LG var byte : N1 var byte			'
LNG var byte : LAT var byte 				'
last var DB.bit7 : first var DB.bit0			'define display buffer first & last bits for swapping
msel var bit : ply var bit				'define mode display / play and pause status bits
LTA var byte : LTD var byte				'define lookup table value & data bytes
'
roll var byte : Rcnt var byte				'define display animation control variables
roll1 var roll.bit0 : roll2 var roll.bit1		'
roll3 var roll.bit2 : roll4 var roll.bit3		'
roll5 var roll.bit4 : roll6 var roll.bit5		'
rollo var byte						'
rollo1 var rollo.bit0 : rollo2 var rollo.bit1		'
rollo3 var rollo.bit2 : rollo4 var rollo.bit3		'
rollo5 var rollo.bit4 : rollo6 var rollo.bit5		'
rolls var byte						'
rolls1 var rolls.bit0 : rolls2 var rolls.bit1		'
rolls3 var rolls.bit2 : rolls4 var rolls.bit3		'
rolls5 var rolls.bit4 : rolls6 var rolls.bit5		'
F1 var byte : F2 var byte : F3 var byte			'
F4 var byte : F5 var byte : F6 var byte			'
'
SM var bit						'define search match status bit

as you can see, there aren't a lot of variables.
I think that the library variables are being added to total the 96 bytes
in the first bank of RAM and then the compiler is clapping out there.
If I add just a few more byte size variables and set them to any value
to make sure they are used, my program will no longer start

If I remember correctly from my 16F84 days, PBP uses some variables
to pass values from the user's PBP routines to it's own library routines.
with a bit of assembler hacking I have managed to claim some of these
"middle man" variables in the past.
Art.

[Art]

I have made an interesting discovery.
My program only contains two lines that change the bank select bit RP1.
This means that my PBP program can only be accessing the first two RAM banks which is only a little more than half that the chip provides.

It seems I will have to change the RP1 bit manualy in assembler to use the rest of the RAM. Surely I'm not the only one who has encountered this?



... well it seems I answered my own question.
A little later I have found out that some of the exixting asm in my PBP code
that addresses RAM does so incorrectly when PBP changes the location of
that RAm without my asm code knowing about it.
So a little thing like:
@ incfsz _colcnt,f
@ goto _decpnt
can cause the whole program to break when the variable 'colcnt' requires
a change tot he bank select bits in order to address it. or at least that's what
I think is happening at the moment...

Anyway I have solved my original problem

[Melanie]

No, something's not right.

I've used PBP with 16F876 extensively, which is the smaller I/O brother of the 877 without problem. I've maxed out the RAM and the Program Codespace and know PBP works to the limit of the PIC with versions 2.44, 2.45 and 2.46.

Now if you are embedding Assembler which is going to Bank Switch or do anything other than rudimentary functions or access Registers that PBP isn't, then you must save the current environment on entry and restore it on exit. Otherwise you will not leave the PIC in the state PBP expects it to be.

What version of PBP are you using?

[Art]

I think maybe I didn't explain myself too well.
At this stage I am able to use all of the chip's RAM with a pure PBP program.

I think the reason why my code originaly stuffed up when I used more than a
certain amount of RAM is that I had asm routines that accessed RAM without
any bank switching.
Therefore, the addition of more RAM to my program might have allocated
existing variables to areas of RAM that would require bank switching by my
asm code when addressing them.

I hope that makes better sense.. everything is working now I have gone back
to pure basic. At some stage I like to convert it to all asm for optimising, but
best wait until it's close to finished.
Art.