Shop Learn P1 Docs P2 Docs
Code works with PNut & FlexProp, but not Prop Tool. How possible? — Parallax Forums

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

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...

Comments

  • RaymanRayman Posts: 12,734

    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...

  • @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.

  • evanhevanh Posts: 13,424

    @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?

  • 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

  • AribaAriba Posts: 2,590

    @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

  • RaymanRayman Posts: 12,734

    Thanks! I bet that is the issue...

  • RaymanRayman Posts: 12,734

    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.

  • JonnyMacJonnyMac Posts: 8,163
    edited 2022-07-23 22:52

    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.

  • RaymanRayman Posts: 12,734

    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

  • JonnyMacJonnyMac Posts: 8,163
    edited 2022-07-23 22:53

    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)Phil Pilgrim (PhiPi) Posts: 23,347
    edited 2022-07-24 02:39

    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

  • @"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.

  • evanhevanh Posts: 13,424

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

  • 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

  • evanhevanh Posts: 13,424

    GOTO ain't so bad.

Sign In or Register to comment.