220.127.116.11 THE TRIS INSTRUCTIONS
Some PIC devices use a TRIS instruction to load the TRIS register. The <htc.h> header file will ensure a special definition for a C object called TRIS. PICC will automatically use the TRIS instruction when an appropriate processor is selected and the TRIS register is accessed.
For example, to make all the bits on the output port high impedance, the following code can be used.
TRIS = 0xFF;
This will load the appropriate value into the W register and then call the TRIS instruction.
Those PIC devices which have more than one output port may have definitions for objects: TRISA, TRISB and TRISC, depending on the exact number of ports available. This objects are used in the same manner as described above.
Given that last paragraph I changed TRIS to TRISIO, TRISA, TRISB, and TRISC. Still got the same error. I also changed the numerical values to decimal and hex. I even closed MPLAB and opened it again. None of these licked the problem. Finally since I have v9.80 installed I tried that to compile the program.
Lo and behold! The error message disappeared. When I opened the include file for the 10F22x for v.9.80 I found out that TRIS and TRISIO are defined therein, but they aren't in the 10F222 include file for v.9.81. Oddly though, while OPTION is defined in v.9.80 and isn't in v9.81, the latter nevertheless understood that command and correctly compiled it.
So there. That's a bug in version 9.81.
Having opened the include files for both versions, I was vexed to find out that there are a number of differences in the defines. For instance for the configuration bits, v9.80 lists the following:
// Configuration Mask Definitions /* Internal oscillator frequency select */ #define OSC_8MHZ 0xFFF // internal osc is 8MHz #define OSC_4MHZ 0xFFE // internal osc is 4MHz /* Master clear pullup enable */ #define MCPUEN 0xFFD // pullup enable #define MCPUDIS 0xFFF // pullup disable /*watchdog*/ #define WDTEN 0xFFF // watchdog timer enable #define WDTDIS 0xFFB // watchdog timer disable /* code protection */ #define PROTECT 0xFF7 // protect the program code #define UNPROTECT 0xFFF // do not protect the program code /* MCLR Pin function */ #define MCLREN 0xFFF // master clear reset enable #define MCLRDIS 0xFEF // master clear reset disable
while v9.81 has these:
// // Configuration mask definitions // // Config Register: CONFIG #define CONFIG 0x0FFF // Internal Oscillator Frequency Select bit // 8 MHz #define IOSCFS_8MHZ 0xFFFF // 4 MHz #define IOSCFS_4MHZ 0xFFFE // Master Clear Pull-up Enable bit // Pull-up disabled #define MCPU_OFF 0xFFFF // Pull-up enabled #define MCPU_ON 0xFFFD // Watchdog Timer Enable bit // WDT enabled #define WDT_ON 0xFFFF // WDT disabled #define WDT_OFF 0xFFFB // Code protection bit // Code protection off #define CP_OFF 0xFFFF // Code protection on #define CP_ON 0xFFF7 // GP3/MCLR Pin Function Select bit // GP3/MCLR pin function is MCLR #define MCLRE_ON 0xFFFF // GP3/MCLR pin function is digital I/O, MCLR internally tied to VDD #define MCLRE_OFF 0xFFEF
None of the bit names are the same!
Since I'm using the ADC, the line "GO_nDONE = 1"--which is perfectly fine in v9.81--was flagged as an error in v9.80 because it only recognizes "GODONE." Now try compiling "GODONE = 1" in v9.81. What do you think will happen? You guessed it. You get a build fail.
For who knows what reason, Microchip not only demands we have a photographic memory to remember all those changing (or alternate) defines, it's also made it a hair-tearing ordeal to port firmware from one compiler version to the next. This is yet another reason I really would rather stick to mikroC if not for the fact that mikro doesn't support the baseline PICs and has a 2K code limit.