lhbradley replied to lhbradley's topic in Enhancement RequestsThanks 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.
lhbradley posted a topic in Enhancement RequestsI'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