|
|
View previous topic :: View next topic |
Author |
Message |
picman62
Joined: 12 Dec 2014 Posts: 77
|
Multiple compilation units |
Posted: Tue Feb 24, 2015 4:47 am |
|
|
Hi.
When is it an advantage to create a project with multiple compilation units and how effective is it compared to building a regular single project? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Tue Feb 24, 2015 10:22 am |
|
|
I rather doubt there is any advantage,especially none with a single project. I believe the idea is to create your own 'functions' that several projects would use,say a 'driver' for a custom LCD module. Then that code could be 'imported' into several project.
Frankly I don't see ANY benefit,as CCS makes is easy to 'include' code like 'drivers', 'math routines', etc.
Perhaps someone who has done it, can explain why it was /is better but on the surface I can't see any real benefit.
Jay |
|
|
picman62
Joined: 12 Dec 2014 Posts: 77
|
|
Posted: Tue Feb 24, 2015 10:51 am |
|
|
Thanks for clarifying this. |
|
|
mbradley
Joined: 11 Jul 2009 Posts: 118 Location: California, USA
|
|
Posted: Sun Jul 05, 2015 1:04 am |
|
|
Here is an example of a project I did that has 3 different compilation units,
http://www.mculabs.com/projects/ssx32.html
You can basically create an 8ch, 16ch or 32ch servo driver.
In main, you see:
#define SSX32
//#define SSX16
//#define SSX8
the project will either compile for 18F26K20 or 18F46K20 depending on which option you choose.
With this way of doing this, I don't have to maintain 3 separate projects for 3 different servo controllers. _________________ Michael Bradley
www.mculabs.com
Open Drivers and Projects |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Sun Jul 05, 2015 10:35 am |
|
|
The same would work without multiple compilation units.
The key 'problem' to understand about MCU use. is the way the CCS optimiser work. The PIC doesn't have a variable stack (for the 12/14/16/18 chips), so where on most chips the stack can be used for transient variables, and variables that are only used locally to a routine, on the PIC these have to use the main RAM. CCS starts by building a tree of the routines, and then working across the tree, and re-using RAM space for local variables for each branch, into the same areas used for other branches. Unfortunately using MCU's, impedes the efficiency with which this can be done. The same code built with MCU's (depending on the actual code layout), can (will) end up using more RAM. :(
Now the reasons 'to' use MCU's, are on larger code, reducing compilation time (though generally most PIC code is so small that this is not worthwhile - this includes routines filling medium PIC24's, which still takes less than a couple of seconds to compile), or distributing libraries without distributing readable source code (for commercial reasons). This second, can be done in CCS using the encryption option instead.
Historically, CCS was a single pass compiler, without a linker, and it still works better if treated as if this was still the case. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|