RAM Memory locations

[bwhiten]

The compiler says I am running out of contiguous RAM space to store LCD data in a 16F887. I have relocated the array to 0x300 and it compiles and when I look at the .sym file it "appears" this is in RAM space, not ROM. Cool! But I can't prove it is RAM by looking at the Microchip datasheet. Can someone describe to me how to determine the RAM locations in the memory maps of the datasheet?

[PCM programmer]

Every PIC data sheet has a chart that shows the register addresses and
the blocks of general purpose RAM. Look in the 16F887 data sheet,
in this section:

[bwhiten]

I definitely looked at this figure but it made little sense in terms of direct versus indirect addressing. This is the statement I have in the program:

[PCM programmer]

#locate only works with RAM. You can't use it to put data in ROM.
Use 'const' to put data in ROM. See the links in this thread for examples:
http://www.ccsinfo.com/forum/viewtopic.php?t=32666&highlight=struct+const

[bwhiten]

Sorry to be unclear. This was done to find more room in RAM. It appears to be locating this structure in RAM at 0x300, just like I wanted, but I can't determine why 0x300 is a legal RAM address from looking at the datasheet. Paranoid I guess.
Can you tell by looking at what I show above that 0x300 is a legal RAM address and if so how do I translate that back to the addresses I see in Figure 2-6?
Thanks again for struggling with my issues.

[Ttelmah]

I'm afraid all you have done, is find a shortcoming in the memory testing.
Figure 2-6. Your chip, has a total of 368 bytes of RAM, organised as 96bytes at 0x20 to 0x7F, then 80bytes at 0xA0, to 0xEF, then 96bytes from 0x110, to 0x16F, and finally 96 bytes from 0x190, to 0x1EF.
0x300, is not a legitimate location for the chip.
If you try to #locate the variable anywhere inside the legitimate memory, the compiler will tell you it has not got enough contiguous locations, for the array, since it is bigger than any of the available blocks (array needs 128 consecutive locations). However, some of the chips in the same family, support you adding external memory, so the #locate, accepts that _you_ know what you are doing when you give it a location, and will allow you to put the array at 0x300. Unfortunately, you don't have any memory there...

Best Wishes

[bwhiten]

Obviously my code didn't run. I did make some progress however, by splitting the array in to two and #locate-ing one at 0x110 and one at 0x190. This allowed the design to fit where as without these locates the RAM never fit.

[Ttemah]

Normally, the compiler will do this OK, with the following comments:
1) You must split the array (since the largest contiguous piece of memory is not large enough for the 128 element entry.
2) You must have #device *=16. Otherwise the compiler will only access the first bank.
3) Though on 'speed' grounds, it is better to declare much used variables first, you may well find that the compiler will fit the two arrays in OK, if you declare them first. It finds it easier to fit the 'big lumps', and then fit the smaller stuff 'round' these.

#locating as you have done, is a good choice if you have just a couple of large elements like this.

Best Wishes

[bwhiten]

The reason I started down this path was that I was not satisfied with the speed of the LCD updates using the "slow" version of the GLCD text generating code. I was using the slow version because the 16F887 does not have enough RAM to utilize the FAST_GLCD code as written. I worked around this now by modifying the code to store and fast write a single "text line" of the LCD at a time. This fits in the available RAM and reduces the display-a-line-of-text function from a sequence of writing the LCD memory 2048 times with an overhead of 2048 reads and 2048 writes, to reading RAM 128 times and writing the LCD memory 128 times with an overhead of 4 writes. Do this across all 8 lines and the LCD updates quite a bit faster!