• AVR Freaks

LockedWhere are CONFIG options defined?

Page: < 123 > Showing page 2 of 3
Author
NKurzman
A Guy on the Net
  • Total Posts : 19116
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re:Where are CONFIG options defined? 2012/09/06 12:33:22 (permalink)
0
Ah.... the Old Windows 7 search could not find my file issue.
 
Careful there is V1.01 and V1.10  
#21
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/09 07:30:20 (permalink)
+2 (1)
I've run into this issue porting some old HiTech C for PIC10/12/16 code.
 
Actual supported config settings of the #pragma config <SETTING> = <VALUE>  form can be found in human readable commented database format in:
%ProgramFiles%\Microchip\xc8\v1.10\dat\cfgdata
Just open the correct <PIC_NUMBER>.cfgdata file for your device in a text viewer.
 
The mappings from the __CONFIG( <CONFIG_MACRO>  & <CONFIG_MACRO><CONFIG_MACRO> ... ) form to the #pragma form is in:
%ProgramFiles%\Microchip\xc8\v1.10\dat\cfgmap
Again, simply open the correct <PIC_NUMBER>.cfgmap file for your device in a text viewer.
 
There are a couple of subtle 'gotcha's though.  The CONFIG macros are no longer equivalent to numeric values, and aren't even #defined any more.   This breaks HiTech C code that does stuff like the following (from a PIC12F675 project).
 
In my main.c, before any functions:
 
__CONFIG (MY_CONFIG); //From hardware.h

