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

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

RaymanRayman Posts: 13,860
in Propeller 2

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: 13,860

    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 BauerFrancis Bauer Posts: 353

    @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: 15,187

    @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_21Wuerfel_21 Posts: 4,461

    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,682

    @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: 13,860

    Thanks! I bet that is the issue...

  • RaymanRayman Posts: 13,860

    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,923
    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: 13,860

    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,923
    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,514
    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

  • ElectrodudeElectrodude Posts: 1,621

    @"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: 15,187

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

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514

    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: 15,187

    GOTO ain't so bad.

Sign In or Register to comment.