The largest potential problem shared by both library routines and user code is speed. Without the overhead of reading instructions from the EEPROM, many PBC instructions (such as GOTO and GOSUB) execute hundreds of times faster than their BASIC Stamp equivalents. While in many cases this is a benefit, programs whose timing has been developed empirically may experience problems.

The solution is simple - good programs don't rely on statement timing. Whenever possible, a program should use handshaking and other non-temporal synchronization methods. If delays are needed, statements specifically generating delays (PAUSE, NAP or SLEEP) should be used.

Unlike the BASIC Stamp, PBC programs operate directly on the PORT and TRIS registers. While this has speed and RAM/ROM size advantages, there is one potential drawback.

Some of the I/O commands (TOGGLE and PULSOUT) perform read-modify-write operations directly on the PORT register. If two such operations are performed too close together and the output is driving an inductive or capacitive load, it is possible the operation will fail.

Suppose, for example, that a speaker is driven though a 10uF cap (just as with the SOUND command). Also suppose the pin is initially low and the programmer is attempting to generate a pulse using TOGGLE statements. The first command reads the pin's low level and outputs its complement. The output driver (which is now high) begins to charge the cap. If the second operation is performed too quickly, it still reads the pin's level as low, even though the output driver is high. As such, the second operation will also drive the pin high.

In practice, this is not much of a problem. And those commands designed for these types of interfacing (SOUND and POT, for example) have built-in protection. This problem is not specific to PBC programs. This is a common problem for PICmicro (and other microcontroller) programs and is one of the realities of programming hardware directly.

Since PBC generated programs run directly on a PICmicro MCU, there is no need for the Stamp's PC interface pins (PCO and PCI). The lack of a PC interface does introduce some differences.

Without a PC, there is no place to send debugging information. Thus, while PBC parses PBASIC's DEBUG DEBUG commands, it doesn't generate code.

Without the PC to wake the PICmicro from the END statement, it remains in low power mode until /MCLR is lowered or power is cycled.

PBC's BUTTON command requires the programmer to specify an 8-bit variable to store the current repeat count. The BASIC Stamp will allow the use of any type of variable. Word variables work fine, although they are wasteful. Programs using bit variables for the BUTTON command will compile and run, but the command will not behave correctly. PBC's BUTTON command will also work correctly with word variables. It does, however, generate a compiler error when an attempt is made to use BUTTON with a bit variable.

The faster execution of PBC programs may be a problem for the BUTTON command. The BUTTON command samples the input only once per execution. Debouncing is achieved by the delay introduced by other Stamp overhead (such as fetching instructions from EEPROM). Thus, a BUTTON command which is executed too frequently might not provide as good a "debounce" in PBC programs as it does on the BASIC Stamp.

The PIC16C84 (the default target for PBC programs) and PIC16F83 and 84 have 64 bytes of EEPROM. PBC programs may use this for EEPROM operations and fully supports PBASIC's EEPROM, READ and WRITE commands.

To access off-chip non-volatile data storage, the I2CIN and I2COUT instructions have been added. These instructions allow 2-wire communications with serial EEPROMs like Microchip Technology's 24LC01B.

The Stamp implements subroutines via the GOSUB and RETURN statements. User variable W6 is used by the Stamp as a four nibble stack. Thus, PBASIC programs may have up to 16 GOSUBs and subroutines can be nested up to four levels deep.

The 14-bit core PICmicro MCUs have Call and Return instructions as well as eight level stacks. PBC programs make use of these instructions and use four levels of this stack, with the other four levels being reserved for library routines. Thus, W6 is still available, subroutines may still be nested up to four levels deep and the number of GOSUBs is limited only by the PICmicro MCU's code space.

PBC's RANDOM statement takes any word variable as its parameter. The PBC library routine takes the address of the 16-bit word to randomize as its parameter. Since PBC doesn't implement the PORT register as a true 16-bit memory location, the statement RANDOM PORT will produce a compilation error.

SERIN and SEROUT have been altered to run up to 9600 baud from the previous limit of 2400 baud. This has been accomplished by replacing the little used rate of 600 baud with 9600 baud. Modes of T9600, N9600, OT9600 and ON9600 may now be used.

When the Watchdog Timer time-out wakes a PICmicro from sleep mode, execution resumes without disturbing the state of the I/O pins. For unknown reasons, when the BASIC Stamp resumes execution after a low power instruction (NAP or SLEEP), the I/O pins are disturbed for approximately 18 mSec. PBC programs make use of the PICmicro's I/O coherency. The NAP instruction does not disturb the I/O pins.

Similarly, the Stamp's SLEEP instruction disturbs the I/O pins every WDT time-out period, approximately every 2.3 seconds. PBC's SLEEP instructions only disturbs the I/O pins once every 10 minutes. This is done while recalibrating the period of the WDT.

The Stamp's SLEEP command claims to be ~99.8% accurate. This may be overly optimistic. First, the granularity of the SLEEP command is determined by the Watchdog Timer period, which is typically 2.3 seconds. This introduces an average error of about 1 second. Even without this granularity, SLEEP is only as accurate as the PICmicro MCU's system clock. In the BS1, the oscillator is a resonator, whose accuracy is +/-1%.

Ignoring these effects, there is still the larger problem of variability in the PICmicro MCU's Watchdog Timer. The WDT is driven by an R/C oscillator and the period varies greatly with temperature. Without accounting for this error, the SLEEP command would be worthless.

To eliminate this error, the WDT is calibrated in terms of the system clocks. This is done by counting system clocks while waiting for the WDT to time-out. This calibrated period is then used to decrement the desired sleep period. This keeps SLEEP to within the accuracy of the system clock (ignoring the granularity of the WDT).

PBC's SLEEP command performs this recalibration every 257 cycles or about once every 10 minutes. It recalibrates for a full WDT period (about 2.3 seconds). This results in the PICmicro being active about 0.38% of the time during the SLEEP command. For the PIC16F84 at 4MHz with the WDT enabled, Microchip specifies a typical operating current of 1.8mA and a power down current of 40uA. Using these figures, PBC's SLEEP draws approximately 47uA.

With all the above said, it has been determined that SLEEP may not work properly on all PICmicro MCUs. During SLEEP calibration, the PICmicro MCU is reset. Different devices respond in different ways to this reset. Upon reset, many registers may be altered. Notably the TRIS registers set all the PORT pins to inputs. The TRIS state for PORTB is automatically saved and restored by the SLEEP routine. Any other PORT directions must be reset by the user program after SLEEP. Other registers may also be affected. See the data sheets for a particular part for this information.

To get around potential problems, an uncalibrated version of SLEEP has been added. This version does not cause a device reset so it has no effect on any of the internal registers. All the registers, including PORT direction, remain unchanged during and after a SLEEP instruction. However, actual SLEEP times will no longer be as accurate and will vary dependent on device particulars and temperature. To enable the uncalibrated version of SLEEP add the following lines to a PBC program: