Jump to content
lhbradley

Processor Header File Need Proper Defs For 16 Bit Sfrs

Recommended Posts

I'm new to SourceBoost; I have been porting an app from Basic18 to C. I'm trying XC8, C18, and SourceBoost.

I discovered that the header file for an 18F2620 defines ALL the SFRs as CHAR types, even those (such as CCPR1 and ADRES).

 

When I tried this:

 

ccpr1 = 700;

 

The complier just put the low byte of 700 into the CHAR variable ccpr1. Worst of all, the compiler didn't give any warnings that data was being lost.

 

I was able to redefine the ccpr1 register in my code

#define ccpr1 int @CCPR1

 

but this shouldn't be necessary. And warning of lost data would be real nice.

 

I understand that the header files are probably generated from the MPASM ones by a program, and that it would be difficult to to manual create all the headers, but there are only a few 16 bit SFRs. Perhaps the program could take these into account.

 

Thanks

 

Larry Bradley

Ottawa, Canada

Share this post


Link to post
Share on other sites

Larry,

I discovered that the header file for an 18F2620 defines ALL the SFRs as CHAR types, even those (such as CCPR1 and ADRES).

 

When I tried this:

 

ccpr1 = 700;

 

The complier just put the low byte of 700 into the CHAR variable ccpr1.

Worst of all, the compiler didn't give any warnings that data was being lost.

If you are using the SourceBoost IDE, In Menu Settings->Options->Compile Options Did you have in "All Warnings" radio button selected ?

If you are using MPLAB, did you have "All Warinings" selected, or us compiler command line option -W2?

 

Regards

Dave

Share this post


Link to post
Share on other sites

ccpr1 is defined as char for backward compatibility with other PIC types that have this register one byte long. Same approach is used for all other registers in system headers. To access 16 bit register two other variables are defined just after ccpr1. These are ccpr1l and ccpr1h that are mapped to low and high byte of the register and these are the ones you need to use.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Hi Larry,

 

If the registers are consecutive in memory address, and little endian, try using this to declare 16 bit registers.

 

volatile unsigned int ccpr1_16@CCPR1;

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Thanks for the "All Warnings" tip. I'll check that out. Using SourceBoost IDE.

 

I don't understand the comment about "other pics". This is the header file for an 18F2620. I don't see why the header file for a specific processor should be influenced by what another processor has. Same for all the 16 bit registers.

 

I was able to get around it, but I really don't see why every user that wants to use one of the 16 bit registers has to treat them as two 8 bit registers, or define his own variable.

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×