When you simulate the above code, the values of bit0 and b1 will change depending on what assign statement is being executed.
That is correct but I'm not sure I'm understanding what you perceive to be the problem or in which statements.
I like to name my inputs, but using 'symbol Name1 = C.5' doesn't work properly if you then want to use 'b1=Name1' (but it is exactly what you need if you want to 'readadc Name1,b0').
This a feature of the READADC ( and TOUCH ) commands. They work with 'analogue channel numbers'. In the past there has been correlation between pin number and channel number but with later PICAXE this is lost.
PICAXE firmware expects to see channel number specified in the READADC command, but users often want to use pin names, eg READADC B.0, READADC B.1 and READADC B.2 rather than READADC 1, READADC 2 and READADC 4 for the 20X2 ( note the awkward differences and non-consecutiveness ).
Within the compiler pins B.0-B.7 and C.0-C.7 will be numbered something like 0-7, 8-15, and are effectively hidden symbol definitions for numeric values. The PICAXE is still using pin numbers internally but the complexity of all this is hidden from the user.
When a pin name is re-symboled it simply gets the same numeric definition as the original pin and for most commands and circumstances this is absolutely fine. For READADC and TOUCH there's an issue; the numbers allocated as pins 0-7 and 8-15 don't match 'analogue channel numbers' as allocated by Microchip.
The compiler therefore 'gets smart' when it sees READADC B.2 and translates that B.2 to it's internal pin number, say 22, then to the analogue channel number 4 which it knows is on that pin. So it's the same as having written READADC 4 which is what you wanted.
However, if you had -
Symbol N = 22
ReadAdc N, b0
It would read analogue channel 22 rather than channel 4. That's probably as you expected, but did not recognise that -
Symbol N = B.2
ReadAdc N, b0
Is exactly the same; the B.2 having been converted to the number 22.
The compiler can only 'get smart' when it sees a pin name specified within the command ( eg READADC B.2 ) and when an analogue channel number is specified it uses it as is. Thus -
ReadAdc B.2, b0 --> ReadAdc 4, b0
Symbol N = B.2
ReadAdc N, b0 --> ReadAdc 22, b0
In the past (prior to the port.pin convention) I think this always caused a syntax error (such as '5' vs. 'pin5'), and I dealt with it. This time, there is no syntax error in the code above...but it won't return the results that you expect.
The compiler still checks for where a pin variable is used when it is likely that a pin number should be specified, for example "HIGH pinC.0", "COUNT pinC.0, 1, w0" and "READADC pinC.5, b0".
It seems that the compiler shouldn't need to interpret 'b1=C.5' as anything other than 'b1=pinC.5' or am I missing something? Or could it at least generate a syntax error?
b1=C.5 is considerably different to b1=pinC.5, and that's the case as it always has been with pin numbers pre port.pin format. Both are legitimate and neither would be syntax errors.
The problem here seems to be the analogue channel mapping rather than anything else -
ReadAdc B.2, b0
is not the same as -
Symbol N = B.2
ReadAdc N, b0
