lhbradley 0 Posted January 20, 2013 Report Share Posted January 20, 2013 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 Quote Link to post Share on other sites
Dave 0 Posted January 20, 2013 Report Share Posted January 20, 2013 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 Quote Link to post Share on other sites
Pavel 0 Posted January 20, 2013 Report Share Posted January 20, 2013 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 Quote Link to post Share on other sites
Reynard 0 Posted January 21, 2013 Report Share Posted January 21, 2013 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 Quote Link to post Share on other sites
lhbradley 0 Posted January 26, 2013 Author Report Share Posted January 26, 2013 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. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.