Best Practices: #include .c versus Multiple Compilation Unit

[allenhuffman]

After I started posting here about "challenges" I faced with the CCS compiler, several responded saying to avoid using Multiple Compilation Units.

I had a test program using several .c files and MCU and it worked just fine, but when I moved those files into one of our larger production projects (dozens of .C files using MCU), it wouldn't build. Using suggestions from this forum, I included all the .c files using #include and the same code built just fine. This makes me think there's something wonky with MCU or just something I don't understand.

At work, we have a bunch of CCS IDE projects with dozens of files each all using Multiple Compilation Units just fine. It just seems that something I have in my code (which worked FINE in one project using MCU but wouldn't in another - same files!) causes issues.

Could someone explain a "best practice" for large projects made up of dozens of .c files?

Thanks!
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

[jeremiah]

From my own experience the "worked fine" litmus test is not a very good one, so I wouldn't always rely on that.

Things that I have found that cause multiple compilation unit to not build is the lack of a #include reference to the ".h" file for the micro in each (yes each and every one) of the C files. Since CCS doesn't use an actual linker, it uses other trickery to emulate it. Part of the requirements for that to work was to ensure that every C file had the right #DEVICE directive in it (which the micro's ".h" file has). Additionally, if there were any other micro specific precompiler directives (#use, #pin_select, #device, #build, #fuses etc.), all C files should have access to those as well. I usually made my own header file that included the micro's header at the top, and all my other preprocessor directives in it. I then #include 'ed that file in all my C files.

I would note that when I last evaluated multiple compilation units, while everything seemed to be fine at first, I noticed some somewhat random oddities in the code while running the firmware in an actual environment. After viewing the generated hex I found that the compiler was not doing a good job of sharing all those settings I put in my header file. In some cases it duplicated code, in others, there were order issues, etc. I hope that the newer versions (last 3 years or so) have done better in that regard.

Might be something to at least consider.

So I have gone to doing the "include" method and use the following rules to help enforce stuff:
1. I only include the .c files at the end of the main.c file so that they are all in one spot and nothing is hidden
2. Every C file has a #module directive directly under the #includes in its file. This is to help keep me from randomly accessing a function or variable I didn't mean to. #including everything together puts everything into the same file scope and global space.

[Ttelmah]

You will find that the version using MCU's will be larger, and potentially slightly
slower than the version using single compile. The reason is that the compiler
can only optimise section by section when using MCU's, while with the single
compile the optimisation can be on the entire code.
Honestly, use single compile. I compile programs that are over 120000 lines
and it takes less than 2 seconds to do. So why use MCU's?.

[newguy]

I have to chime in to agree with Ttelmah. The CCS compiler works best using the traditional "include all" model. I also have a fundamental disagreement with precompiled libraries as, I've learned, they tend to be trusted too much.

...Just thinking back to the PID library I inherited years back in a prior position. It had been written years earlier by a summer student and filed away, not to be examined for years. Simply trusted. Until I started to dig into why things didn't behave right. Then I found that the summer student didn't understand what a derivative was, and our PID library was actually PI.

[allenhuffman]

[temtronic]

re: 'slow PC'....
A PC used for 'engineering' should NOT have 99.9944% of the 'stuff' that's probably there, specially autoupdaters, internet access, wordprocessors, spreadsheets, Autocad, email, etc. Have a look at the 'tasks' running and I'll wager you could/should delete most of them.
Yes, I know that's 'not how it's done' these days but even today's PCs only do ONE thing at a time so the 'leaner' the software, the faster the PC will be.

Jay

[Ttelmah]

The thing that slows it the most, is poor disk performance.
Run a ramdisk, and just put the project in this. I'll bet you'll find
the compile speed will be vastly better.
Search for 'DataRAM'. It's free.