News:

Let's find out together what makes a PIC Tick!

Main Menu

System variables included in total RAM used?

Started by trastikata, Jul 15, 2021, 12:02 PM

Previous topic - Next topic

trastikata

As title suggest I was wondering if the system variables are being reported in the total RAM used statistics?

My question is due to the fact that the compiler shows "1011 variable bytes used from a possible 1024" and when I Dimension another byte get the "Not enough RAM" message?

Thanks

top204

Device?

It is probably an enhanced 14-bit core device. These have a section of RAM at the top of RAM bank 0 that the compiler does not use. From address 0x70 to 0x7F, but it still counts them, and the amount of RAM is taken from the official info from Microchip.

The RAM at 0x70 is shared among the RAM banks, and can come in useful for your own programs. The variables will need creating at the bankless RAM area.

trastikata

#2
Quote from: top204 on Jul 15, 2021, 08:46 PMDevice?
It is probably an enhanced 14-bit core device....

Hi Les,

It is actually the 18F2553.  With 1011 variables the program compiles, adding a dummy byte after that causes the "Not Enough RAM"

- I thought it is something related to using the USB module, but after removing all USB-related code and include files, and adding an array of dummy bytes - the problem persists - at 1011 bytes used RAM I get the error.
- I also found that removing all the code and leaving only one Label with no code again allows me to Dimension the memory to only 1011 bytes.
- When I removed all arrays and declared a list of individual bytes, I was able to go up to 1023 out of 1024

2553.jpg

top204

#3
For normal use, I would not recommend the devices with the on-board USB tranceiver, because Microchip really did not think how they actually work in "real-life" when they were designed.

Because the device has parts of its RAM designated to USB only, the compiler automatically assigns parts of it for USB use, so it is invisible to the user when implementing the USB commands or libraries.

The PIC18F2553 actually has 2048 bytes of RAM, but the dual port "USB" RAM is, stupidly, placed in the middle of RAM, not at the end of RAM, so the compiler has to take this into account and not allow user variables to go above address 0x0400 (1024) because this is the USB buffer area, and it also has to designate other parts of RAM for USB use only, and does not count them (which I will change for the amount of RAM available). So it only allows standard RAM use up to the dual port RAM area.

If you are not using USB, add the declare:

Declare Onboard_USB = Off

And the compiler will remove all of its built-in RAM designations and give you the full 2048 bytes of RAM to use. I think this declare needs to be added to the manual in its next update.

trastikata

Quote from: top204 on Jul 16, 2021, 10:24 AMFor normal use, I would not recommend the devices with the on-board USB tranceiver, because Microchip really did not think how they actually work in "real-life" when they were designed.

I'm actually using the USB transceiver, I removed the USB related code to make sure it is not causing the anomaly with the missing 12 bytes of RAM.

As I mentioned earlier, it seems to be an Array related problem, because when I'd removed the arrays and declared individual bytes I could declare all 1023 variables. When using arrays - the compiler gives an error if more than 1011 bytes of RAM are used.

So I assumed maybe some system variables, pertaining to arrays are not included in the statistics?

Quote from: top204 on Jul 16, 2021, 10:24 AMIf you are not using USB, add the declare:

Declare Onboard_USB = Off

And the compiler will remove all of its built-in RAM designations and give you the full 2048 bytes of RAM to use. I think this declare needs to be added to the manual in its next update.

This is great, thank you for that option. Can I assume it would be applicable to all other dual-port RAM USB capable PICs?

top204

#5
Also remember, RAM on the 8-bit microcontrollers is not linear, it is banked. So even a single byte variable added can move other variables over RAM banks, which means the compiler may have to use extra system variables for user variables that are now crossing RAM banks etc...

Because of the non-linearity of the RAM, it cannot be guaranteed to increase by only 1 if a single byte variable is added, it may increase by more because the compiler may need to use more resources, especially on programs that are using lots of the RAM, because it is "guaranteed" some will be crossing RAM banks.

I make it invisible to the user, the extra assembler code complexities involved within expressions and comparisons when the individual pieces of a multi-byte variable, or different variables, are in seperate RAM banks, but it can increase RAM usage, and definately increases code memory usage. It is just the silliness of the banked RAM system on PIC 8-bit devices that should have been eliminated from them years ago.