# Confusion about #pragma in XC8

I'm currently programming a pic16f18323. I'm using MPLAB X. And XC8 as the compiler. I just want to ask if pragma configurations can be shown as ('110' is the binary representation of 3 bit RSTOSC configuration in Oscillator configuration register. Page 50 in 'PIC16(L)F18313/18323' datasheet) :

#pragma config RSTOSC = 0b110


#pragma config RSTOSC = HFINT1


I tried using the first expression instead of the regular(second) one. It didn't give me any compiler error, but it didn't work properly neither. When I program the pic with simple blink code, with 'HFINT1' configuration it works well. But when I use the binary number, the frequency of the blink increases largely.

It makes me think that it is probably about the syntax, but still I'm not perfectly sure. It doesn't affect my work directly, I encountered this problem by coincidence and I just became curious. If someone knows about this I would be glad.

• Hi! Thanks for your comments. Looks like I'm wrong! I'm going to delete my answer before it spreads misinformation :) Aug 28 '16 at 3:58

#pragma is a directive that sends text information to the compiler, which then interprets it according to the rules of the particular pragma. This text is not C code and does not have to be compatible with it.

The relevant definitions for HFINT1 (found in the file '16f18323.cfgdata') are:-

CWORD:8007:2977:FFFF:CONFIG1
CSETTING:70:RSTOSC:Power-up default value for COSC bits
CVALUE:60:HFINT1:HFINTOSC (1MHz)


This tells the config pragma that RSTOSC = HFINT1 means 'set memory at address 0x8007 to 0x60 through a mask of 0x70', which puts 0b110 into bits 6-4 of config register 1.

You should use the defined config names only. Substituting C stye binary numbers will just confuse the pragma.

• Thank you, I think this is a suitable answer. For the ones who are curious, binary syntax #pragma config RSTOSC = 110 without '0b' at the beginning worked for me. Aug 28 '16 at 14:46
• 110 is interpreted as a decimal number, equal to 1101110 in binary. In this case the required upper 3 bits are correct, but only by pure luck. Hex numbers (0x..) will also be interpreted correctly, but you shouldn't put 'magic' numbers into your code! Aug 28 '16 at 17:20
• Oh that was a huge coincidence then, I absolutely got it now. Aug 31 '16 at 21:18