CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Beginner question: PIC16F886 SFRs?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
daVinci_Claude



Joined: 09 Mar 2014
Posts: 2

View user's profile Send private message

Beginner question: PIC16F886 SFRs?
PostPosted: Sun Mar 09, 2014 7:17 am     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Mar 09, 2014 2:47 pm     Reply with quote

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

View user's profile Send private message AIM Address

PostPosted: Sun Mar 09, 2014 2:48 pm     Reply with quote

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: 19446

View user's profile Send private message

PostPosted: Sun Mar 09, 2014 2:53 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Mar 09, 2014 4:04 pm     Reply with quote

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

View user's profile Send private message AIM Address

PostPosted: Sun Mar 09, 2014 4:13 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Mar 09, 2014 4:44 pm     Reply with quote

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

View user's profile Send private message AIM Address

PostPosted: Sun Mar 09, 2014 7:55 pm     Reply with quote

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

Very Happy Very Happy
Ttelmah



Joined: 11 Mar 2010
Posts: 19446

View user's profile Send private message

PostPosted: Mon Mar 10, 2014 1:22 am     Reply with quote

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. Smile

Best Wishes
daVinci_Claude



Joined: 09 Mar 2014
Posts: 2

View user's profile Send private message

PostPosted: Mon Mar 10, 2014 12:25 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Mar 11, 2014 4:30 am     Reply with quote

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: 19446

View user's profile Send private message

PostPosted: Tue Mar 11, 2014 4:53 am     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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