Exact match. Not showing close matches.
'[PIC]: MCLR vs GP3, how to configure in C'
|> Well, I use it in MPLAB, like this:
> __CONFIG B'11111101100100'
> I'm not sure but I guess in C you can use a ASM directive to tell
>compiler you are writing an asm code...
> I hope this helps
Thanks for responding. I was afraid if I tried to "brute force"
the register that I would collide with some other part of the
compiler "secretly" trying to set the configuration on its own.
The answer, I discovered is:
which is kind of a high-level form of directly specifying the
configuration bits. Now the thing I don't like is that I
don't have a list of all the fuse options and what they
correspond to. For instance, how would I use that pin as
an input instead? My guess is #fuses MCLR=NO And
I also wanted to use the internal oscillator. The datasheet
specifies XT, HS, and so on, but also INTRC and EXTRC. So
I plugged in INTRC and it took it. Now the compiler didn't
generate an error, but that's not how I choose to do
Anyone with the CCS compiler can look in the book on page 18 and
see an incomplete list for #fuses. Ok, I'm done complaining.
Next I get to debug it when it doesn't work. :)
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
Peter L. Peres
Usually compilers know nothing about device internals of that level, they
use header files to gather that knowledge. Your compiler folder probably
contains a lot of files named after pic devices (suffix .h probably).
Perhaps you should read them. The header matching the device is loaded by
the compiler (silently). This is something that should not happen imho, it
should be explicit. I.e. if you write for 12C508 then something like
'#include <12C508.h>' should be required, instead of many pragmas and
nonstandard preprocessor directives.
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email mitvma.mit.edu with SET PICList DIGEST in the body listserv
|>Usually compilers know nothing about device internals of that level, they
>use header files to gather that knowledge. Your compiler folder probably
>contains a lot of files named after pic devices (suffix .h probably).
>Perhaps you should read them. The header matching the device is loaded by
>the compiler (silently). This is something that should not happen imho, it
>should be explicit. I.e. if you write for 12C508 then something like
>'#include <12C508.h>' should be required, instead of many pragmas and
>nonstandard preprocessor directives.
Yes, I really hate "magic", which is why I favor the assembler when
I expect to be fighting with the bits. Your suggestion was
right on, and the files start with "P", so P12C671.inc has
all the configuration bits defined. In addition I can
see they are all bit masks which is why you can AND them
together in the config line of the assembler.
Unfortunately, this doesn't document what the C compiler wants, though
it gives strong hints. As does the datasheet. As in, "maybe they
used the same word in their compiler".
Fortunately, I can look at the output of the compiler and find out
just what the registers are getting set to.
Unfortunately, everything I've looked at checks out so far (config,
ADCON1, TRIS) so I'm still looking. Might be in the timer interrupt; lots
of black magic in there. Though it worked fine on the 16F877 ICD.
http://www.piclist.com hint: To leave the PICList
More... (looser matching)
- Last day of these posts
- In 2001
, 2002 only
- New search...