and in hardware.h, (which keeps it with my I/O mapping #defines)
 
#define MY_CONFIG (INTIO & MCLRDIS & WDTDIS & PWRTEN & BOREN & UNPROTECT)

 
The cure is to redefine MY_CONFIG as:
 
#define MY_CONFIG FOSC_INTRCIO MCLRDIS WDTDIS PWRTEN BOREN UNPROTECT

Note: The important step is to remove the surrounding ( ) round the CONFIG macros in #DEFINE MY_CONFIG.   You also need to replace legacy CONFIG_MACRO ones with the current ones from the .cfgmap file EVEN IF YOU ARE STILL #DEFINING _LEGACY_HEADERS. You may leave the &'s in but they serve no purpose. If you were using the HiTech post v9.81 CONFIG macros, simply remove the ( ) and leave the & in for backwards compatibility.  
Edit: Fixed missing config in the #pragma above.
HTH
Ian
post edited by Ian.M - 2012/09/16 15:43:54
#22
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/14 15:03:54 (permalink)
0
Ian.M
The mappings from the __CONFIG( <CONFIG_MACRO>  & <CONFIG_MACRO><CONFIG_MACRO> ... ) form to the #pragma form is in: 
%ProgramFiles%\Microchip\xc8\v1.10\dat\cfgmap
Again, simply open the correct <PIC_NUMBER>.cfgmap file for your device in a text viewer.
 
I wonder if it just me but I'm seeing a reversal of values, at least on PWRTE, WRT and CP bits, when I use the #pragma (alleged) equivalent  declaration.
 
I'm using MPLABX v1.41, xc8 v1.10 free and ICD3 with this:

__CONFIG(FOSC_INTOSC & WDTE_OFF & PWRTE_OFF & MCLRE_ON & CP_OFF & BOREN_OFF & CLKOUTEN_OFF & IESO_OFF & FCMEN_OFF);
__CONFIG(WRT_OFF & VCAPEN_OFF & STVREN_OFF & LPBOR_OFF & LVP_OFF);

So, after compiling with this, everything is ok, apart from the IDE complaining of the __CONFIG.
Then the equivalent:
 
#pragma config FOSC=INTOSC, WDTE=OFF, PWRTE=OFF, MCLRE=ON, CP=OFF, BOREN=OFF, CLKOUTEN=OFF, IESO=OFF, FCMEN=OFF, WRT=OFF, VCAPEN=OFF, STVREN=OFF, LPBOR=OFF, LVP=OFF

After compiling the IDE complains not being able to debug because PWRTE is ON and WRT is ON.
Checking the Config Bits windows, it in fact says the bits are ON.
 
As I said, is it something I'm doing wrong or is this a bug?
 
TIA
jss
 
#23
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/15 04:53:45 (permalink)
+2 (1)
Just answered myself, it's self inflicted.
 
I have
 

#define ON     1
#define OFF    0
#define TRUE  1
#define FALSE 0
 

in my header file, as I think most people have.
 
So, the compiler preprocesses
 

#pragma config PWRTE=OFF  // as PWRTE=0 which is ON because the bit is negated
 

I don't thing it's a good idea to use ON and OFF for this semantic. Most people #defines them, I think.
 
So, now I'm left with a dilemma: either I keep using the legacy __CONFIG, while MC allows it, or I'll have to change ON and OFF on all my active files. Not good.
 
jss
#24
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/15 06:13:25 (permalink)
0
Its a kludge, but I think you could simply move the #pragma config to before the #include as the #pragma config no longer relies on constants from the header!
 
However I am with you in preferring the __CONFIG() form as it makes it considerably simpler to put a #define of the whole config in my hardware.h file (that every .c file in the project that does any I/O includes) so I can keep my hardware dependent stuff in as few files as possible.   If the initialisation is complicated enough, I also have a hardware.c which gets the actual __CONFIG() statement, otherwise that goes in main.c.  The multi-line #pragma form is obviously not amenable to this treatment, and the single line #pragma is just plain ugly though I suppose I could use it with #define the same way.
post edited by Ian.M - 2012/09/15 06:21:52
#25
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/15 08:02:08 (permalink)
0
Thanks for replying.
Ian.M
Its a kludge, but I think you could simply move the #pragma config to before the #include as the #pragma config no longer relies on constants from the header!

Yes, you're right, it works. But I find this a severe limitation that I'm always supposed to remember whenever I start a new project.
I still think that ON and OFF must always mean the same thing, independently of the context. I mean, obviously lights OFF == darkness ON, but it's misleading.
Ian.M 
However I am with you in preferring the __CONFIG() form

What worries me is how long this legacy will last and, when it stops, we are left with the same problem unless someone does something about it.
Rgds
jss
#26
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/15 09:47:38 (permalink)
0
As ON and OFF may not be a consistent logic level, even within the same project (e.g. active low switch input and active high driver for a motor) simple #defines for ON and OFF are usually misleading and counter-productive.   I would define SW_ON and SW_OFF and also MOT_ON and MOT_OFF, which also avoids the clashes with the CONFIG.
 
However if you insist on writing code that clashes with the compiler's reserved words, worst case: if __CONFIG() ever is removed, roll your own.    The basic definition from HiTech C v9.83 pic.h is:

#define    __CONFIG(x)    asm("\tpsect config,class=CONFIG,delta=2");\
            asm("\tdw "___mkstr(x))

and ___mkstr() is found in htc.h:

/* common definitions */

#define    ___mkstr1(x)    #x
#define    ___mkstr(x)    ___mkstr1(x)

You would obviously need the 'andable' CONFIG bit #defines as well for the specific device, which could be generated by parsing the MPASM includes or simply copied from the old HiTech headers.
 
#27
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/15 18:46:40 (permalink)
0
Thank you for the __CONFIG() definition, I feel safer now.
Ian.M
 ON and OFF... compiler's reserved words

Not just by curiosity but because it affects a lot of my previous files, I went through the whole manual and I didn't see any reference for ON and OFF being reserved words, do you know where it is stated?
If they are indeed reserved, shouldn't the compiler show an error if you try to redefine them?
 
Rgds
jss
#28
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/15 20:52:20 (permalink)
0
Unfortunately I cant find a list of reserved words in the new XC8 manual.  I've tried the obvious sections and looked at anything that might give a clue but it just doesn't seem to be there.  I am surprised by this omission.   We are given the list of predefined macros (5.14.3).  As the words in question for #pragma config are understood by the preprocessor irrespective of the inclusion of any headers, we really should be given a full list of them. 
 
An ANSI C compliant preprocessor will not emit warnings for redefining reserved words - that is 'fair game' to the preprocessor.  Just about the only thing you are not allowed to do, is to use the preprocessor to redefine one of its own commands.
post edited by Ian.M - 2012/09/16 20:37:15
#29
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 04:32:47 (permalink)
0
Ian.M
 Unfortunately I cant find a list of reserved words in the new XC8 manual....As the words in question for #pragma config are understood by the preprocessor irrespective of the inclusion of any headers...
 

Neither can I.
 
However, I have a hunch on what's happening: The devs didn't see the need to reserve the words (ON and OFF) because they didn't anticipate that these words were not confined to the #pragma config, or the setting itself within the #pragma; to reinforce this, please see that in one setting, for instance MCLRE, ON means "1" whereas on PWRTE, ON means "0"; see what I mean? it must be confined to the setting, can't even be broad within the #pragma.
 
The whole problem is the setting also accepting numerical values and the preprocessor replaces the defined (in my case) ON with "1". Then the #pragma config accepts "1" as OFF (for PWRTE).
 
Even the IDE is not painting the ON and OFF within the #pragma as #defined words, which means it thinks it's not replaceable, as the devs. The preprocessor thinks otherwise.
 
The whole thing is rather illogical, I would still prefer to let alone the broadly used ON and OFF and use the old __CONFIG() form, i.e. PWRTE_ON and PWRTE_OFF.

 I would define SW_ON and SW_OFF and also MOT_ON and MOT_OFF

I have tens (hundreds?) lines similar to these:
 

TMR0IE = ON; // Enable TMR0 interrupts
GIE = ON;
OutReg.Out.SupZones = ON;
...
 

With just two defines, ON and OFF. If I had to write it like this:

TMR0IE = TMR0IE_ON; // Enable TMR0 interrupts
GIE = GIE_ON;
OutReg.Out.SupZones = OutReg.Out.SupZones_ON;
...
 

How many #defines would I have to establish?
 
I'm sorry I can't agree with you, if you want to own a very common word like "ON", it must always mean the same thing, preferably "1", not sometimes one thing and others its reverse.
 
Rgds
jss
 
 
#30
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 06:01:50 (permalink)
+2 (1)
The problem would be alleviated if they also supported the use of the same words with one (or possibly 2) leading underscores, or allowed #pragma CONFIG to take a string literal for its arguments - so blocking macro expansion.
If your code is that much dependent on:
 
    #define ON 1
    #define OFF 0

and they do ever totally depreciate __CONFIG(), simply put your #pragma CONFIGs in a separate source file that DOES NOT include your project specific headers.
 
What do you do with inverse logic SFR bits like RBPU?  Using your simple scheme ON would be off. Smile
 
To preserve existing code, you could simply define ON and OFF as C constants, which will be invisible to the preprocessor. e.g.
 
static const unsigned char ON=1,OFF=0;

static so it is restricted to the current compilation unit and unsigned char in the hope that the compiler wont generate too much bloat, but I suspect that the free XC8 will generate pretty nasty code compared to the current  #defined literals.
post edited by Ian.M - 2012/09/16 06:04:20
#31
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 06:46:39 (permalink)
0
Ian.M
The problem would be alleviated if they also supported the use of the same words with one (or possibly 2) leading underscores
 
Agreed. But, recovering what I said before, why not of the form PWRTE_ON? (as before in __CONFIG()).
Using this form, we wouldn't have an ambiguity of values on the same symbol.

or allowed #pragma CONFIG to take a string literal for its arguments - so blocking macro expansion.

Yes, also acceptable.
 
...they do ever totally depreciate __CONFIG(), simply put your #pragma CONFIGs in a separate source file that DOES NOT include your project specific headers.
 
Yes, but I find it simpler to make my own ___CONFIG() macro as you explained on a previous post, and include it in a immutable header file that I use in every project, mydefs.h, where I define, among many things, ON and OFF.
 
What do you do with inverse logic SFR bits like RBPU?  Using your simple scheme ON would be off. Smile
 
Well observed. If I don't change the RBPU in the runtime code, I usually initialize it bytewide.
Otherwise, if I have to, I define RBPU_ON and RBPU_OFF, similarly to what you said before, SW_ON and SW_OFF, but also applicable to PWRTE_ON; we come  to the same point. Sometimes I also use my also #defines HI and LO in similar situations, but never ON and OFF on reversed meaning bits.
 
To preserve existing code, you could simply define ON and OFF as C constants, which will be invisible to the preprocessor. e.g.
  
static const unsigned char ON=1,OFF=0;

static so it is restricted to the current compilation unit and unsigned char in the hope that the compiler wont generate too much bloat, but I suspect that the free XC8 will generate pretty nasty code compared to the current  #defined literals.

As you already concluded, this is not advisable.
 
I've been enjoying and learning a lot from our discussion, thank you.
Rgds,
jss
 
#32
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 08:18:45 (permalink)
0
I've got a workaround for you:
 
#define ON 1// the problematic defines
#define OFF 0
 
#define CFG(x,y) ##x = ##y , // *SERIOUS* abuse of the ## operator to prevent macro substitution
#define MY_PRAGMA_CONFIG \
    CFG(FOSC, INTRCIO) \
    CFG(MCLRE, OFF) \
    CFG(WDTE, OFF) \
    CFG(PWRTE, ON) \
    CFG(BOREN, ON) \
    CFG(CP, OFF) \
    CFG(CPD, OFF)
 
#pragma config MY_PRAGMA_CONFIG

or simply use as many CFG() as required separated by whitespace in the #pragma config line. The  trailing ',' from the last CFG()  doesn't seem to matter.


#pragma  config \
     CFG(FOSC, INTRCIO) \
     CFG(MCLRE, OFF) \
     CFG(WDTE, OFF) \
     CFG(PWRTE, ON) \
     CFG(BOREN, ON) \
     CFG(CP, OFF) \
     CFG(CPD, OFF)

Tested using Microchip MPLAB XC8 C Compiler (Free Mode)  V1.10 for a PIC12F675.
 
 
post edited by Ian.M - 2012/09/16 08:27:50
#33
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 08:54:55 (permalink)
0
Brilliant idea!
It's very manageable, we don't have to pay attention to the order of the #defines, with just a CFG() definition on my mydefs.h and the typing increment / file readability, is reasonable.
 
I just gave it a personal touch. So, my final form is
 

/* mydefs.h */
#define CFG(x,y) ##x = ##y // notice no comma
#define ON      1
#define OFF     0
 
/* headerfile.h */
#pragma config CFG(FOSC,INTOSC), CFG(WDTE,OFF), CFG(PWRTE,OFF), CFG(MCLRE,ON), CFG(CP,OFF), CFG(BOREN,OFF), \ 
              CFG(CLKOUTEN,OFF), CFG(IESO,OFF), CFG(FCMEN,OFF), CFG(WRT,OFF), CFG(VCAPEN,OFF), \
              CFG(STVREN,OFF), CFG(LPBOR,OFF), CFG(LVP,OFF)
 

 
Thank you so much for your time and support.
Rgds
jss
 
#34
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 10:24:53 (permalink)
0
Fine, if you like typing commas.  Me, I'm *L*A*Z*Y! mr green
N.B. you will need to watch out that the next XC8 version doesn't break the whole token pasting as an anti-expansion thing.
If it does, try:

#define CFG(x,y) , ##x = ##y // more *SERIOUS* abuse of the ## operator to prevent macro substitution

which at least avoids a leading ## by prefixing it with a comma.  (#pragma config doesn't seem to mind what punctuation is used).  However it is still trying to concatenate a legal C identifier token with a punctuation token to make one (illegal) token so we are still in undefined behaviour territory. pink[:-]
For reference (underlining added myself):
ANSI C89 (draft)
3.8.3.1 Argument substitution
After the arguments for the invocation of a function-like macro have been identified, argument substitution takes place. A parameter
in the replacement list, unless preceded by a # or ## preprocessing token or followed by a ## preprocessing token (see below), is replaced by the corresponding argument after all macros contained therein have been expanded. Before being substituted, each argument's preprocessing tokens are completely macro replaced as if they formed the rest of the source file; no other preprocessing tokens are available.
...
3.8.3.3 The ## operator
A ## preprocessing token shall not occur at the beginning or at the end of a replacement list for either form of macro definition.
Semantics
If, in the replacement list, a parameter is immediately preceded or followed by a ## preprocessing token, the parameter is replaced by the corresponding argument's preprocessing token sequence. For both object-like and function-like macro invocations, before the replacement list is reexamined for more macro names to replace, each instance of a ## preprocessing token in the replacement list (not from an argument) is deleted and the preceding preprocessing token is concatenated with the following preprocessing token. If the result is not a valid preprocessing token, the behavior is undefined.  The resulting token is available for further macro replacement. The order of evaluation of ## operators is unspecified.
...

#35
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 12:21:12 (permalink)
0
Ian.M
 Fine, if you like typing commas.

I love reusable code and I quickly thought it could be a good asset in the future, without the comma in the way, for something like:
CFG(apples, not_potatoes) expanding to apples = not_potatoes
The price to pay for this versatility is typing the commas in the #pragma case.
 
Thank you for your references but, concerning future problems, I'll have to deal with them as they cross my way, and I always rely on altruistic people like yourself for help.
 
Rgds,
jss
#36
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 16:14:19 (permalink)
0
If you want that, and  neither apples nor  not_potatoes have previously been #defined as something else, simply:
 
 #define SET(x,y) (x=(y))

will do the job + is 'kosher' ANSI C, or for that matter legit in any other C dialect I've used since the '80's.
 
The only reason for (ab)using the ## preprocessor operator was to inhibit macro expansion of CFG()'s parameters to solve your problem with #defined ON and OFF.
 
Its interesting to see how easy it is to abuse the parser that #pragma config  uses.  I even found that it *will* accept quoted <name>=<value> pairs (with judicious use of whitespace), so long as ONE pair is *NOT* quoted! WTF!!! LoL
 
post edited by Ian.M - 2012/09/16 20:33:19
#37
mad_c
Super Member
  • Total Posts : 1271
  • Reward points : 0
  • Joined: 2010/12/12 17:48:27
  • Location: Brisbane, Australia
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 18:22:13 (permalink)
0
jss
I don't thing it's a good idea to use ON and OFF for this semantic. Most people #defines them, I think. 

So, now I'm left with a dilemma: either I keep using the legacy __CONFIG, while MC allows it, or I'll have to change ON and OFF on all my active files. Not good.

Just a general comment: If you create a preprocessor macro that redefines any symbol used by a compiler, whether that be another macro, a keyword, and SFR name or a token used in a pragma, then this could lead to problems. The compiler can warn on redefining preprocessor macros, but not with pragma tokens or other symbols. But this should not be a problem. The #pragma config lines can be placed anywhere in your code, so why not place them in a separate module that does not define any preprocessor macros at all. You can define ON and OFF elsewhere as you like, but just do not expose your pragmas to these definitions.
 
Thanks for raising this issue, though, as it will trick a lot of people. We'll see if there can be a better solution.
 
Jeff.
 
 
#38
Ian.M
Super Member
  • Total Posts : 13273
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/16 20:28:36 (permalink)
0
Hi, Jeff
It's always good to have input from the development team. Thank you. 
 
If you could simply support a quoted string literal paramater for #pragma config (similar to the way asm() works) e.g. accept:
   
 #pragma config "FOSC=INTRCIO, MCLRE=OFF, WDTE=OFF, PWRTE=ON, BOREN=ON, CP=OFF, CPD=OFF"

as an alternative to the current:
   
 #pragma config FOSC=INTRCIO, MCLRE=OFF, WDTE=OFF, PWRTE=ON, BOREN=ON, CP=OFF, CPD=OFF

it would solve the problem of collisions with the preprocessor macro namespace with no other side effects.
It should simply strip all " characters from the rest of the #pragma config line before further evaluation so that C style string literal concatenation is effective.  
 
The easy option of removing the ability to use preprocessor macros in #pragma config would be a retrograde step as surely I am not the only one who modifies the CONFIG using macros rather than using multiple CONFIGs and conditional compilation.
Regards
Ian.
post edited by Ian.M - 2012/09/16 20:52:15
#39
jss
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2011/08/20 01:17:33
  • Location: 0
  • Status: offline
Re:Where are CONFIG options defined? 2012/09/17 03:53:37 (permalink)
0
Ian.M
Its interesting to see how easy it is to abuse the parser that #pragma config  uses.  I even found that it *will* accept quoted <name>=<value> pairs (with judicious use of whitespace), so long as ONE pair is *NOT* quoted! WTF!!! LoL 
 

These inconsistencies frighten me. I mean, if I can see the errors, I can find a workaround.
But, if the compiler makes an error, or doesn't detect one of my errors, or typos, and this is included in the final product as a ticking bomb, this frightens me.
 
Rgds
jss
 
#40
Page: < 123 > Showing page 2 of 3
Jump to:
© 2021 APG vNext Commercial Version 4.5