Multiple compilation units, redux

[bcfd36]

I am VERY new to CCS. I have done a search and haven't found the answer I am looking for. And I am at home now, not at work so don't have access to the compiler version or any code examples.

We are running a bit of an older version of the compiler so things don't look exactly like they do in the FAQ section. Note, I do NOT have a "link separately" option in my IDE.

Here is what I want to do...

I want to have 3 (or more) directories, each containing a project. One directory, we will call it COMMON, will contain a file or files with functions/routines that are common to multiple other projects in the other directories. Note I have created this directory/project and compiled the files mod1.c and mod2.c, compiled the project, and created object files mod1.o and mod2.o. Note there are files mod1.h and mod2.h, each included by mod1.c or mod2.c.

In another directory, I have a "main" in control.c (in the control project) that calls routines in mod1.o and mod2.o. It includes mod1.h and mod2.h. I put the directory in the "include" section of the control project. This one WILL NOT COMPILE right now. It is complaining that it cannot find mod1.h and mod2.h despite the fact that the directory they are in is in the include path.

What am I doing wrong? Eventually, I would like to put the .o files in a library and link to it, but that is for another day. And no, I don't have any idea how to do that at this point.

Also, if I do get "control" to compile, will the linker pick up the mod1.o and mod2.o files in the other directory?
_________________
D. Scruggs

[Ttelmah]

What you describe, can be made to work (on current compilers at least), but remember that the files will need to export the routines. You can't just compile them and link them as an entity. In the examples directory, there is a .zip file, 'mcu.zip', which shows how to do all this. If your compiler is too old to have this, then forget it, it definitely pre-dates the ability working.

However, don't.

Much better to just have the routines as uncompiled sources, which are then included, and linked with the project. Think how the compiler include files are done. You just include these in the project and compile them as part of the project.

Why?.

Multiple reasons. Historically, CCS didn't have a linker at all. It still tends to be more reliable not using linking.
Then there is optimisation. CCS, will optimise code that it compiles as part of a project. Things like maths routines, delays etc., will be shared between the routines. Separate modules reduce the ability to do this.
Then there is also RAM optimistion. Again the compiler will take advantage of re-ordering RAM areas, when the code is all compiled together. Do it as modules, and some of this optimisation is lost.

I've found that on large projects using separate compiler modules, increases the final code size by up to perhaps 10%, and the RAM use by a variable amount (depending on how variables are structured), between nothing, and nearly doubling the use. At this point I decided to stick with single compilation.

I just have directories containing source code .h files pre-written for individual operations, and include what I use.

[bcfd36]

Ttelmah, thank you very much for your answer. I will have to give it some thought. The way of doing things under CCS is quite different from the UNIX/Solaris/Linux, RSX-11M, VMS, PCs, etc. that I have worked under before.

BTW, I am running the PCWHD with EVERYTHING at version 5.018. Not my decision, I just have to live with it.

I also see another potential problem with what I want to do. My common routines would be used by different PIC models. My gut instinct tells me this will not work in the long run.
_________________
D. Scruggs

[Ttelmah]

Especially since the compiler applies bugfixes when the code is compiled...

So even if the same 'core' was involved, the results may need to change for different processors.

There is also another thing I'll add about the difference to Unix etc.. Generally on these, the stack will be used for data storage. As such dynamic memory allocation. The PIC doesn't have a data stack, so means the compiler has to do the allocation....

[bcfd36]

I had a bit of success redoing things closer to what you recommend.

I changed the files to where the the module containing the main and the local routines is in the multi_module_test directory, and the common code is contained in mod1.h and mod2.h in the common directory. common and multi_module_test are at the same level.

The file with main contains includes of mod1.h and mod2.h as follows: