Out of ROM, A segment or the program is too large

[kgng97ccs]

I am using the PIC18LF46K22 MCU, MPLAB IDE v8.92, and CCS C compiler v5.115.

I am referencing this helpful reply from Ttelmah regarding optimizing code (https://ccsinfo.com/forum/viewtopic.php?t=59937; that post is locked):

[Ttelmah]

No, opt compress will tend to combine things rather than separate them.
It is trying to make the total code size as small as possible.

However what you show suggests you are actually running out of total
size, not space in one segment. Splitting things up will actually make this
worse rather than better....

Segments as a problem are more a PIC16 problem, rather than PIC18.
If you look your whole available code space is the first segment.

You have simply run out of space. Second part of the message
'or the program is too large'.....

[temtronic]

WOW, ran out of ROM in a 46K22 !!!
I'm thinking you have HUGE 'data tables' in your program ??
If so, perhaps you could store that data(say it was a 'font table' ) in an external EEPROM ?

Any 'finished' program shouldn't use more than 90% of ROM, as we all know 'other code' HAS to be added a few days later.....

Just trying to think of options.

[kgng97ccs]

Thank you, Ttelmah and Temtronic.

My code can now compile, but with 99% ROM usage (I removed a function that is not called):
Memory usage: ROM=99% RAM=61% - 67%

I am still looking into how to reduce the ROM usage.

My code has many fprintf statements that print both text and variables to a software UART (and ultimately to the computer screen, for the user to see). When I commented out one group of fprintf statements in a function, the ROM usage reduced to 95%!

I will now try to shorten the text in all fprintf statements. Most static data and parameters are already stored in the built-in EEPROM. The PCB does not have any external EEPROM.

I will appreciate any other ideas you or any other contributors may have that can reduce ROM usage.

[temtronic]

One possible solution...all depends on how the compiler works....

If all the 'fprints to PC screen' changed into calling a common function, that should ( may ?) reduce space.
Say you need to send 1-10 variables to the PC screen, have ONE function that sends ALL of them,even if some are not needed

I'm thinking each current 'printf to PC screen' code would be changed to a short 'call to 'printtoPCscreen' function instead of several lines of code.

Hopefully you can code a test of my idea,see if it does work or not.

Others may reply already knowing if this will work...at least it sounds good in my head.....

[Ttelmah]

Several things.

The first is duplication. Any code that could be split off to be a subroutine?.
That includes as Jay says things like printouts etc.. Also things like messages.
If these are used in more than one place, then store as a constant value
instead of having these stored twice.
Then look at things that could be more efficient. So for example, arrays
are less efficient to access than separate variables. Large switch statements
etc. etc..
Jay also alludes to data. Remember if you initialise a variable, this involves
a ROM copy of the values being stored. Could these values come from
somewhere else like an external EEPROM instead?.
Then really if the code is this large, would it be better to look at a DsPIC?.

[temtronic]

re: Then really if the code is this large, would it be better to look at a DsPIC?.

No, he needs a SMALLER PIC !

Being told you have to use a smaller device and you're forced into becoming 'creative' on how to code and use BITS instead of having 'unlimited' WORDS to use.

As Mr. T points out several ways you can reduce ROM requirements.

I was thinking about this the other day while looking at BASIC code I'd cut in 1977. Had to 'pack' data into 256 byte sectors (85 x 3 was efficient ! ). Another chunk of 'fun' code was encoding 24hrs into a byte,well 7 bits. Each bit represented 15 minutes, and the 8th bit was a 'flag'.
Since memory got huge in size and cheap to buy, programmers don't have 'fun' anymore.. doing more with less.

[Ttelmah]

Good point.
It is easy to write code very inefficiently, and modern programming is
more and more going that way. Using smaller variables also saves size
in the routines to handle them. Multiplying or adding two 8bit values
uses perhaps 1/10th the space of doing the same with 16bit values,
Going with float again perhaps 10* more space.
Using a bit of thought and scaling values to fit into integer types save
both ROM and RAM.

[newguy]

[kgng97ccs]

Thank you, everyone, for your ideas.

So far, by shortening the text in fprintf statements by using abbreviations for some words, I have managed to get the ROM usage down to 97% (not much, but at least the full code compiles). I am still looking into other options.

From Newguy:

[newguy]

Instead of using (for example)

[Ttelmah]

and remember you must have #device PASS_STRINGS=IN_RAM to use
constant strings passed like this.

[kgng97ccs]

Thank you, Newguy and Ttelmah. Yes, the example helps.

1. If I am passing a string constant declared in an array, I will not need to use the directive “#device PASS_STRINGS=IN_RAM”. Is this correct?
Example:

[Ttelmah]

Pass strings is useful in a lot of places and costs very little in code size.
Passing as a RAM string will work, but will cost (in this case) 18bytes of RAM.
Add this up for all the strings, and you'll probably run out....

[kgng97ccs]

I have managed to get the ROM usage down to 95% (from 100%) by doing the following (I have “opt compress” in my code).
1. Abbreviating some text in fprintf() statements.
2. Consolidating sequential fprinf() statements into one fprintf() statement.
3. Using a wrapper function to wrap the built-in read_eeprom() function and doing the same for the write_eeprom() function. I gathered from the CCS forum that this can help to prevent the compiler from making these built-in functions inline. I placed “#separate” before the function prototype of each of these wrapper functions, but found that it actually does not affect the ROM usage (as shown in the .STA file).

I am still looking into how best to use one or more subroutines to do the fprintf(). This will need more planning, as my fprintf() statements are varied and scattered across many functions.