I have a product that went through several development phases. In some of those phases I changed PIC MCU (e.g. from 16F685 to 16F616) used to control its features. Because there is no way (that I can find) to programmatically select the MCU device or even programmatically manipulate the config fuses, maintaining legacy products is a real nightmare. If these things were in place, it would be possible to write code using generic variable names that could be assigned in a header file targeted to a particular MPU flavor. That way, I could make changes and updates in one code file that could be applied to both current and legacy products.
Something like this:
//======= TARGET Specification =========
// Comment out all but the applicable device
And the header files would look something like this:
//========= mpu_pic16f685.h =========
//========= Product Name =========
//========= ver. 1.30 =========
#include <P16F685.c> // Defeats internal link mechanism
CONFIG = 0x0FCC; // Overrides GUI selections
sfr unsigned short volatile PORT_GRP1 absolute PORTA // Not sure if this is valid but something like this needs to be possible
sfr unsigned short volatile PORT_GRP2 absolute PORTB
//========= mpu_pic16f616.h =========
//========= Product Name =========
//========= ver. 3.04 =========
CONFIG = 0x03fC;
sfr unsigned short volatile PORT_GRP1 absolute PORTA
sfr unsigned short volatile PORT_GRP2 absolute PORTC
I suspect your reason for doing it this way, is to allow for a "seemless" integration of these definitions with customer source code--in an attempt to hide complexity and make the C environment more like a BASIC environment, etc. But, the down side, it seems to me, is the lack of programmatic control. Sometimes I appreciate this "hand holding" because, in my line of work I wear many hats and sometimes go for months without doing any PIC programming, so when I come back I'm a bit rusty and can get up to speed more quickly when wizards, and GUI's show me the way. But, my use of them, generally, stops once they re-awaken my "little grey cells" (i.e. I use them as a re-training aid).
Once I'm back up to speed, I, personally, find it easier, and less error pron, to do these selections in the code, rather than relying on GUI's and Wizards that hide the functionality and require one or more external steps that I have to remember to do when switching between products/versions/legacys. I would rather be able to do that in one place.
Since you guys are doing something that seems a bit non-standard in implementing as ".c" files [e.g. P16F616.c], what would normally be header files for defining the register names (and such) of specific PIC devices, you will probably need to find a way to send signals from the main object file to the linker. Perhaps this could be done with a preprocessor directive that tells the linker/make utility to select the requested MPU object.
Even if I could do something like a #include on a saved "Scheme", that would be an improvement (or, perhaps a function called IncludeScheme(char *scheme_path)
I imagine that programmatic controls such as I am describing here, could lead to some support headaches due to people applying them and then complaining because the GUI settings don't "take" (because they forgot that the programmatic inclusions override the GUI settings), so add notations to the GUI and in the Compile Messages. I know that won't completely solve the problem, but I think the value of adding this kind of control out weights the possible customer static that might ensue.