i try to compile a program for 16f54, wen i do is says "Error: Excessive RAM usage!"
however when i try to compile to 16f57 (same ic more pins)
compiler output says it uses " 1.0 Sec. Program Memory: 174/2048 words (8,5%) RAM: 21/72 bytes (29,17%)"
since 16f54 has 25 byttes of memory i should have extra 4 more bytes ?!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bytes take up 1 byte.
Byte Arrays take 1 byte per element plus one byte
Word Arrays take 1 byte per element plus one byte plus 4 bytes for handling (as I remember...)
Strings take 1 byte per character plus one byte
Words take up 2 bytes
Longs take up 4 bytes
Integer take up 4 bytes
If you include any include files then any variables defined in the include may require memory. This additional memory would have to be calculated from reviewing the include file and the methods used from within a specific include file.
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is 19 +12+1=32 bytes far beyond 25 bytes. So only problem i see there is that compiler should report 32 bytes and not 21.
Also good idea should be if compiler inform needed bytez even if not able to compile it so i would be aware that i need the specific ram bytes to select the proprer pic micro.!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I meant 19 bytes within the sonyremote.h for the call to the readIR_Remote method.
A good way to determine memory usage for the user contributed support files is to create the ASM only and this will provide you a good idea of memory usage.
GCB and GCGB provide memory usage for information purposes after the source code has been tokenised, conditional processing completed, logic mapped and variable usage and then passed through the compiler.
It could be useful to change the 'Error: Excessive RAM usage! Delete some variables, reduce the size of arrays, or upgrade to a more powerful chip' to state the number of bytes required. This is added to the list of ideas - thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
first if sonyremote.h need 19 bytes,and since i use no other variables, why 16f54 a 25 byte sram chip does not fit ?!
second, if my program really needs more bytes and since gcb can calculate this correct, since it says "need more ram" somehow it is count somethink.
i believe the mesageshould say you need THAT amount of memory !
since exact mem usage knowledge could provide exct and precision chip selection !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This may be caused by my release level of GCB. As a developer I do have a later version. If I compile your program. I get these results for the 16f54. So, this is probably caused by the release level of your code. What is your release date etc?
2.0 Sec. Program Memory: 88/512 words (17.19%) RAM: 19/25 bytes (76.%)
I have added your idea to the list of changes that we could do in terms of adding an improved user messaging regarding memory usage. Thank you for the idea.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I can compile for me. As I am on the very latest test build. Please note: I am one of the development support team.
We are planning a new release, we did release a test build at the end of last year - we had to resolve a few issues and we still have two more feature to add. Watch the notice on the forum.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
but again it does not compile it !
here are the full error report
with previous version i get an information about memory usage (even if it was false)
now i get no info at all about memory usage !
therefore is a step backward !!
*** makeHEX.bat ***
Great Cow BASIC (0.94 2015-04-02)
Compiling D:\PIC\GCB@Syn\MyProjects\test.gcb ...
Finding source files:
D:\PIC\GCB@Syn\MyProjects\test.gcb: found
D:\PIC\GCB@Syn\GreatCowBasic\include\SonyRemote.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\a-d.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\pwm.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\rs232.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\eeprom.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\sound.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\stdbasic.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\7segment.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\lcd.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\ps2.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\timer.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\system.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\hwspi.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\keypad.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\random.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\string.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\usart.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\i2c.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\hwi2c.h: found
Loading source files ... 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70% 75% 80% 85% 90% 95% 100%
Reading compiler directives ...
Reading chip data ...
D:\PIC\GCB@Syn\GreatCowBasic\chipdata\16F54.dat
Thoughts on getting most out of the available memory. The root cause of the issue is the allocation of the array in the available bank memory. An array of 6 bytes will fit into the free space in one bank, but the array of 7 will not.
GCBASIC currently cannot split an array over banks, so if there are 6 bytes free in one bank and 5 in another, you cannot have an array of 7 bytes. This would be very hard to do efficiently on 12F/16F, there would be a whole series of special function registers in the middle of the array. This not the case on 16F1/18F as linear addressing makes it easy to span banks because the SFRs are not making the problem (as with 12F/16F).
But, a potential work around. You can adapt the .h file to remove the array and change to explicit single byte variables. Then this method may resolve these device specific memory constraints. I cannot promise this idea works but as I write I cannot think why it should not.
Anobium
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Anobium: In this thread you say : "Word Arrays take 1 byte per element plus one byte plus 4 bytes for handling (as I remember...)"
I tought that arrays were only supported for integer. Did I missed something ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
i try to compile a program for 16f54, wen i do is says "Error: Excessive RAM usage!"
however when i try to compile to 16f57 (same ic more pins)
compiler output says it uses " 1.0 Sec. Program Memory: 174/2048 words (8,5%) RAM: 21/72 bytes (29,17%)"
since 16f54 has 25 byttes of memory i should have extra 4 more bytes ?!
Please attach your code. I can have a quick look.
Doesn't GCB use a few bytes of RAM for system variables?
Yea, and, for array management.
i did extensive, since i posted this, test's and seems that only this code is enough
whats the amount of "extra bytes" ? doesn't compiler count it in output log?
if not is there a way to calculate the exact mem needed ?
Last edit: Christos 2015-01-17
There are a number of files and reports produced by the compiler. See the same folder as the source GCB file.
To more explicit.
Bytes take up 1 byte.
Byte Arrays take 1 byte per element plus one byte
Word Arrays take 1 byte per element plus one byte plus 4 bytes for handling (as I remember...)
Strings take 1 byte per character plus one byte
Words take up 2 bytes
Longs take up 4 bytes
Integer take up 4 bytes
If you include any include files then any variables defined in the include may require memory. This additional memory would have to be calculated from reviewing the include file and the methods used from within a specific include file.
Evan
from a quick review of the sonyremote.h file.
This requires 19 bytes. 12+1 bytes for the pulse width array and other variables.
You can save two bytes by not declaring the variables in the main body and using the following to call the method.
This is 19 +12+1=32 bytes far beyond 25 bytes. So only problem i see there is that compiler should report 32 bytes and not 21.
Also good idea should be if compiler inform needed bytez even if not able to compile it so i would be aware that i need the specific ram bytes to select the proprer pic micro.!!!
Sorry, I meant 19 bytes within the sonyremote.h for the call to the readIR_Remote method.
A good way to determine memory usage for the user contributed support files is to create the ASM only and this will provide you a good idea of memory usage.
GCB and GCGB provide memory usage for information purposes after the source code has been tokenised, conditional processing completed, logic mapped and variable usage and then passed through the compiler.
It could be useful to change the 'Error: Excessive RAM usage! Delete some variables, reduce the size of arrays, or upgrade to a more powerful chip' to state the number of bytes required. This is added to the list of ideas - thank you.
hi thanks for the reply
i confused now :)
first if sonyremote.h need 19 bytes,and since i use no other variables, why 16f54 a 25 byte sram chip does not fit ?!
second, if my program really needs more bytes and since gcb can calculate this correct, since it says "need more ram" somehow it is count somethink.
i believe the mesageshould say you need THAT amount of memory !
since exact mem usage knowledge could provide exct and precision chip selection !
This may be caused by my release level of GCB. As a developer I do have a later version. If I compile your program. I get these results for the 16f54. So, this is probably caused by the release level of your code. What is your release date etc?
I have added your idea to the list of changes that we could do in terms of adding an improved user messaging regarding memory usage. Thank you for the idea.
hi
its Version: 0.9 11/5/2014 (its the one at GCB@Syn download yesterday)
so you saying that the program need 19 bytes, and it CAN compile for 16f54 to you ?
Thank you. You have the May 14 release.
Yes, I can compile for me. As I am on the very latest test build. Please note: I am one of the development support team.
We are planning a new release, we did release a test build at the end of last year - we had to resolve a few issues and we still have two more feature to add. Watch the notice on the forum.
hi
download the 31/03/2015 hotrelease
but again it does not compile it !
here are the full error report
with previous version i get an information about memory usage (even if it was false)
now i get no info at all about memory usage !
therefore is a step backward !!
*** makeHEX.bat ***
Great Cow BASIC (0.94 2015-04-02)
Compiling D:\PIC\GCB@Syn\MyProjects\test.gcb ...
Finding source files:
D:\PIC\GCB@Syn\MyProjects\test.gcb: found
D:\PIC\GCB@Syn\GreatCowBasic\include\SonyRemote.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\a-d.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\pwm.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\rs232.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\eeprom.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\sound.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\stdbasic.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\7segment.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\lcd.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\ps2.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\timer.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\system.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\hwspi.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\keypad.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\random.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\string.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\usart.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\i2c.h: found
D:\PIC\GCB@Syn\GreatCowBasic\INCLUDE\LOWLEVEL\hwi2c.h: found
Loading source files ... 5% 10% 15% 20% 25% 30% 35% 40% 45% 50% 55% 60% 65% 70% 75% 80% 85% 90% 95% 100%
Reading compiler directives ...
Reading chip data ...
D:\PIC\GCB@Syn\GreatCowBasic\chipdata\16F54.dat
Chip Settings:
Chip Model: 16F54
Chip Family: PIC (12)
Clock MHz: 4
RAM: 25
Running compiler scripts ...
Building memory map ...
Finding and compiling #IFDEF directives ...
Replacing defines with values ... 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 11% 12% 13% 14% 15% 16% 17% 18% 19% 20% 21% 22% 23% 24% 25% 26% 27% 28% 29% 30% 31% 32% 33% 34% 35% 36% 37% 38% 39% 40% 41% 42% 43% 44% 45% 46% 47% 48% 49% 50% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60% 61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 71% 72% 73% 74% 75% 76% 77% 78% 79% 80% 81% 82% 83% 84% 85% 86% 87% 88% 89% 90% 91% 92% 93% 94% 95% 96% 97% 98% 99% 100%
Compiling subroutines/functions:
Main
READIR_REMOTE
INITSYS
Adding data lookup tables ...
Allocating RAM to variables ...
Tidying Code ...
Locating subroutines in program memory ...
Calculating CONFIG ...
Writing output to D:\PIC\GCB@Syn\MyProjects\test.asm ...
An error has been found:
Error: Excessive RAM usage! Delete some variables, reduce the size of
arrays, or upgrade to a more powerful chip
The message has been logged to the file Errors.txt.
The output file, the HTML, does show the memory usage.
Resolving the memory allocation/reporting is still on the list of jobs to be completed. Sorry.
a,thanx helpfull ! (now it saying 20 bytes out of 25 needed :)
this info whould be posted in popup window after compilation,just like previus versions do imho
i will wait then :)
Last edit: Christos 2015-04-09
Thoughts on getting most out of the available memory. The root cause of the issue is the allocation of the array in the available bank memory. An array of 6 bytes will fit into the free space in one bank, but the array of 7 will not.
GCBASIC currently cannot split an array over banks, so if there are 6 bytes free in one bank and 5 in another, you cannot have an array of 7 bytes. This would be very hard to do efficiently on 12F/16F, there would be a whole series of special function registers in the middle of the array. This not the case on 16F1/18F as linear addressing makes it easy to span banks because the SFRs are not making the problem (as with 12F/16F).
But, a potential work around. You can adapt the .h file to remove the array and change to explicit single byte variables. Then this method may resolve these device specific memory constraints. I cannot promise this idea works but as I write I cannot think why it should not.
Anobium
@Anobium: In this thread you say : "Word Arrays take 1 byte per element plus one byte plus 4 bytes for handling (as I remember...)"
I tought that arrays were only supported for integer. Did I missed something ?