Shop Learn P1 Docs P2 Docs
PNut/Spin2 Latest Version (v35t - New PASM-level debugger, PC_MOUSE now reports pixel color) - Page 47 — Parallax Forums

PNut/Spin2 Latest Version (v35t - New PASM-level debugger, PC_MOUSE now reports pixel color)

14547495051

Comments

  • cgraceycgracey Posts: 13,730

    @mwroberts said:
    @cgracey Mouse feedback in debug is fantastic!!! This allows for a user interface... buttons and sliders and... You should start a new thread so people know about this... When will you release a new pnut with this feature? I imagine it will be a while before it makes it to propeller tool...

    I will add keyboard input today.

    I think we'll get this into Propeller Tool soon.

    Yes, a new thread would be good.

  • AribaAriba Posts: 2,590

    Is the mouse position always sent, or just when something changes. I think the latter safes alot of bandwith.

    Andy

  • cgraceycgracey Posts: 13,730

    @Ariba said:
    Is the mouse position always sent, or just when something changes. I think the latter safes alot of bandwith.

    Andy

    It's a request that must be made using a DEBUG statement. There's no way for the PC to asynchronously send the data and have it update the variables.

  • AribaAriba Posts: 2,590
    edited 2021-12-17 18:32

    Thanks Chip, getting the data only on request is good, so I can decide the sampling rate.

    Something else:
    I find the changed behaviour of the REPEAT FROM TO loops very dangerous. There is existing code that checks if the variable is outside the range to detect that the loop was not early terminated with quit. For example this snippet from the FSRW driver (SD card driver) that compares the filename:

          repeat i from 0 to 10
             if (padname[i] <> byte[s+i])
                quit
          if (i == 11 and 0 == (byte[s][$0b] & $18))
             ...
    

    With the variable limited to the range, this does not work anymore, but the error is hard to find, because there is no error stated, and it works in many cases, but not in all.
    Took me quite some time to find the reason why the FSRW not works correctly with the new PNUT version.
    Now I've changed it to:

          repeat i from 0 to 11
             if (padname[i] <> byte[s+i]) and i < 11
                quit
          if (i >= 11 and 0 == (byte[s][$0b] & $18))
    

    but that is ugly and hard to understand.

    Andy

  • cgraceycgracey Posts: 13,730

    @Ariba said:
    Thanks Chip, getting the data only on request is good, so I can decide the sampling rate.

    Something else:
    I find the changed behaviour of the REPEAT FROM TO loops very dangerous. There is existing code that checks if the variable is outside the range to detect that the loop was not early terminated with quit. For example this snippet from the FSRW driver (SD card driver) that compares the filename:

          repeat i from 0 to 10
             if (padname[i] <> byte[s+i])
                quit
          if (i == 11 and 0 == (byte[s][$0b] & $18))
             ...
    

    With the variable limited to the range, this does not work anymore, but the error is hard to find, because there is no error stated, and it works in many cases, but not in all.
    Took me quite some time to find the reason why the FSRW not works correctly with the new PNUT version.
    Now I've changed it to:

          repeat i from 0 to 11
             if (padname[i] <> byte[s+i]) and i < 11
                quit
          if (i >= 11 and 0 == (byte[s][$0b] & $18))
    

    but that is ugly and hard to understand.

    Andy

    I probably should have left it alone.

  • flexspin still has the old behaviour, too, so it's not like there's gonna be compatibility hell if you change it back.

  • AribaAriba Posts: 2,590

    Also FOR - NEXT in BASIC, and for(;;) in C have the index variable outside the range after the loop, that is just how this type of loop works. I don't see any advantage in the changed behaviour of Spin2.

  • cgraceycgracey Posts: 13,730
    edited 2021-12-17 23:40

    @Ariba said:
    Also FOR - NEXT in BASIC, and for(;;) in C have the index variable outside the range after the loop, that is just how this type of loop works. I don't see any advantage in the changed behaviour of Spin2.

    Neither do I, really, but someone in the past had impressed upon me that we needed to change it, so I did.

  • evanhevanh Posts: 13,392

    I got the impression the request was because Spin1 worked that way and he wanted both to be the same ... although it may not have been directly stated as such.

  • But isn't that bit of FSRW code ported 1:1 from Spin1? Which implies that that's not actually true? I don't know.

  • AribaAriba Posts: 2,590
    edited 2021-12-18 00:21

    It was a request by a teacher in the live forums, I don't remember the reason. I think he and his stundents just expected it to work differently. Spin1 works just like BASIC and C and the previous PNUT/PropTool.

    Andy

  • I imagine it will be a while before it makes it to propeller tool...

    Hopefully, not too long -- this feature is likely to get a lot of use.

  • evanhevanh Posts: 13,392
    edited 2021-12-18 10:06

    Chip,
    I'd like a way to run-time update debug's comport timing. This is specifically for when using Spin2's clkset() function, so maybe it could be integrated into the clkset() function itself.

    Currently that timing config is pre-compiled to suit the clkfreq_ constant and locked into the protected 16 KB debug area. So any call to clkset() is currently incompatible with all debug features.

    An alternative might be not have the smartpin timing set within every debug event. That would lessen overheads at the same time.

  • Oh, a small request: Can we get predefined symbols for ALTI S fields? I always have to look them up in the manual...

  • roglohrogloh Posts: 4,437
    edited 2021-12-19 10:18

    Why does this simple DEBUG test program fail and spew out continuous debug data in PropellerTool? Is this DEBUG syntax wrong for printing HUB arrays or is there a bug in 2.6.0 of PropellerTool?

    I found it works okay in Flex and the DEBUG documentation says you can print arrays out in PASM2 so it should work AFAIK. I tried with and without # for the constant length of 3 to print, as well as using registers for that size argument too, but it didn't help. It just keeps printing memory (forever?)

    CON
        _clkfreq = 160000000
    
        DEBUG_BAUD = 115200
        DEBUG_DELAY = 2000
    
    PUB main()
        coginit(NEWCOG, @reader, @startupData)
    
    DAT
        orgh
    
    '-----------------------------------------------------------------------
    ' Reader Cog PASM2 code entry point
    '-----------------------------------------------------------------------
    
    reader
                org 0
                cogid pb
                DEBUG(UHEX_LONG(pb))
                DEBUG(UHEX_LONG(ptra))
                DEBUG(UHEX_LONG_ARRAY(ptra, #3))  'also tried 3 instead of #3
    
                cogstop pb
    
                orgh
    
    startupData
                  long $aabbccdd
                  long $abcd1234
                  long $deadbeef
    

    I get this from Flex which is what I wanted to see, but PropellerTool doesn't stop printing:

    ( Entering terminal mode.  Press Ctrl-] or Ctrl-Z to exit. )
    Cog0  INIT $0000_0000 $0000_0000 load
    Cog0  INIT $0000_0404 $0000_0000 load
    Cog1  INIT $0000_06C0 $0000_06D4 load
    Cog1  pb = $0000_0001
    Cog1  ptra = $0000_06D4
    Cog1  ptra = $AABB_CCDD, $ABCD_1234, $DEAD_BEEF
    
  • evanhevanh Posts: 13,392

    I'm no whizz with Spin but I've been in the habit of always placing a REPEAT at the end of the main block to stop it exiting. I know it makes no diff in FlexSpin but I vaguely remember there is an effect with Pnut.

  • evanhevanh Posts: 13,392

    Huh, just gave it a whirl and it works correctly as is in flexspin and, a little surprisingly, in pnut too. But as you noted, it messes up in proptool ... v2.6.0 ... no change with REPEAT added ...

  • I know what you mean but I think it makes no difference here AFAIK however I did just find that 2.5.3 doesn't do the (infinite?) printing loop. So something in 2.6.0 seems to be bad. I've already found it crashes from time to time too on my windows 10 PC so it might be a bit buggy in general.

  • evanhevanh Posts: 13,392

    @rogloh said:
    ... I did just find that 2.5.3 doesn't do the (infinite?) printing loop. So something in 2.6.0 seems to be bad. I've already found it crashes from time to time too on my windows 10 PC so it might be a bit buggy in general.

    That makes sense.

  • cgraceycgracey Posts: 13,730

    @Wuerfel_21 said:
    Oh, a small request: Can we get predefined symbols for ALTI S fields? I always have to look them up in the manual...

    Yes, I will add some for the next release. I've got the mouse stuff done. Now I have to get the keyboard stuff going.

  • cgraceycgracey Posts: 13,730

    @evanh said:
    Chip,
    I'd like a way to run-time update debug's comport timing. This is specifically for when using Spin2's clkset() function, so maybe it could be integrated into the clkset() function itself.

    Currently that timing config is pre-compiled to suit the clkfreq_ constant and locked into the protected 16 KB debug area. So any call to clkset() is currently incompatible with all debug features.

    An alternative might be not have the smartpin timing set within every debug event. That would lessen overheads at the same time.

    Maybe I could make a 'BAUDVAL (x)' command which would override the default for that DEBUG operation.

  • evanhevanh Posts: 13,392

    @cgracey said:
    Maybe I could make a 'BAUDVAL (x)' command which would override the default for that DEBUG operation.

    I presume the idea is that that could be issued next to a clkset() and takes effect when debugging is enabled. Sounds good. Probably better than what I was thinking because it is only compiled in when debug is switched on.

  • cgraceycgracey Posts: 13,730

    @evanh said:

    @cgracey said:
    Maybe I could make a 'BAUDVAL (x)' command which would override the default for that DEBUG operation.

    I presume the idea is that that could be issued next to a clkset() and takes effect when debugging is enabled. Sounds good. Probably better than what I was thinking because it is only compiled in when debug is switched on.

    I am thinking that it wouldn't do a CLKSET, but just use the baud setting that you'd give it. Maybe it could compute the baud from the current clkfreq.

  • evanhevanh Posts: 13,392
    edited 2021-12-21 10:17

    Right, user program would call both when changing the clock frequency, I figured you meant it that way.

    No, don't do the calculations internally. clkset() also needs external calculation. I've crafted an easy to use routine already.
    EDIT: Hmm, maybe it is a good idea to do the calculation for smartpin internal to BAUDVAL(). Otherwise the user program can control the data format.

    In which case then there is no need for any parameter. All debug parameters are defined at compile time. So BAUDVAL() just has to recalibrate to updated clkfreq system variable.

  • evanhevanh Posts: 13,392
    edited 2021-12-21 11:12

    Here's the tail of my existing pllset() routine:

        if mode.[24]                        ' PLL-ON bit set when calculation is valid
            clkset( mode, targetfreq + besterror )      ' make the frequency change
            baudval()                   ' recalibrate debug comms as well
        else
            xinfreq = -1                    ' failed, no change
    

    I've tacked in BAUDVAL() simply there.

  • @cgracey

    Both Pnut V35q and propeller Tool 2.6.0 report "Error: Constant must be from 0 to 255" for the following code.

      l_addr = $123
    
    dat     org
       rdlut pa,#l_addr
    
    

    Same for WRLUT too.
    Should be 0 to 511 for non augmented constamts..

  • Wuerfel_21Wuerfel_21 Posts: 3,013
    edited 2021-12-22 10:47

    No, it's correct. LUT access uses the same format as hub access, so only the first 256 entries are immediate-addressable. This is in exchange for RDLUT something,ptra++ and such being valid ops.

  • evanhevanh Posts: 13,392

    Oh, that was another RevB silicon change wasn't it.

  • cgraceycgracey Posts: 13,730
    edited 2021-12-22 13:11

    I've got the PC-keyboard and PC-mouse feedback working in the DEBUG displays. If you look in the Spin2 doc and search for "PC_KEY" or "PC_MOUSE", you will find the description of how it works.

    For the mouse, the position within the window, all three buttons, and the scroll-wheel delta are returned.

    For the keyboard, all keys are returned, including the arrows and editing keys.

    I will post this tomorrow and will demonstrate it after the P2 Live Forum at 1pm.

    ' Run with DEBUG enabled to view
    
    _clkfreq = 200_000_000
    
    VAR
         long key   'PC_KEY
    
         long xpos  'PC_MOUSE record (6 contiguous longs)
         long ypos
         long wheeldelta
         long lbutton
         long mbutton
         long rbutton
    
    PUB go() | c
    
      debug(`plot myplot rgbi8 hidexy)
    
      repeat
        debug(`myplot `pc_mouse(@xpos))             'read PC mouse
        debug(`myplot `pc_key(@key))                'read PC keyboard
        c := (c + wheeldelta << 5) & $E0 | $1F      'scrollwheel changes drawing color
        if lbutton                                  'left button draws
          debug(`myplot color `(c) set `(xpos, ypos) dot 5)
        if mbutton                                  'middle button clears the canvas
          debug(`myplot clear)
        if rbutton                                  'right button erases
          debug(`myplot color 0 set `(xpos, ypos) dot 21 32)
        if key                                      'print any key value at the mouse pointer
          debug(`myplot set `(xpos, ypos) text '`(key)')
    
  • cgraceycgracey Posts: 13,730
    edited 2021-12-22 20:44

    I updated the top link to the latest v35r which does the keyboard/mouse feedback:

    https://drive.google.com/file/d/1aWx7Sv6ZjTpf2ZivrI5MoA8QVQqKqiK8/view?usp=sharing

    See the "DEBUG_Mouse_and_Keyboard.spin2" file for a comprehensive example of the new PC_KEY and PC_MOUSE commands in DEBUG.

Sign In or Register to comment.