Code works with PNut & FlexProp, but not Prop Tool. How possible?

Rayman

Trying to figure out why this FSRW (uSD reading code) won't work with Prop Tool.

It works with PNut V34Z and FlexSpin 5.9.12.
Doesn't work with Propeller Tool 2.7.0.

Don't expect anybody to figure out this code...
Just wondering how this could be possible.
I thought Prop Tool used same source as PNut...

Rayman

Just in case somebody does want to look...
Test setup is P2 Eval board with uSD that has bitmap2.bmp on it and VGA output with A/V on P0 basepin.

Program is supposed to load and display bird image from SD card.

I've commented out serial output and added some debug lines instead.

Problem seems to be in popen() where it searches the directory for the given filename.
It is not finding the file with Prop Tool and the filenames if finds look messed up.

This happens with both versions of the low level driver (assembly and bit-bashed).
So, I'm leaning toward thinking it is something in the popen() function and not the low level driver, but not 100% on that yet...

Francis Bauer

@Rayman said:
Trying to figure out why this FSRW (uSD reading code) won't work with Prop Tool.

It works with PNut V34Z and FlexSpin 5.9.12.
Doesn't work with Propeller Tool 2.7.0.

Don't expect anybody to figure out this code...
Just wondering how this could be possible.
I thought Prop Tool used same source as PNut...

Is there a reason you are using such an old version of PNut? The latest is V35S, which is probably closer to what Prop Tool 2.7.0 is using.

evanh

@Rayman said:
Trying to figure out why this FSRW (uSD reading code) won't work with Prop Tool.

It works with PNut V34Z and FlexSpin 5.9.12.
Doesn't work with Propeller Tool 2.7.0.

It compiles without errors in all three. What problem are we looking for?

Wuerfel_21

Could it be the loop end value issue? New spin2 interpreter leaves loop variables at the end value, old interpreter and flexspin leave it one step past the end value

Ariba

@Wuerfel_21 said:
Could it be the loop end value issue? New spin2 interpreter leaves loop variables at the end value, old interpreter and flexspin leave it one step past the end value

Yes, I also think that's the issue. I reported it here:
https://forums.parallax.com/discussion/comment/1532499/#Comment_1532499

Depending on the version of PNUT and PropTool the value of the variable in a REPEAT FROM TO is one higher than the end value, or equal to the end value!
I hope Chip has changed it back in newer versions.

Andy

Rayman

Thanks! I bet that is the issue...

Rayman

BTW: The problem is with opening a file. The loops that scan the FAT don't work with Prop Tool and gets stuck in endless loop.

JonnyMac

I hope Chip has changed it back in newer versions.

I have a slightly newer than public release of PNut and Propeller Tool 2.7.0. Both leave the loop control variable at the end limit value.

In the P1, though, the value of the loop control variable is the end value + step (as Andy indicated). I'm with Andy and others: this is the way it should work, and I hope @cgracey will put it back.

Rayman

Ok, took me a while to circle back to this, but think I found the problem with the help here...

replaced:

      repeat i from 0 to 10
         if (padname[i] <> byte[s][i])
            quit

with this:

      repeat i from 0 to 11
         if i==11
          quit
         if (padname[i] <> byte[s][i])
            quit

And it seems to work now. Have to test a bit more to know for sure it's fixed
This issue there is that the next line tests if i==11 to know that filename is a match:
if (i == 11 and 0 == (byte[s][$0b] & $18)) ' this always returns

JonnyMac

I was speaking with Chip today and brought this up. I think he's going to change it back (to the way it is in the P1). Your new code will work in either case, but we won't trip over this when porting code that checks the loop value after the loop runs.

Phil Pilgrim (PhiPi)

IMO, the value of a loop variable after a completed loop should be treated as undefined. IOW, when writing code, it's bad practice to depend upon it to have any particular value. It's out of scope at that point, and the docs should say so.

-Phil

Electrodude

@"Phil Pilgrim (PhiPi)" said:
IMO, the value of a loop variable after a completed loop should be treated as undefined. IOW, when writing code, it's bad practice to depend upon it to have any particular value. It's out of scope at that point, and the docs should say so.

-Phil

But it's not out of scope at that point - all locals in Spin are scoped to the whole method. If it were actually out of scope at that point, it wouldn't be possible to refer to it anymore, as is the case in C.

evanh

It's in scope for C, and all languages I know of.

Phil Pilgrim (PhiPi)

But it's not out of scope at that point - all locals in Spin are scoped to the whole method.

Yeah, yeah, whatever. Okay, not technically out of scope, but out of scope as far as any assumptions about its value are concerned. A loop variable, regardless of "scoping" should only be considered defined inside its loop. Outside, anything goes, and it's bad practice to assume otherwise, regardless of what language you're using.

-Phil

evanh

GOTO ain't so bad.