RAM Usage & Symbol Table

Barney · Joined: 18 Oct 2004 Posts: 41 Location: Newark, CA

I am trying to understand how the CCS complier assigns RAM, in particular for the 16F87/88. I am looking for general info as well as specific info:

General Info:
1. Any magic decoder rings for the .SYM file? I started looking at it and it *seems" self explanitory, but I would appreciate a guided tour if available.

2. When I get an out of RAM error message, is there anyway to find out what is specifically causing the problem? Right now I just blindly change #locate and #reserve and make arrays smaller until the error message goes away. I would like to understand and fix the problems rather than paper over them.

3. If I #reserve space for variables, how does this impact the complier's automatic assignment of variables? (Other than the obvious point that the complier can't use that reserved space for anything else)

Specific Questions:
1. In the 16F87/88 the last 16 bytes of banks 1,2,and 3 are mapped into bank 0. That is accessing address 0xF0 or 0x170 or 0x1F0 actually accesses 0x70. Is the complier aware of this, or do I need to #reserve these locations? There is nothing in the .h or .lst file to indicate one way or the other.

2. The symbol table appears to have 2 sections, the first section appears to be data and the addresses are restricted to the register file map. The second section appears to be procedure names or constants and I am guessing it is program memory addresses?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

DragonPIC · Joined: 11 Nov 2003 Posts: 118

I have notice, at least with the SX version, that if I changed the order that some of the variables are initialized I would save program space. This is because the program does not have to change banks anymore to access 1 variable to the next since they are then in the same bank.

I am not sure if this will help with your arrays though. I believe the compiler likes to keep a whole array in one bank. So if you are one space short in a bank to fit the array, it will jump to the next bank. I don't believe it knows how to organize it so that it works. To do so may eat up more of your program memory instead.

Suggestion would be to try not to use too many global variables if possible.
_________________
-Matt

Barney · Joined: 18 Oct 2004 Posts: 41 Location: Newark, CA

Using *=16 sure makes a different in the RAM available on the 16F88:

*=8 --> ROM = 14% RAM=94%-95%
*=16 -> ROM = 16% RAM=45%-46%

Evidently I can't address the general pupose registers above 0xFF. Does this cause a problem for the complier to get to the hardware registers in the upper banks? For example WDTCON at address 0x105 in bank 2?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

No, you're thinking that it's a hardware issue, but it's not.

It's a compiler option. With *=16, the RAM at addresses 0x100 and
above becomes available for use. In order to use it, the compiler
must generate ASM code to switch to the upper RAM banks. Doing
so uses up additional ROM locations. Some users might have programs
that use little RAM, but a lot of ROM. By not enabling *=16, they
keep their RAM usage in the lower banks, and avoid the extra bank
selection instructions, and thus have more ROM available for their
application program.

Barney · Joined: 18 Oct 2004 Posts: 41 Location: Newark, CA

OK I got that part. My question concerns the difference between my C code and the compiler's built in routines. Even if I set *=8, I presume that the compiler will add the bank switching ASM statements in its internal routines. So while *=8 restricts my C code to registers below 0x100, the compiler's internal statements are not restricted.