PNut/Spin2 Latest Version (v44 -Data Structures Added, New Methods for Memory Testing/Manipulation)

cgracey

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

Ariba

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

Andy

cgracey

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

Ariba

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

cgracey

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

Wuerfel_21

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

Ariba

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.

cgracey

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

evanh

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.

Wuerfel_21

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.

Ariba

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

JonnyMac

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.

evanh

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.

Wuerfel_21

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

rogloh

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

evanh

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.

evanh

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

rogloh

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.

evanh

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

cgracey

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

cgracey

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

evanh

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

cgracey

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

evanh

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.

evanh

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.

ozpropdev

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

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.

evanh

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

cgracey

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)')

cgracey

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.