Shop Learn P1 Docs P2 Docs Events
PNut/Spin2 Latest Version (v37 - OBJ parameterization, field pointers, locals cleared, plus more) - Page 53 — Parallax Forums

PNut/Spin2 Latest Version (v37 - OBJ parameterization, field pointers, locals cleared, plus more)

1505153555659

Comments

  • jmgjmg Posts: 14,994
    edited 2022-08-28 01:21

    @cgracey said:
    I just tried something on a lark and it actually works now:

    CON download_baud = 3_000_000 'debug_baud will inherit the download_baud value

    The new serial works at 3 Megabaud!

    Did you test any of this running via a FT232H or FT2232H ?

    Running those HS Serial links, should let you shake out bugs in the code, as the driver-side of those have higher thru-put limits, and larger HW buffers.
    It would also be useful to compare where WINE systems fail, if running those HS-USB Serial parts.

    There are growing serial bridge choices these days, I have some CH9102 parts here and some PL2303GC which are FS-USB parts with different top baud speeds.
    There is also a CH347 I'd like to trial, (TSSOP20 HS-USB) when I can source a module.

    Addit: A search just found there is now a CH347 module, so I've ordered some to trial https://www.tindie.com/products/johnnywu/ch347-development-board/

  • cgraceycgracey Posts: 13,895
    edited 2022-08-28 01:17

    @jmg said:

    @cgracey said:
    I just tried something on a lark and it actually works now:

    CON download_baud = 3_000_000 'debug_baud will inherit the download_baud value

    The new serial works at 3 Megabaud!

    Did you test any of this running via a FT232H or FT2232H ?

    Running those HS Serial links, should let you shake out bugs in the code, as the driver-side of those have higher thru-put limits, and larger HW buffers.
    It would also be useful to compare where WINE systems fail, if running those HS-USB Serial parts.

    There are growing serial bridge choices these days, I have some CH9102 parts here and some PL2303GC which are FS-USB parts with different top baud speeds.
    There is also a CH347 I'd like to trial, (TSSOP20 HS-USB) when I can source a module.

    I have an FT231XS chip on my prop plug. The part is supposed to be good for 3M baud. That's all I've got.

    In order to get 3Mbaud working, the Latency Timer needs to be set to 1ms in the Device Manager, in order to not overflow the internal buffers, and having a dedicated thread in Windows helps, too.

  • jmgjmg Posts: 14,994
    edited 2022-08-28 02:08

    @cgracey said:

    @jmg said:

    @cgracey said:
    I just tried something on a lark and it actually works now:

    CON download_baud = 3_000_000 'debug_baud will inherit the download_baud value

    The new serial works at 3 Megabaud!

    Did you test any of this running via a FT232H or FT2232H ?

    Running those HS Serial links, should let you shake out bugs in the code, as the driver-side of those have higher thru-put limits, and larger HW buffers.
    It would also be useful to compare where WINE systems fail, if running those HS-USB Serial parts.

    There are growing serial bridge choices these days, I have some CH9102 parts here and some PL2303GC which are FS-USB parts with different top baud speeds.
    There is also a CH347 I'd like to trial, (TSSOP20 HS-USB) when I can source a module.

    I have an FT231XS chip on my prop plug. The part is supposed to be good for 3M baud. That's all I've got.

    In order to get 3Mbaud working, the Latency Timer needs to be set to 1ms in the Device Manager, in order to not overflow the internal buffers, and having a dedicated thread in Windows helps, too.

    The HS-USB link uses a 125us frame, and most HS-USB bridge parts have larger HW buffers. You can also define larger PC-side buffers as part of the open step.

    The CH347 data says this : Each serial port has a built-in 12K-byte receive FIFO and a 4K-byte transmit FIFO.

  • hinvhinv Posts: 1,215

    @cgracey said:
    I want to have tools running on the P2, itself, for many reasons. It would be a whole new level of productivity.

    Very good to hear! I agree!

  • @JonnyMac said:

    Please @cgracey , just EOL the Delphi based PNut and rewrite it for the P2 itself...

    Sure, dump the old version of Delphi, but don't make us do development on the P2. Update the Spin compiler to an external app, written in a x-platform language that can be compiled anywhere and does dead code removal, share it with others for improvements/new features (but maintain an official version). Focus on specialty hardware (the P1 and P2), and generalize the development. Developing only for Windows has hurt the Parallax bottom line.

    I'm sure this will cause me troubles, but I have developed this thing a while ago:
    https://forums.parallax.com/discussion/174436/spin-tools-ide

    The discussion wasn't updated in a while, but if anybody is interested, the latest version is available here:
    https://www.maccasoft.com/spin-tools-ide/

    Just my 2cents.

  • cgraceycgracey Posts: 13,895
    edited 2022-08-28 05:56

    @macca said:

    @JonnyMac said:

    Please @cgracey , just EOL the Delphi based PNut and rewrite it for the P2 itself...

    Sure, dump the old version of Delphi, but don't make us do development on the P2. Update the Spin compiler to an external app, written in a x-platform language that can be compiled anywhere and does dead code removal, share it with others for improvements/new features (but maintain an official version). Focus on specialty hardware (the P1 and P2), and generalize the development. Developing only for Windows has hurt the Parallax bottom line.

    I'm sure this will cause me troubles, but I have developed this thing a while ago:
    https://forums.parallax.com/discussion/174436/spin-tools-ide

    The discussion wasn't updated in a while, but if anybody is interested, the latest version is available here:
    https://www.maccasoft.com/spin-tools-ide/

    Just my 2cents.

    That is interesting, Macca. What do you use for a compiler inside it?

  • @cgracey said:

    @macca said:

    @JonnyMac said:

    Please @cgracey , just EOL the Delphi based PNut and rewrite it for the P2 itself...

    Sure, dump the old version of Delphi, but don't make us do development on the P2. Update the Spin compiler to an external app, written in a x-platform language that can be compiled anywhere and does dead code removal, share it with others for improvements/new features (but maintain an official version). Focus on specialty hardware (the P1 and P2), and generalize the development. Developing only for Windows has hurt the Parallax bottom line.

    I'm sure this will cause me troubles, but I have developed this thing a while ago:
    https://forums.parallax.com/discussion/174436/spin-tools-ide

    The discussion wasn't updated in a while, but if anybody is interested, the latest version is available here:
    https://www.maccasoft.com/spin-tools-ide/

    Just my 2cents.

    That is interesting, Macca. What do you use for a compiler inside it?

    No external compiler, all integrated, developed my own by reverse engineering PropTools and PNut binary outputs (with some help from the interpreter source).

  • cgraceycgracey Posts: 13,895
    edited 2022-08-28 06:12

    @macca said:

    @cgracey said:

    @macca said:

    @JonnyMac said:

    Please @cgracey , just EOL the Delphi based PNut and rewrite it for the P2 itself...

    Sure, dump the old version of Delphi, but don't make us do development on the P2. Update the Spin compiler to an external app, written in a x-platform language that can be compiled anywhere and does dead code removal, share it with others for improvements/new features (but maintain an official version). Focus on specialty hardware (the P1 and P2), and generalize the development. Developing only for Windows has hurt the Parallax bottom line.

    I'm sure this will cause me troubles, but I have developed this thing a while ago:
    https://forums.parallax.com/discussion/174436/spin-tools-ide

    The discussion wasn't updated in a while, but if anybody is interested, the latest version is available here:
    https://www.maccasoft.com/spin-tools-ide/

    Just my 2cents.

    That is interesting, Macca. What do you use for a compiler inside it?

    No external compiler, all integrated, developed my own by reverse engineering PropTools and PNut binary outputs (with some help from the interpreter source).

    Wow! That is quite an endeavor.

    I put the compiler for our tools into a github repository. I just updated it today with the latest stuff. Do you ever look at that?

  • cgraceycgracey Posts: 13,895
    edited 2022-09-11 08:52

    I posted a new PNut_v35v at the top of this thread.

    • P62 held high before DEBUG, so that older P2 Edge modules without serial pull-ups will work with the debugger.
    • Automatic clock setup added for PASM-only programs. No more need for ASMCLK.
  • cgraceycgracey Posts: 13,895

    I also update the P2_PNut_Public repository.

    https://github.com/parallaxinc/P2_PNut_Public

  • @cgracey said:

    • Automatic clock setup added for PASM-only programs. No more need for ASMCLK.

    That sounds troublesome. Where and how does that happen?

  • evanhevanh Posts: 14,025
    edited 2022-09-11 11:08

    From the notes:

    PASM-only programs which use non-RCFAST clock modes now get prepended with a 16-long clock-setter program which sets the clock mode, moves the PASM program down into position, and then executes it. This means that the ASMCLK instruction is no longer needed at the start of PASM-only programs. This harmonizes with the PASM-level debugger's operation, where the clock is automatically set.

    I see why - So debug() can stay as a set at assemble-time sysclock frequency ... Not the direction I was hoping this would take.

  • cgraceycgracey Posts: 13,895
    edited 2022-09-11 17:09

    @Wuerfel_21 said:

    @cgracey said:

    • Automatic clock setup added for PASM-only programs. No more need for ASMCLK.

    That sounds troublesome. Where and how does that happen?

    From the version notes:

    "PASM-only programs which use non-RCFAST clock modes now get prepended with a 16-long clock-setter program which sets the clock mode, moves the PASM program down into position, and then executes it. This means that the ASMCLK instruction is no longer needed at the start of PASM-only programs. This harmonizes with the PASM-level debugger's operation, where the clock is automatically set."

    There could be a symbol which, if defined, would disable this 16-long program from being prepended to your PASM-only program. Then, you would have to manually control it.

    It is impossible to single-step through clock-setting code, because it affects the serial baudrate and blows up the debugger. So, it's good to get it out of the way. It makes stepping through small PASM programs so much cleaner, because you don't have the awkward clock-setting ASMCLK code to work around and you don't have to suffer it cluttering up your code.

  • cgraceycgracey Posts: 13,895

    @evanh said:
    From the notes:

    PASM-only programs which use non-RCFAST clock modes now get prepended with a 16-long clock-setter program which sets the clock mode, moves the PASM program down into position, and then executes it. This means that the ASMCLK instruction is no longer needed at the start of PASM-only programs. This harmonizes with the PASM-level debugger's operation, where the clock is automatically set.

    I see why - So debug() can stay as a set at assemble-time sysclock frequency ... Not the direction I was hoping this would take.

    Evan, what would you like to see?

  • cgraceycgracey Posts: 13,895
    edited 2022-09-11 17:11

    About the ASMCLK code where there are six instructions which set a crystal/PLL combo, I should probably precede it with a REP #6,#1 instruction to shield it from interrupts, especially debug interrupts.

  • evanhevanh Posts: 14,025

    @cgracey said:
    Evan, what would you like to see?

    At the moment I generally don't use debug() for one reason - It breaks when run-time adjusting the sysclock frequency.

    In my own diagnostic printing code, that I maintain, I have a two step process of adjusting the sysclock frequency then adjusting the baud ratio of the serial pins. eg:

        lib.pllset( test_freq )
        lib.baudinit( DEBUG_BAUD )
    

    An alternative would be incorporate the second step into pllset() or even clkset().

  • evanhevanh Posts: 14,025
    edited 2022-09-11 22:48

    Here's my existing pllset() source code (Based off your posted compile-time source). It has a one line commented baudval(), straight after its clkset() call, ready to be uncommented when such a function exists as standard:

    pub  pllset( targetfreq ) : xinfreq | mode, mult, divd, divp, post, Fpfd, Fvco, error, besterror, vcolimit
    
        mode := clkmode_
    
        if clkmode_ >> 24 & 1                           ' compiled with PLL on
            divd := clkmode_ >> 18 & $3f + 1
            mult := clkmode_ >> 8 & $3ff + 1
            divp := (clkmode_ >> 4 + 1) & $f
            divp := divp ? divp * 2 : 1
            xinfreq := muldiv65( divp * divd, clkfreq_, mult )
    
        elseif clkmode_ >> 2 & 3                        ' compiled with PLL off
            xinfreq := clkfreq_                     ' clock pass-through
        else                                            ' unknown build mode
            xinfreq := 20_000_000                   ' default to 20 MHz crystal
            mode := %10_00                          ' default to 15 pF loading
    
        mode := %11_11 & mode | %11                     ' keep %CC, force %SS, ditch the rest
    
        besterror := div33( targetfreq, 100 )           ' _errfreq at 1.0% of targetfreq
        vcolimit := targetfreq + besterror
        vcolimit := vcolimit < 201_000_000 ? 201_000_000 : vcolimit
    
        repeat post from 0 to 15
            divp := post ? post * 2 : 1
    
            repeat divd from 64 to 1
                Fpfd := div33( xinfreq, divd )
                mult := muldiv65( divp * divd, targetfreq, xinfreq )
                Fvco := muldiv65( xinfreq, mult, divd )
    
                if Fpfd >= 250_000 and mult <= 1024 and Fvco > 99_000_000 and Fvco <= vcolimit
                    error := div33( Fvco, divp ) - targetfreq
    
                    if abs( error ) <= abs( besterror )     ' the last iteration at equality gets priority
                        besterror := error
                        mode := (mode&%11_11) | 1<<24 | (divd-1)<<18 | (mult-1)<<8 | ((post-1)&15)<<4
    
        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
    
  • Just installed the latest Pnut-spin2 v35v. Norton 360 choked on the .exe file. Is this a false Norton indication?

  • cgraceycgracey Posts: 13,895

    @"frank freedman" said:
    Just installed the latest Pnut-spin2 v35v. Norton 360 choked on the .exe file. Is this a false Norton indication?

    The file is fine. It was not signed, though, which may be causing the problem. Jeff here at Parallax usually signs files, but I just posted it without signing.

  • cgraceycgracey Posts: 13,895

    @evanh said:
    Here's my existing pllset() source code (Based off your posted compile-time source). It has a one line commented baudval(), straight after its clkset() call, ready to be uncommented when such a function exists as standard:

    pub  pllset( targetfreq ) : xinfreq | mode, mult, divd, divp, post, Fpfd, Fvco, error, besterror, vcolimit
    
      mode := clkmode_
    
      if clkmode_ >> 24 & 1                           ' compiled with PLL on
          divd := clkmode_ >> 18 & $3f + 1
          mult := clkmode_ >> 8 & $3ff + 1
          divp := (clkmode_ >> 4 + 1) & $f
          divp := divp ? divp * 2 : 1
          xinfreq := muldiv65( divp * divd, clkfreq_, mult )
    
      elseif clkmode_ >> 2 & 3                        ' compiled with PLL off
          xinfreq := clkfreq_                     ' clock pass-through
      else                                            ' unknown build mode
          xinfreq := 20_000_000                   ' default to 20 MHz crystal
          mode := %10_00                          ' default to 15 pF loading
    
      mode := %11_11 & mode | %11                     ' keep %CC, force %SS, ditch the rest
    
      besterror := div33( targetfreq, 100 )           ' _errfreq at 1.0% of targetfreq
      vcolimit := targetfreq + besterror
      vcolimit := vcolimit < 201_000_000 ? 201_000_000 : vcolimit
    
      repeat post from 0 to 15
          divp := post ? post * 2 : 1
    
          repeat divd from 64 to 1
              Fpfd := div33( xinfreq, divd )
              mult := muldiv65( divp * divd, targetfreq, xinfreq )
              Fvco := muldiv65( xinfreq, mult, divd )
    
              if Fpfd >= 250_000 and mult <= 1024 and Fvco > 99_000_000 and Fvco <= vcolimit
                  error := div33( Fvco, divp ) - targetfreq
    
                  if abs( error ) <= abs( besterror )     ' the last iteration at equality gets priority
                      besterror := error
                      mode := (mode&%11_11) | 1<<24 | (divd-1)<<18 | (mult-1)<<8 | ((post-1)&15)<<4
    
      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 think we need to convey DEBUG baud to the debugger.

    Since there is no guaranteed-unclaimed hub RAM, what if we put P62 and P63 into long-repository mode (P62 could output a steady high) outside of the debug interrupt ISR and we used them to hold ClkFreq and DebugBaud, so that the debugger could compute appropriate WXPIN values to configure the same pins for serial I/O?

  • evanhevanh Posts: 14,025

    How to notify of parameter passing? I was thinking there would be a debug command added. In which case the new command would be able to pass those needed variables into the protected space.

  • cgraceycgracey Posts: 13,895
    edited 2022-09-12 16:12

    @evanh said:
    How to notify of parameter passing? I was thinking there would be a debug command added. In which case the new command would be able to pass those needed variables into the protected space.

    If you changed the ClkFreq, you would just do:

    WXPIN ClkFreq,#62

    If you wanted to change BOTH, which would probably not make sense, you would do:

    WXPIN ClkFreq,#62
    WXPIN DebugBaud,#63

    The debugger ISR would do:

    RQPIN ClkFreq,#62
    RQPIN DebugBaud,#63

    ...in order to compute the WXPIN values for the same pins in serial mode.

    Before leaving the ISR, it would return P62 and P63 to repository mode and reload the values it read.

  • evanhevanh Posts: 14,025

    @cgracey said:
    If you changed the ClkFreq, you would just do:
    WXPIN ClkFreq,#62

    Won't that just be overwritten on the next debug()?

  • cgraceycgracey Posts: 13,895

    @evanh said:

    @cgracey said:
    If you changed the ClkFreq, you would just do:
    WXPIN ClkFreq,#62

    Won't that just be overwritten on the next debug()?

    I added to the prior post about this.

  • cgraceycgracey Posts: 13,895

    I don't think it would ever be necessary to actually change the baud rate, right? It would be ClkFreq that would have to be accounted for.

  • cgraceycgracey Posts: 13,895

    Maybe just P63 holds the ClkFreq in repository mode. The debug baud rate can be set by the compiler.

  • cgraceycgracey Posts: 13,895

    ...That would be best, because P62 could remain in async serial transmit mode, staying high, regardless of whether someone changed its OUT or DIR bit. P63 in repository mode would be impervious to OUT and DIR changes, as well.

  • evanhevanh Posts: 14,025

    @cgracey said:
    I added to the prior post about this.

    Oh, so the two smartpins continuously appear as repositories from the user perspective. Yeah, I'm good with that.

  • evanhevanh Posts: 14,025

    @cgracey said:
    Maybe just P63 holds the ClkFreq in repository mode. The debug baud rate can be set by the compiler.

    Yep, no problem. Wouldn't want to adjust target baud on the fly.

  • cgraceycgracey Posts: 13,895
    edited 2022-09-12 16:29

    Okay. I will work on this today.

    It would be good to know whether or not DEBUG is active in Spin2. I could have the Spin2 interpreter's "CLKSET(NewCLKMODE, NewCLKFREQ)" instruction do a "WXPIN NewCLKFREQ,#63" when in DEBUG mode. I could just NOP the instruction from the compiler when DEBUG is off.

    For PASM-only code, you would have to do the WXPIN yourself. You would always want to use a "REP #codesize,#1" to shield the clock change and WXPIN together.

Sign In or Register to comment.