News:

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

Main Menu

is it possible? (program size over)

Started by Maxi, Aug 15, 2022, 06:48 AM

Previous topic - Next topic

Maxi

When we compile a program if program size over the pic capacitiy
proton+ tell us "this code not fit this device ....."

ok but is it possible how big?
example: this program is %124 over the capacity etc

Yves

Each chip have a limited capacity. Sometimes you can tweak the code to reduce for example saving strings in EEprom if they are repetitive. I'm sure there people in the forum that knows all the tricks to shrink codes.

Regards,

Yves 
Yves

John Drew

Maxi, this question came up in the old forum.
The simple answer is "no".
As workarounds and to give a rough answer I've commented out sections until I could get a compile. This gave an idea of how much I had to reduce things.
The other was to change the name of the PIC to one in the same family with more memory and try a compile. If it did a note of the compiled size versus the available memory of your chosen device gave an indication.
You can't change families though due to compile sizes being dependent on the family.
John

top204

#3
"Proton+"?? The compiler has not been named that for about 17 years now. :-)

John is correct. It is not possible to give a percentage of how much over the limit for code memory the program is.

The compiler reads how much flash memory has been used, from the files created by the assembler when all of the tweaks and optimisations the compiler does have been assembled. It is not as simple as counting the mnemonics used while compiling, because they are tweaked and optimised and optimised and optimised, then assembled, and tweaked and optimised again by the contents of the ".lst" file produced by the assembler on its first pass, so some mnemonics are removed or added after compilation, and by the optimiser programs. If the optimiser is disabled, the ".lst" file is still used to count the last code memory address, but the compiler tweaks as it goes along, often called "peephole optimisation". The final code memory usage is based upon the directive "__eof" that the compiler places at the end of the assembler listing, so it reads the code memory address beside it.

So it is only the assembler that knows the final size, and it is the assembler that gives the very obscure error message when the code memory has gone over the limit of the device. The compiler recognises the obscure error message created by the assembler and interprets it to a more understandable error message. However, because the assembler does not assemble the program, it does not create a ".lst" file or a ".map" file, so there is no way of knowing how much over the limit the code memory is! And the obscure error message produced by the assembler has no details, whatsoever, about sizes. In fact, the assembler error has nothing to state about not enough code memory. It is so obscure!!!

The compiler produces its ".pbe" file that has the amount of RAM and code memory used, and all the IDEs give the code sizes and the RAM usage on their bottom window, so it is up to the user to check when limits are drawing nearer. The compiler gives meaningful error messages for RAM usage, because the compiler knows all the variables it is creating and what each variable is, so that is very different.