Updates

If you have an AWC product, this is the place to check for important updates, manual changes, and tips.

APP IV

If you use the APP-IV, be sure to download the updated headers that corrects a small error in the IREAD macro.

All PAKs

You can now find selected manuals online in PDF format!
PAK-I PAK-II PAK-III PAK-IV PAK-V PAK-VI PAK-VII PAK-VIII PAK-IX PAK-X
If you are trying to interface a PAK to something other than a Stamp, check out our example code:
PIC Scenix SX 68HC11, AVR, BX24
The PAK-I, II, III, IV, and IX will execute a hardware reset if the clock line stays high for more than 2400 milliseconds.
The PAK-V, the PAK-VI, the PAK-X, XI, and XII use ordinary RS232 protocol. The other PAK devices use a proprietary synchronous protocol explained in the manuals. The maximum speed depends on the speed you are operating the PAK. For 10MHz PAKs, the data clock frequency should be 50KHz or less. For 20MHz PAKs, the maximum speed is about 100KHz. You should also provide a small delay between bytes if the PAK is operating near the upper limit of its communications speed. For reference, the Stamp II's SHIFTOUT command (which works fine with the PAKs) uses a 16 KHz clock and the Stamp IISX uses 42KHz.
Bypass capacitors (.1uF between Vdd and Vss near the chip body) are a good idea for all chips, not just the PAK.

All 50MHz PAKs

Some of the PAKs have enable or option pins that you can leave floating. However, noise from the oscillator can drive these pins and overpower the built-in pull up resistors. This can cause the PAK to appear to not work because it is disabled or an option is set incorrectly. The solution is simple: don't let the pins float. On a PAK-V, for example, for greatest reliability, tie the Enable, RXINV, and B9600 pins high or low (if you are not driving them with a CPU output). Don't just let them float.
One cause of problems with 50MHz PAKs is failure to achieve oscillation. Remember, a 50MHz oscillator must have short leads, and low stray inductance and capacitance. If you have problems making the oscillator start, you might try a 10K resistor across the two outer leads of the resonator. A small capacitor (10-20pF) from one or both resonator leads may also help in some cases.
Sometimes, failure to reset can be a problem. Try placing a 10K pull up resistor on the RESET pin and then manually (or automatically) ground it for a bit before your program tries to access the PAK. If this solves your problem, you are having a power up reset problem. The PAK requires a fast Vdd ramp up. If your power supply rises slowly, or is noisy, you may have this problem. Try connecting an RC reset circuit or connecting the PAK's reset to the Stamp's RESET pin.

Serial PAKs (PAK-V, PAK-VI)

The examples in the manual are for the BS2. Remember the BS2SX and the BS2P have different baud rate constants. If you are using 84 or 84+$4000 as a baud rate constant, and you are using anything other than a BS2, you are at the wrong baud rate!

GP-3

There is an updated GP3.OCX that fixes rare problems where errors occur at startup causing false readings on your first command. Either download the new core setup or replace your existing GP3.OCX file. As of March 3rd, these files now include release 1.4 of both the OCX and the AWCGP3DLL.DLL file. These new versions support the a2dconf command that allows you to set a different voltage reference. Note that you must have a GP3 produced after March 1, 2004 for this command to have any effect. However, you can use the new library (without calling a2dconf) with older firmware.

PAK-I

Early versions of the PAK-I manual omitted an important note about the DIGIT command:

The DIGIT command uses a preprogrammed algorithm to extract digits from numbers. Part of this algorithm involves converting the number to a 24-bit integer and back. Therefore, the DIGIT command may produce errors (or even fail to converge) on large numbers whose integer representations exceed 24-bits during this process. This does not affect the basic accuracy of the device (which you can verify by reading the hex representation of the floating point number). This is only a problem when working with very large numbers. If you plan on working with large numbers, or using many significant digits, you may want to consider reading the number in hex and converting to ASCII in your own program.

Another problem with early PAK-I devices is that only a hardware reset would clear bits in the error status word. This did not affect calculations that were not in error, but it makes it difficult to tell why a calculation failed because all errors that ever occurred were returned for each error. If you don't have a connection to the hardware reset line, you can force a hardware reset by holding the clock line high for 2400 milliseconds. PAK-Is that return $22 as their version number reset the error code each time. All PAK-IIs exhibit the newer behavior.

PAK-II

Note that PORT B pins are Schmitt triggers when used as inputs.
Some PAK-IIs return incorrect results for the following computations:

arcsin(0)
arcsin(-1)
arccos(-1)

You can test to see if your PAK is affected and either treat these values as a special case or contact us for an upgrade if you use these functions. If you don't use arcsin and arccos, there is no need to update your PAK. PAK-IIs shipped after August 2002 should not have this problem. Earlier PAK-IIs also do not have this problem.
Some versions of the PAK-II (and PAK-IX) BS2 library have incorrect function codes for arcsin, arccos, and arctan. This is not a problem with the PAK, just with the BS2 library code. If you are using this code, look for the following lines and make the corrections indicated:

FArcSin:
fpb=$24
goto fpstats

FArcCos:
fpb=$25
goto fpstats

FArcTan:
fpb=$26
goto fpstats

PAK-IV

Note that PORT B pins are Schmitt triggers when used as inputs.

PAK-V

The PAK-Va is now shipping. These are exactly like the PAK-V but do not require an external resistor for the ceramic resonator. They also have a slightly wider power supply range.

PAK-IX

The PAK-IX BS2 library on early disks has a harmless bug. The original code reads:
' A/D
fa2d:
SHIFTOUT DATAP,CLK,MSBFIRST,[$29,(fpb-1)<<4+fpx] ' a/d
goto fpstats

But should read:
' A/D
fa2d:
SHIFTOUT DATAP,CLK,MSBFIRST,[$29,(fpb-1)<<4+fpx] ' a/d
goto fpstat

This is harmless since it just sends a byte to the PAK that the PAK ignores during the conversion. Still, you should fix your program if it has this typo in it.
The PAK-IX addendum should mention that the COMMCK command returns 0x41.
Older PAK-IXs return incorrect results for the following computations:

arcsin(0)
arcsin(-1)
arccos(-1)

You can test to see if your PAK is affected and either treat these values as a special case or contact us for an upgrade if you use these functions. If you don't use arcsin and arccos, there is no need to update your PAK. PAK-IXs shipped after August 2002 should not have this problem.
Some versions of the PAK-II (and PAK-IX) BS2 library have incorrect function codes for arcsin, arccos, and arctan. This is not a problem with the PAK, just with the BS2 library code. If you are using this code, look for the following lines and make the corrections indicated:

FArcSin:
fpb=$24
goto fpstats

FArcCos:
fpb=$25
goto fpstats

FArcTan:
fpb=$26
goto fpstats

AWC Electronics - Updates