1.76 milliseconds and the corrected
HI-TECH PICC-Lite version only took
1.3 milliseconds.
This was a good lesson for me to
have extra eyes review my code
before releasing articles in the future,
and I promise to do that. It also taught
me something I never really thought
of prior to this. Declaring the correct
size variables can have a huge impact
on the processing time of your code.
I remember many times when I
wanted to create a variable that would
contain values only slightly larger than
255. I would declare a 16 bit value or a
word variable in PICBasic Pro. Now I
see how this cost me significant processing time. To understand exactly
how much it cost me, I re-ran the
PICBasic Pro code with a 16 bit
“word” variable declared. It was a
lot slower than the C program with
the “int” variable. PICBasic Pro took
2. 6 milliseconds with a 20 MHz resonator and 13.1 milliseconds with a
4 MHz resonator. The PICC-Lite
compiler took 720 microseconds at
20 MHz and 3. 6 milliseconds at 4
MHz. It’s very clear by looking at
this the PICC-Lite compiler handles
16 bit math much more efficiently
than the PICBasic Pro.
All this speed comparing
between these two fine compilers is
relative, though, because — despite
this 16 bit variable slowdown —
PICBasic Pro with a 16 bit variable
declared and running at 4 MHz was
still faster than the PICBasic standard
version — even with the variable still
set as a byte (reference Table 1 from
April). I’m often asked, “Why should
someone spend a couple of hundred dollars for the PICBasic Pro
compiler when they can program
with a cheaper option?” This is
clearly one of the reasons.
In many projects, high speeds }
won’t matter. But in cases where it
does, it’s good to know the limits —
especially if your program has lots
of math equations. Those applications may be the time where you
use a byte variable for the low
byte, and then have a second byte
variable for the high byte, followed
by a check to see whether the low
byte overflowed before updating
}
the high byte. This would save
processing time, since you are
working with byte-sized variables.
OTHER COMPILER
CHOICES
Another batch of comments came
from people curious about other compilers, such as Crownhill Associates’
Proton Basic compiler. I’ve tried it in
the past and remember it using a slightly different setup than Parallax’s BASIC
Stamp PBASIC style, which the test
program was based on. I decided to try
Proton on this speed-test code. I downloaded the sample version of Proton to
see if it supported the same chips I
used. The sample version doesn’t support the PIC16F876A or PIC16F877A,
but did support the PIC16F877. I dug
around and found one of those older
chips, so I was able to run it. I was
pleasantly surprised to find the same
speedtest.bas program compiled in
Proton, but I got a few warnings.
Proton prefers you to use the DIM
instead of VAR directive for creating
variables, and it uses a different
command than PAUSE for delays. The
compiler did compile it, though, and
LISTING 1
#include <pic.h>
// Include HITECH CC header file
void Pause( unsigned int usvalue );
void msecbase( void );
//Establish pause routine function
//Establish millisecond base function
main()
{PORTB = 0;
TRISB = 0;
//Clear PortC port
//All PortC I/O outputs
while(1)
{//loop forever
unsigned int z, y;
RB0 = 1;
for(z=0; z<255; z=z+1)
y=y+1;// Turn on RC0 LED
RB0 = 0;
Pause(10);
// Turn off RC0 LED
// Pause 10 msec
} //End while
} //end main
//*******************************************************
//pause - multiple millisecond delay routine
//*******************************************************
void Pause( unsigned int usvalue )
{
unsigned char x;for (x=0; x<usvalue; x++)
msecbase();// Delay usvalue in milliseconds
// Millisec delay routine
//*******************************************************
//msecbase - 1 msec pause routine
//*******************************************************
void msecbase(void)
{OPTION = 0b00000001;
TMR0 = 0xd;
while(!T0IF);
T0IF = 0;
//Set prescaler to TMRO 1:4
//Preset TMRO to overflow on 250 counts
//Stay until TMRO overflow flag equals 1
//Clear the TMR0 overflow flag
June 2007 17
