Make It Easier To Programmatically Target PIC Devices

Post your requests and ideas on the future development of mikroC PRO for PIC.
Post Reply
Author
Message
steve42lawson
Posts: 183
Joined: 06 Mar 2008 17:35
Location: St. George, UT
Contact:

Make It Easier To Programmatically Target PIC Devices

#1 Post by steve42lawson » 12 Sep 2011 21:01

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:

Code: Select all

//======================================== 
//=======  TARGET Specification  ========= 
//======================================== 
// Comment out all but the applicable device

//#include "mpu_pic16f685.h"
#include "mpu_pic16f616.h"

...

And the header files would look something like this:

Code: Select all

//===================================
//========= 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
...

Code: Select all

//===================================
//========= mpu_pic16f616.h =========
//=========   Product Name  =========
//=========    ver. 3.04    =========
//===================================
#include <P16F616.c>
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.
Humility is the lack of the desire to impress, not the lack of being impressive.

User avatar
filip
mikroElektronika team
Posts: 11874
Joined: 25 Jan 2008 09:56

Re: Make It Easier To Programmatically Target PIC Devices

#2 Post by filip » 16 Sep 2011 10:45

Hi,

Thank you for this extensive elaboration.

We really appreciate the time and effort that you have spent to give us a new look on this matter.
I have reported this to our developers; they will thoroughly analyze this.

If you have anymore suggestions regarding any product of our company, do not hesitate to publish them here.

Regards,
Filip.

Post Reply

Return to “mikroC PRO for PIC Wish List”