4.0.10 Bug with pin3 etc

[hippy]

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

 

[Technical]

This is not a bug and is by deliberate design.

pin3 etc variables are only designed to be used with input if...then statements, and are only therefore pre-defined on valid input pins. Although the syntax you are trying to do does work with some outputs, it is fairly abstract, as it is more efficent, and simpler, to use high and low commands.

The line
let pin3 = 1

should be simply entered as
high 3

when talking about output 3.

Or, using symbols

symbol output_led = 3
high output_led

If we did what you suggest the compiler would accept, for instance, statements such as

if pin3 =1 then...

on 18 pin PICAXE, which is nonsense as input 3 does not exist. We would then get complaints the other way around... unfortunately you can't please everyone all the time!

Edited by - Technical on 5/13/2004 8:56:04 AM

 

[hippy]

I wasn't suggesting that the compiler should allow the use of non-existant pins for input ( eg 'if pin3 = 1 then' on am 18 ), but to check whether any 'pinX' variable was valid where it is used, be it to refer to an input or output.

If allowing the use the non-existant 'pin3' for input is 'nonsense' ( and it is ), then so too is the compiler allowing the non-existant output 'pin3' to be used for output on the 08, which it does allow.

 

[Technical]

Any pre-declared variable can be used anywhere within a program. Therefore we do not intend to change the functionality of the software at present by pre-declaring non existant input pins.

What you are trying to do can be overcome by use of high and low commands instead.

 

[hippy]

But non-existant output pin variables are pre-declared ;-) I won't labour the point though, as we obviously have a different perspective.

The problem I have been thrown was checking, and now making, a suite of programs run on any PICAXE variant with only the SYMBOL definitions needing to be changed to work. The idea is to have just one program which will run on any PICAXE, using any output pins with some very minor definition changes.

The root problem is that the code uses, entirely validly on the 28-series, code such as ...

- SYMBOL OUTPUT_PIN = pin3
- OUTPUT_PIN = b0

To use HIGH/LOW, changing SYMBOLs is easy, but changing all the assignments means, for each, having to do ...

- IF b0 = 1 THEN Output1
- Output0:
- LOW OUTPUT_PIN
- GOTO OutputDone
- Output1:
- HIGH OUTPUT_PIN
- OutputDone:

Six extra bytes per assignment ( a 300% increase in code size ), and about four times slower.

It's not possible to predict 'b0' before the assignment as that data is computed / extracted from EEPROM.

The annoying thing is that while a 'LET pin0=b0' doesn't need to change, a 'LET pin3=b0' does. But because I don't know in advance which pin 'OUTPUT_PIN' will be, or the target PICAXE, all assignments have to be expanded to the verbose code or it fails should OUTPUT_PIN ever be one which doesn't compile. Of course, for all the other cases which do work, this is an unnecessary expansion of code that wastes precious code space and execution time.

The code works fine as it is on the 28-series, but fails to compile on an 18 for no other reason than it has three missing input pins ;-)

Although it would appear possible to produce multiple versions of the software targeted at each PICAXE, every variant would need this verbose code or there will be major discrepencies in timing depending upon which PICAXE and which Output Pins are used.

This, with the changed ( and now less predictable ) timing, of course has knock-on effects right back to the funadamental design ( out of my hands ), and program space limits loom as a problem, along with the four-deep stack.

The pragmatic solution, which involves no change at all, is to say they can't use Output Pins 3, 4 or 5 or on an 18, or Output Pin 0 on an 08, but I have no retort to the comment that, "That is ridiculous !". Having suggested the PICAXE in the first place, I've got some egg dripping from my chin :-(

 

[hippy]

A lateral thought which should make it work on the 08, 08M, 18 and 18A if not the 18X which are unlikely to be used anyway ...

Ignoring the difficulty of actually doing this - If I compile with 'LET pin7=b0', find where the token that specifies the 'pin7' variable is, can I WRITE a 'pin3' variable token over the top of it at runtime to create a 'LET pin3=b0' ?

The question really is, will the Firmware handle a 'pin3' assignment, and is it just the compiler's lack of pre-declared variable stopping the compilation ?

<i>And the answer after trying an 18 is ... </i> No, it doesn't appear to work :-(

Edited by - hippy on 5/13/2004 6:56:41 PM