How to reduce ROM space ??

[arun]

Hi,

I have developed a large program (it works very well ) for use on PIC 16F877 , the ROM size occupied is around 75% and the RAM is 59%.

Is this too much or should I re-structure my program so that it occupies less ROM space. ???

Some tips would be very helpful.

thanks
arun

[Mark]

It fits doesn't it???

[Ttelmah]

[rnielsen]

I had a project, once, that ran just fine (I needed to tweek it a bit to get the whole code to fit) but if I added two int8 variables I ran out of space. If it runs, don't worry about it.

Ronald

[Mark]

I have some that is so packed that just declaring one variable before the other causes out of ROM. It is due to then bank switching.

[Trampas]

I have a simple set of rules I follow when developing code and products:

1) Define your own data types, this will save you hours when you have to port your code.

2) Try not to use intrisic functions like, CCS's bit_test. If you do then define them as macros like #define BIT_TEST(x) bit_test(x). Also always used the #case in CCS. This way if you port code to anothe chip or compiler you can easily change the bit_test implementation.

3) Try to organize your code into modules, like a file for the flash chip, etc. This way if you reuse the chip or need module for another project it is easy to port.

4) Never optimize code when writting first time. Write all code in the simpliest easiest way for people to read and understand. If you need to optimize then comment out unoptimized code and write a new optimized version. Do not optimize until absoultly needed! Like when you run out of ROM and not before.

5) When starting code figure out your error reporting system first! For example will errors be logged to flash or out serial port, etc.

6) Put code in to check for vaild inputs and outputs for all functions. What I like to do is but a #define to enable this error checking. For example:

[bdavis]

I agree with what Trampas posted. The reason for using 'C' is to reduce development time, decrease bugs, to decrease debug time, and increase portability. I know what you mean when you want to look for optimizations at 75% full for ROM. My comfort range is 50% usage for future maintenance and new features, but of course that depends on the project and if you plan on doing field upgrades for a year or more.

The biggest things I could see were:

- Use bits for everything you can - (single cycle, single instruction, and efficient use of ram).

- I use asm to toggle a bit - CCS added a function for it, but I haven't looked at a listing to see if is a single instruction. If you use "byte & (~mask)), then it is ten times the code and ten times slower on the pic. The 18Fxxx has a BTG instruction, which is nice.

- Use pointers instead of arrays for data in ram. I declare the data as an array, then use pointers in the code to access the data. This saved more code space than any other simple optimization, and is portable. Look at your listing file and you can see about a 50% savings in ROM usage for these lines of code. I did hear that earlier compiler versions may have problems using too many pointers - ie: "*c = *b;"

- From all listings and experimentation, CCS doesn't fully optimize pointers and such using the 18Fxxx registers yet (in version 3.202). I wouldn't recommend it unless you are actually running out of code space, but you can see huge savings in code space optimizing the indirect registers in assembler - this was about 16x smaller than using arrays and about 8-10x smaller than using pointers. The 18Fxxx has the ability to clear or copy and increment in a single instruction for indirect (pointer) registers. The compiler seems to only use this for each line of 'c' code, but not consecutive lines. The 16x in improvement was seen in initializing an array at runtime.

-Any assembler is implemented as a macro, and should have a very good reason for using it (speed, code space, precicise behavior, etc).

- Highly recommend looking at the listing file- I have found compiler bugs before even running the code doing this. I will give you a better understanding of what the compiler is doing. I'm still learning everything about CCS, but so far, I'm happy, and hope the above helps...

[Trampas]

I know for real compilers, like Microsoft's compiler they recommend you do not use pointers for indexing into arrays. Which seems funny at the first, but the reason is optimizations.

That is the high end compilers are often smarter about the hardware the code runs on than the programmer. For example: