 |
 |
| View previous topic :: View next topic |
| Author |
Message |
daVinci_Claude
Joined: 09 Mar 2014
Posts: 2
|
| Beginner question: PIC16F886 SFRs? |
 Posted: Sun Mar 09, 2014 7:17 am |
 |
|
Hi there
I'm new to programming PICs, and I'm encountering problems with SFRs.
I'm just trying to set the General Interrupt Enable bit:
| Code: | #include <16F886.h>
#FUSES NOWDT
#FUSES PUT
#FUSES NOPROTECT
#FUSES NOBROWNOUT
#FUSES NOLVP
#FUSES NOCPD
#use delay(clock=4M)
main(void)
{
GIE = 1;
while(1) {}
} |
The error message is:
| Quote: | | Undefined identifier GIE |
Compiler Version: 5.001
Target: PIC16F886
Standard Run Mode
5V, 4 MHz Standard
So, I probably need a header file which tells the compiler where/what GIE is.
But where can I find this file? I found the PIC16F886.h file, but this seems to be for mpasm? ("3. Processor Type entry in the MPASM full-screen interface")
I also foundthis PIC16F84 file, which seems to be what I need for the 886.
Where do I find this file and how do I include it correctly?
Kind regards
Mark |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Mar 09, 2014 2:47 pm |
|
|
Do you have the CCS IDE compiler (PCWH, PCWHD) ? I don't have it,
but I believe there is a button to create the register header file, possibly
in the Device Editor. I can't find a screen shot of the recent Device
Editor on the net. Unless someone else answers, you just need to look
around in the IDE and find it.
If you can't find it, there are other options for direct register access.
However, direct register access is not the preferred way to write CCS
programs. There are functions to do most it. Usually they are sufficient. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sun Mar 09, 2014 2:48 pm |
|
|
| Quote: |
Compiler Version: 5.001 |
that was the first BETA !!!!
get a real released version like 5.020 or later
before you do ANYTHING else.....
ver 5.001 belongs in your desktop recycle bin, seriously.... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sun Mar 09, 2014 2:53 pm |
|
|
but also, as a general comment, only use SFR's directly, if there is not a CCS function to do things.
enable_interrupts(GLOBAL);
sets the GIE bit. |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Sun Mar 09, 2014 4:04 pm |
|
|
| Ttelmah wrote: | but also, as a general comment, only use SFR's directly, if there is not a CCS function to do things.
enable_interrupts(GLOBAL);
sets the GIE bit. |
AND, it is portable between processors (let CCS figure out which SFR address to talk to).
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sun Mar 09, 2014 4:13 pm |
|
|
but if you MUST be explicit - here is the CCS way to do it :
| Code: |
//two steps , in case you want to refer to INTCON for other bits
// and want to document better what the code is about
// re: the datasheet
#BYTE INTCON = 0X0B
#BIT GIE =INTCON.7
// or just rip&&run
#BIT GIE =0x0B.7
|
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Mar 09, 2014 4:44 pm |
|
|
The basic problem with this is that he's a newbie and we're giving him
more advanced information than he needs at this point.
Using direct register access will only make his programs fail more often.
The reason it's better to use CCS functions is because they handle
everything that's required (usually). Just enabling GIE isn't enough.
Here's the list file code for a 16F886. Note that it sets not only the GIE
bit, but also the PEIE bit:
| Code: | .................... enable_interrupts(GLOBAL);
001A: MOVLW C0
001B: BCF STATUS.RP1
001C: IORWF INTCON,F
|
If you look at this figure in the 16F886 data sheet,
| Quote: | | FIGURE 14-7: INTERRUPT LOGIC |
you will note that PEIE acts as a gate for large numbers of interrupts.
To sum up, the original poster should only use CCS functions. |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Sun Mar 09, 2014 7:55 pm |
|
|
yes i agree totally - my bad
what i showed is ONLY for when you look at the .LST file and find CCS has screwed the pooch in terms of their own function calls.
PCM is on target except for the rare occasion when CCS is NOT
 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Mon Mar 10, 2014 1:22 am |
