Grich RC PICC Compiler

copyright, Peter H. Anderson, Baltimore, MD, Feb, '99


I received the Grich compiler today (Feb 17, '99).

At $59, it is considerably more practical for the hobbyist than other PIC C compilers. I have only looked at it for a few hours, but I am impressed. Indeed, in some respects I regard it as superior to the High-Tech $850 compiler.

Some Initial Impressions.

The package consists of a single disk with no printed documentation. Documentation consists of a 38K README.TXT file and a few examples.

There is no library. At first, this bothered me, but then again, are such functions as strcpy, strcat, toupper really all that important. Certainly, one can write their own "library" in the form of functions.

Only a single file can be generated. That is, projects are not supported. However, one can easily cut and paste routines as needed into the main file. A nice feature is that if a function is not used, it is not compiled. Thus, the user might have a nu mber of useful "libraries" and simply paste them into the main program without having to cut out routines which are not used in that specific program.

The compiler generates only .asm and .hex files. With the High Tech compiler, we compile and then download the .cod file to an ICEPIC emulator and this is not possible with the Grich package as there is no .cod file. However, most hobbists do not have an $800 emulator. For those who do, it is a simple matter to bring the .asm file into ICEPIC and with a minimum of editing, assemble it and download to the emulator.

For hobbyists not having an emulator, the .asm file may be brought into Micrchip's MPLAB. Of course, one is them debugging at the assembly level, but frankly, I prefer doing this. Or, the hobbyist might simple use the .hex file to burn the 16F84 and giv e it a try.

Floating point is not supported. But, for BASIC Stamp enthusiasts and those familiar with the MELabs package, this is not a serious problem. Most problems can be solved without resorting to floating point routines.

The compiler is limited to the Microchip 14-bit core devices. Thus, the PIC12C508 and 509 devices are not supported. But, most hoyyists use the PIC16F84 which is supported. If you absolutely need an 8-pin DIP, you might fully debug using the PIC16F84 a nd then revise your code for the 12C671 or 672 which is also supported.

All and all, there are deficiencies. But, for the hobbyist, none of these may be any too serious.

The beauty of the package is its simplicity. I feel in control of what I am doing.

The following is an implementation of a simple program which reads RA.0 and continually provides either an advancing or declining bar graph implemented with eight LEDs on PORTB.

// Program BAR.C 
// Reads RA.0 and causes bar graph to either move up or down. 
// copyright, Peter H. Anderson, Baltimore, MD, Feb, '99

#pragma PROC_CODE_WORD_VAL 0x19	// CP=0, PWRTE = 1, WDTE=0, OSC=XT
#pragma PROC_ID_VAL 0x01 0x02 0x03 0x04

#include "16F84.h"

#define TRUE 	!0
#define FALSE	0

int porta @ 0x5;
int portb @ 0x6;

int trisa @ 0x85;
int trisb @ 0x86;

long t;
   unsigned int d;

   while( t ) 
      for(d = 0 ; d < 255 ; d++ );

   char *patt;	// pointer to a ROM array 
   int n;

   patt = "\x00\x01\x03\x07\x0f\x1f\x3f\x7f\xff";
   trisb = 0x00;	// portb are outputs
   trisa = 0x1f;	

          for(n=0; n<8; n++)
             portb=@(patt + n);
          for(n=7; n>=0; n--)
             portb=@(patt + n);
   }	// end of while

Prototypes are not supported.

Note that the 16F84.H include file does not define all of the registers and bits within the register and thus in the above, the addresses of TRISA, TRISB, PORTA and PORTB are defined. I plan to develop a standard header file which includes all of this.

The above uses a lookup table which is implemented in program memory by declaring a pointer to type char. This is then initialized;

	patt = "\x00\x01\x03\x07\x0f\x1f\x3f\x7f\xff";
Normally, an array element is refered to as;
However, another implementation is;
where patt is the address of the beginning of the array and *(patt+n) means the value at address patt+n

Grich uses @(patt+n) to distinguish between arrays which are implemented in ROM from those implemented in EEPROM.


My initial impression of the Grich PICC Compiler is quite postive. Admittedly, there are shortcomings, but I don't view these as too serious for a hobbyist.

If you would like me to develop additional sample routines, please let me know via e-mail. Such feedback is useful as I don't like to spend time on things which are of little interest.

Happy Tinkering!