 |
 |
| View previous topic :: View next topic |
| Author |
Message |
RossJ
Joined: 25 Aug 2004
Posts: 66
|
| Out of RAM if too FEW bytes are #reserved !!! |
 Posted: Wed Aug 25, 2004 3:43 am |
 |
|
I have written a bootloader (for a 16F876A) in assembler which uses 19 bytes of bank 0 and all of bank 2. In my C application, I have used #reserve to prevent the compiler from using this RAM as follows:
#reserve 0x020 : 0x030
#reserve 0x070 : 0x071
#reserve 0x110 : 0x16F
When I compile, I receive the 'Not enough RAM for all variables' error message. If I change the middle range to '0x70 : 0x76' (or say '0x68 : 0x71') it compiles fine. Why does the compiler fail to allocate RAM when there is more of it available? I have to reduce the available RAM before the compiler can allocate all variables to it!!!
Appart from the ranges mentioned above, there are no large arrays or such in the C program (nothing bigger than 6 bytes). Also, there are about 20 bytes of unallocated RAM at the top of bank 1 (below the 0xF0 common area). I am not using 16 bit pointers, so I don't expect the compiler to use bank 3 without me telling it to.
Has anyone seen this before? Is this likely to be a bug in the compiler, or am I just doing something stupid? I am using the latest PCW 3.207, but it was the same in 3.200. |
|
 |
Gerrit
Joined: 15 Sep 2003
Posts: 58
|
|
| Posted: Wed Aug 25, 2004 3:49 am |
|
|
Why are you preventing that the ram is being used ?
After the boorloader is finisched all the ram could be availible
for the program again.
Regards,
Gerrit |
|
|
RossJ
Joined: 25 Aug 2004
Posts: 66
|
|
| Posted: Wed Aug 25, 2004 4:15 am |
|
|
The bootloader also has functionality akin to a BIOS (serial, LCD support and a couple of other things). Since I don't have the space to duplicate the functionality, I provide access from the C application to several of the bootloaders functions. Hence the RAM is still required by the boot loader.
Note that this is not really the issue I am raising... |
|
|
Ttelmah
Guest
|
| Re: Out of RAM if too FEW bytes are #reserved !!! |
| Posted: Wed Aug 25, 2004 6:47 am |
|
|
| RossJ wrote: | I have written a bootloader (for a 16F876A) in assembler which uses 19 bytes of bank 0 and all of bank 2. In my C application, I have used #reserve to prevent the compiler from using this RAM as follows:
#reserve 0x020 : 0x030
#reserve 0x070 : 0x071
#reserve 0x110 : 0x16F
When I compile, I receive the 'Not enough RAM for all variables' error message. If I change the middle range to '0x70 : 0x76' (or say '0x68 : 0x71') it compiles fine. Why does the compiler fail to allocate RAM when there is more of it available? I have to reduce the available RAM before the compiler can allocate all variables to it!!!
Appart from the ranges mentioned above, there are no large arrays or such in the C program (nothing bigger than 6 bytes). Also, there are about 20 bytes of unallocated RAM at the top of bank 1 (below the 0xF0 common area). I am not using 16 bit pointers, so I don't expect the compiler to use bank 3 without me telling it to.
Has anyone seen this before? Is this likely to be a bug in the compiler, or am I just doing something stupid? I am using the latest PCW 3.207, but it was the same in 3.200. |
I suspect the poblem may be that the compiler wants a given number of consecutive addresses, for things like the interrupt data store, and the scratch area. It by default places the former at the bottom of the space it has available, and probably checks first for the 'size' it thinks it needs. It'd only take it's expectations to be one byte less than the amount really needed, and this figure to be the amount between address 30, and 70, for it to then find that it can't fit the block into the available space. Presumably reducing the space by one byte (or more), then forces the compiler to instead place this data above 80.
Personally, I'd allways be inclined to keep such declarations as one block, and (say) use 1A0 to 1FF for example, allowing the bank to be changed once when you enter your code, and back when you exit.
I'd also use the device editor, and check that the 70 address, is not in the area set as the C scratch area (it is normally up in this region). Finally, I'd also consider reserving F0:F1 as well, since though the compiler should know this is in the shared area, I'd never 'assume' that it did...
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