|
|
and as a further comment, you may not have spotted Asmboy, that you can use bit names directly with getenv. So if you do want to access this one bit:
| Code: |
#bit getenv("BIT:GIE")
|
Gives direct access to this one bit. 
Best Wishes |
|
|
daVinci_Claude
Joined: 09 Mar 2014
Posts: 2
|
|
| Posted: Mon Mar 10, 2014 12:25 pm |
|
|
Thank you guys for those quick answers.
I noticed those functions like enable_interrupts(GLOBAL); when reading the manual, but I want to understand the whole thing, how it works. For this reason I want to configure those registers manually.
BTW, thank you for the compiler version hint!
Kind regards
Mark |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Mar 11, 2014 4:30 am |
|
|
| daVinci_Claude wrote: |
I noticed those functions like enable_interrupts(GLOBAL); when reading the manual, but I want to understand the whole thing, how it works. For this reason I want to configure those registers manually.
|
If you want to understand how it works, the best thing is probably to use the CCS functions, and then inspect/dissect the assembler it produces. Then, if you want to really test your knowledge, then you can do your own thing. That's how I learnt, but it wasn't on PICs it was on a small 18 bit machine from the late 60s. I still remember the - rainy - afternoon I worked out how jumps (the machine didn't have branches) were performed.
Once learnt, I never wanted to use assembler again. I have, of course, many times, including on earlyish PICs such as the 16C74, and 6809 (assembling by hand as I had no access to an assembler, let alone a compiler), 6502, various PDP11s, TMS32010 DSP, even a bit of 8086 stuff.
While processors do differ, in architecture, instruction set, and operating paradigm, a lot of concepts are common, and once grasped, are transferable to almost any machine. From that point on, however, I never wanted to program in assembler, or needed to know all the details of a processor. If there was a compiler to do all that for me, then that's what I'd use - the productivity gains were just too much to throw away.
What I'm saying is that trying to knife and fork it, eschewing the considerable assistance the compiler gives you, is an inefficient and arguably perverse way of learning how these beast work. But if it works for you... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Tue Mar 11, 2014 4:53 am |
|
|
Very much agree.
Funnily enough one of the great 'powers' of CCS, is that you can directly access bits, bytes etc., using the #bit and #byte directives, allowing you to effectively do everything that assembler can do.
This makes it very attractive to people who want the power of assembler, without getting involved 'in' assembler. Even it's actual assembler, contains short-cuts, so you can use 'C' variable names directly inside assembler code. Much less likely to go wrong.
I too date back to when in many cases 'assembler' was the only choice, and have done a lot of assembler coding, for a huge range of processors, including ones I've designed myself. Because of this, I've had to actually write assemblers, and then compilers. CCS unfortunately has some core weaknesses (I don't think they have ever heard of a T diagram, or how to properly code the core of a compiler), which is why so often some peculiarities keep appearing. However the other part of it, is the sheer vagaries/varieties of the processors themselves. Some are insane (why they will keep having components that work in older processors and then have major errata in later chips...), and also why they have never really added better hardware support for speedy interrupts (A 'PIC+', with a complete set of all the main registers, swappable with a single instruction - been done on many older processors, but nothing like this on the PIC, except for a tiny 'handful' - less than a handful actually - of registers...).
If you set the compiler to generate 'symbolic' list file format, you get assembler output, using nice names, rather than numbers. Studying this, and then changing just one thing, and seeing what it produces, is a very good way to 'learn the core'. It's even worth trying some basic routines like incrementing an 8bit variable, then a 16bit one, and seeing how things are handled. However the key thing about the compiler is it's flexibility for basic code. I can (have on many occasions), set up basic test routines, with a serial I/O, and a few pins doing jobs, in a dozen lines of code, and had it running in under 10 minutes. Trying to do this in assembler, and you'd still be looking up the basic configuration settings, before starting, at this time...
As PCM_programmer pointed out, the compiler 'knows' that the peripheral interrupt enable also has to be set, so does this for you. Things like this are too easy to miss, to waste time, not letting the compiler do it for you...
Best Wishes |
|
|
|
|
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 vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
