hippy
Ex-Staff (retired)
Programming Editor 4.0.10 and probably earlier.
The following code compiles fine on the PICAXE-28, 28A, 28X and 40X but not on the 18, 18A and 18X ...
- LET pin3 = 1
- LET pin4 = 1
- LET pin5 = 1
Likewise, the following fails on the 18's ...
- SYMBOL LED_3_OUTPUT_PIN = pin3
- SYMBOL LED_4_OUTPUT_PIN = pin4
- SYMBOL LED_5_OUTPUT_PIN = pin5
The 'Unknown Symbol' error would be correct were 'pinX' to refer to an input ( those pins don't exist ) but they do exist as output pins.
Compiling for an 08 or 08M, gives the same problem with pin0 ...
- SYMBOL LED_OUTPUT_PIN = pin0
but rather annoyingly lets the following and similar 'pin3' mistakes through ...
- LET pin3 = 1 ' pin3 is input only !
Although a workround for the 18's is to use explicit HIGH and LOW statements, it means that hardware abstraction such as ...
- SYMBOL LED_OUTPUT_PIN = pin1
- LET LED_OUTPUT_PIN = 1
can't be easily ported from a 28 series to an 18 or 08, and stops working on the 18 and 08 series when changing the code to use one of the pins which throws an 'Unknown Symbol' error.
The 'brute force' removal of the 'pinX' variables from the pre-defined symbol table when the corresponding Input Pin doesn't exist seems to be the cause of the problem; the check in SYMBOL is premature, the checking should be done in the statements using teh vraibles, and the compilation pass or fail should depend on whether a 'pinX' variable is being read from or written to.
Edited by - hippy on 5/6/2004 5:07:37 PM
The following code compiles fine on the PICAXE-28, 28A, 28X and 40X but not on the 18, 18A and 18X ...
- LET pin3 = 1
- LET pin4 = 1
- LET pin5 = 1
Likewise, the following fails on the 18's ...
- SYMBOL LED_3_OUTPUT_PIN = pin3
- SYMBOL LED_4_OUTPUT_PIN = pin4
- SYMBOL LED_5_OUTPUT_PIN = pin5
The 'Unknown Symbol' error would be correct were 'pinX' to refer to an input ( those pins don't exist ) but they do exist as output pins.
Compiling for an 08 or 08M, gives the same problem with pin0 ...
- SYMBOL LED_OUTPUT_PIN = pin0
but rather annoyingly lets the following and similar 'pin3' mistakes through ...
- LET pin3 = 1 ' pin3 is input only !
Although a workround for the 18's is to use explicit HIGH and LOW statements, it means that hardware abstraction such as ...
- SYMBOL LED_OUTPUT_PIN = pin1
- LET LED_OUTPUT_PIN = 1
can't be easily ported from a 28 series to an 18 or 08, and stops working on the 18 and 08 series when changing the code to use one of the pins which throws an 'Unknown Symbol' error.
The 'brute force' removal of the 'pinX' variables from the pre-defined symbol table when the corresponding Input Pin doesn't exist seems to be the cause of the problem; the check in SYMBOL is premature, the checking should be done in the statements using teh vraibles, and the compilation pass or fail should depend on whether a 'pinX' variable is being read from or written to.
Edited by - hippy on 5/6/2004 5:07:37 PM