Libstock
It is currently 16 Apr 2014 05:28

All times are UTC + 1 hour




Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: 12 Sep 2011 21:01 
Offline

Joined: 06 Mar 2008 17:35
Posts: 80
Location: Laguna Niguel, CA
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

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

...



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


Top
 Profile  
 
PostPosted: 16 Sep 2011 10:45 
Offline
mikroElektronika team
User avatar

Joined: 25 Jan 2008 09:56
Posts: 7121
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group