Let's Make Robots!

The new Picaxe bug?

Consider this test code for Picaxe.

#picaxe40x2
#no_data
high 5
for w0 = 1 to 65535 next w0
high 6
for w0 = 0 to 65535 next w0
high 7

Please feed it to your Picaxe, whatever breed. Change the directive #picaxe.... accordingly or remove it. The directive #no_data just speeds up the program load.

Now tell me, how long does it take for the ports to go high (for the LEDs to light up)?

Here are my results.
picaxe 40x2 (firmware B.0): 5 immediately, 6 after about 57 seconds, pin 7 never went high
picaxe 28x1 (firmware A.3): 5 immediately, 6 after about 80 seconds, pin 7 never went high

What is going on here? The for...next that starts at 1 has no problem, the for...next that starts at zero never completes?!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

You can make use of this "bug". if you want to assign 65535 to w0: write it like this:

 let w0=-1

 Means the same thing and it shaves 1 (sometimes 2??) bytes of your program. 

I don't know picaxe from shinola but how about this.

 

per the data sheet "When the end value is exceeded the looping stops".

I take this to mean that the value is tested after it's incremented. But 65535 plus one would leave 0 in the register, which is "start" again. Just a thought.

I take "exceed" to mean "be greater than". For the looping to stop, the var must be outside the specified range. Manual could be clearer.
I had considered that that was a possibility. If so then the manual needs updating to specify that 0 cannot be used as a start variable.
start var can be a 0, as long as the end value is below 65535

It kind'a depends how the value is being tested. Or maybe you just can't have a range greater then 65535 (1-65535 or 0-65534 or 32767-32765).

 

By the way, two thumbs up on Odd's Next Big Adventure!

Yep, I just confirmed. This is an overflow issue. The word value (16 bits) overflows from
11111111.11111111
to
00000000.00000000
when you increment 65535. This much was predicted by me.

But the test in the for/next loop caught me off guard. I expected this loop:
for w0 = 0 to 7
   print w0   '   print does not exist, I'm using sertxd
next
print w0

to print the numbers 0, 1, 2, 3, 4, 5, 6, 7, 8. And it does.

The increment of w0 takes place just before "next w0". Then, "next" evaluates the new value. The escape from the loop can only happen when w0 is outside the range "X to Y" in the "for" statement.

I expected it to escape when w0 is higher than the second value. Not the whole truth. I proved this with a range from 65530 to 65535. That loop escapes just right.

Higher than 65535 just ain't gonna happen in a word value. Also it can not go below zero. The frustrating thing is, this is not a problem for a loop in a byte value (8 bits).

for b5 = 0 to 255
   print b5
next
print b5
works just fine. Printing 0 through 255 (inclusive), then 0 again. Without overflowing a bit into the next byte (b6).

Just curious,

for w0= 0 to 65535 step 1 next w0

and try 

for w0= 0 to 65534 step 1 next w0

Adding "step 1" makes no difference. A step value of 32768 greatly speeds up testing though.