18f452 tables in ram - code?

I've moved up from 16f877 to 18f452 and want/need to take advantage of all that ram in the 18f parts. I d/l and printed all of the data sheet. I know there is some 16 bit pointer registers, but I don't quite know what to do with them.

What are the ways to get to the 16 banks of ram?

I tried changing the BSR bits, but that didn't seem to work. I'm not using any includes so I don't know if that is not defined or what. It compiled without errors.

------
For a little bit more background:

- I'm using 256 variables on a 16f877. I'm have 16 sets of 16 variables. Push one of 16 buttons and see that set of 16 numbers on an LCD.

- I had this working using JAL (thanks Wouter), but was having a hard time wrapping my head around JAL and some of its limitations.

- I moved to PBP. Cool! This stuff rocks! Whipped out some code... smaller, easier to read than JAL, but PBP uses more ram so I could no longer have 256 variables. (Kinda cool though - I would push a button, see a new set of 16 and some of them would be counting. :) Gee, that must be my program loop variables taking the same spot as my data variables. Fun that I could watch my program variables change, BUT NOT WHAT I HAD IN MIND.)

- Getting 256 variable out of a 16f877 that only has 384 bytes of ram is kinda tight.

- Onward to the 18f452. Ah... 16*256 bytes of ram. Now, how do I get at them?

Thanks - Robert

http://www.bitwranglers.com/rshanks/seq_run1.jpg

Hi Robert,

>>Onward to the 18f452. Ah... 16*256 bytes of ram. Now, how do I get at them?

The 18F452 doesn't have 16*256 bytes of RAM. Only 1,536 bytes in 6 banks with 256 bytes per bank.

PBP handles everything for you. Just create your variables, and PBP will assign them all to RAM automatically for you.

You don't need to mess with BSR bits or anything else.

You can create 16 * 16-byte arrays like this.

A VAR BYTE[16]
B VAR BYTE[16]
C VAR BYTE[16]
D VAR BYTE[16]
E VAR BYTE[16]
F VAR BYTE[16]
G VAR BYTE[16]
H VAR BYTE[16]
I VAR BYTE[16]
J VAR BYTE[16]
K VAR BYTE[16]
L VAR BYTE[16]
M VAR BYTE[16]
N VAR BYTE[16]
O VAR BYTE[16]
P VAR BYTE[16]

Of course you can also do it the long way, and create 256 individual variables.

To see how PBP is assigning your variables to RAM, just open the .lst file created at compile time. You'll see something like this for the above arrays.

_B EQU RAM_START + 02BH
_C EQU RAM_START + 03BH
_D EQU RAM_START + 04BH
_E EQU RAM_START + 05BH
_F EQU RAM_START + 06BH
_G EQU RAM_START + 07BH

Etc, etc,,

Thanks, Bruce

Yeah, I was doing some creative math with the 16*256... I knew the data sheet talked about 16 banks... wishful thinking maybe. Actually, 1536 bytes of ram is wonderful.

Thanks for the info on the array of variables. That will work great for right now. I'll probably just use "seqdata VAR BYTE[256]" when I'm using the 18f series.

Although, I would feel better if I knew the address of the array, instead of just letting the compiler put them where it wants. I will be wanting to access the array in an assembly interrupt routine in the future.

It seems like I've seen some bit of code to place a variable at a specific address, (not poke). "counter_a VAR BYTE, $0x300" or something like that. I can't remember where I saw it now, or if it was even PBP. I've been surfing too many code forums lately. :)

Thanks again for your help - Robert

Hi Robert,

You can force PBP to drop variables in specific RAM locations if you prefer.

SEG_DATA VAR BYTE[256] BANK1 : Starts your array in bank 1 at 100H.

Or SEG_DATA VAR BYTE[256] $300 : Starts your array in bank 3 at 300H.

It's all covered in your manual under RAM Usage in the back section.

Try one of the above, compile, then look in the .LST file. You can see where PBP is placing your variables in RAM.

Thanks, Bruce

BOOM! It works like a champ and makes the code more simple.

Doh! It's been six months since I first got PBP and read the manual. Me thinks it's time for a re-read. :)

Later - Robert

Much thanks for yer help - and I'll try not to use the forum as a pre-compiler.

http://www.bitwranglers.com/rshanks/seq_1.jpg