Shop OBEX P1 Docs P2 Docs Learn Events
PNut/Spin2 Latest Version (v46 - DEBUG gating, clock-setter control, VAR flexibility, C_Z for DEBUG) - Page 45 — Parallax Forums

PNut/Spin2 Latest Version (v46 - DEBUG gating, clock-setter control, VAR flexibility, C_Z for DEBUG)

1424345474865

Comments

  • @ManAtWork said:
    A minor bug in Propeller Tool 2.5.3:
    The debug output (text teminal) window is not refreshed when re-sized. When moving the window around by dragging the title bar the text contents stay there but if the window is re-sized only a blank black area is left.

    Improvement request: It would be nice if mark and copy would work on the text for archiving/logging or documentation purposes.

    Thank you. I've logged your reports here: https://github.com/parallaxinc/Propeller-Tool/issues/150
    and here: https://github.com/parallaxinc/Propeller-Tool/issues/151

    On the latter, despite mark and copy, are you aware that there's a logging feature to log all that data right to a text file? If I recall, the log file (if enabled for that code) is stored in your My Documents/Propeller Tool folder.

  • @"Jeff Martin" said:
    On the latter, despite mark and copy, are you aware that there's a logging feature to log all that data right to a text file? If I recall, the log file (if enabled for that code) is stored in your My Documents/Propeller Tool folder.

    Ah, interesting. How can I enable logging? I haven't found anything about logging in the preferences. I also don't think it's enabled by default. I haven't found a logfile in documents/Propeller tool or AppData/Parallax/. Or is there a keyword I have to put into the code?
    Never mind. I've found it:

    DEBUG_LOG_SIZE Sets the maximum size of the 'DEBUG.log' file which will collect DEBUG messages. A value of 0 will inhibit log file generation.

    Thanks

  • evanhevanh Posts: 15,969
    edited 2021-08-23 07:43

    Chip,
    There is a bunch of constant symbols, primarily debug related, that say they have default values in the docs but Pnut at least doesn't predefine them at all. They can't be used unless they are explicitly defined in the source.

    One in particular that doesn't exist but I would like to see added is XTLFREQ_ I use this for runtime recalculating the PLL mode. At the moment I am explicitly defining the alternative _XTLFREQ to 20 MHz and using that instead.

  • @evanh said:
    Chip,
    There is a bunch of constant symbols, primarily debug related, that say they have default values in the docs but Pnut at least doesn't predefine them at all. They can't be used unless they are explicitly defined in the source.

    One in particular that doesn't exist but I would like to see added is XTLFREQ_ I use this for runtime recalculating the PLL mode. At the moment I am explicitly defining the alternative _XTLFREQ to 20 MHz and using that instead.

    Evan, Pnut supports _XINFREQ and defaults to 20_000_000

  • evanhevanh Posts: 15,969
    edited 2021-08-23 11:10

    Problem is it doesn't exist as a symbol for examination unless you've explicitly set it beforehand.

    And convention says that that form, with leading underscore, is for compile time specification. Run time examination convention seems to be with a trailing underscore. eg: _CLKFREQ vs CLKFREQ_

    PS: _XINFREQ/XINFREQ_ is same story as _XTLFREQ/XTLFREQ_ None exist without being explicitly defined.

  • evanhevanh Posts: 15,969
    edited 2021-09-07 09:23

    Documentation error in Clock Setup section of Spin2 document. Where it describes defining of both _XINFREQ and _CLKFREQ it correctly describes what Pnut compiles, "Selects XI-input-plus-PLL mode", but incorrectly states the bit pattern of that mode.

    %01_11 is correct and what Pnut generates. The Spin2 docs are saying %01_10 instead.

  • evanhevanh Posts: 15,969
    edited 2021-09-07 10:49

    Right, solved why I can't run-time adjust the sysclock and also use debug() from Pnut compiled sources. Just what I was suspecting - Pnut pre-calculates, at compile time, the bit-timing of the tx pin and sets it upon every debug() call. Any attempt to run-time correct in user code is fruitless.

    Here's the offending code:

    w       fltl    _txpin_     'reset and configure the tx pin
    x       wrpin   #%01_11110_0,_txpin_
    y       wxpin   _txmode_,_txpin_
    z       drvl    _txpin_
    

    _txmode_ is copied, along with the instructions, from the locked debug area of hubRAM into the cog on each and every debug() call. It can't be written to by user code.

    '
    ' Data set by compiler
    '
    _txpin_     long    62      '@118: tx pin (default is 62, msb = timestamp)
    _txmode_    long    0       '@11C: tx mode (2_000_000-8-N-1)
    _waitxms_   long    0       '@120: waitx value for 1ms delay
    
  • Yeah, that's a bit of a pickle. The solution (for cases like setting the clock up for a particular video mode) is to just set your _CLKFREQ to what it's going to be when you want to get DEBUG messages. That's fine in a debugging context, I'd think.

  • evanhevanh Posts: 15,969
    edited 2021-09-07 12:14

    Yeah. I've been wanting to carry over the ability to do testing at multiple sysclock frequencies from my earlier Pasm only testing to C and Spin testing with the option of using in production deployments too.

    I took Chip's original compile-time BASIC code, I think it was, that he posted a year back and ported it to FlexC for run-time use. Then rewrote it for integer use in C. And finally ported that to Spin2 (swapping out printf()s for debug()s). Which worked fine in FlexSpin, but not Pnut/Proptool because the debug() reporting is garbled. The actual setting code works fine I think.

  • Wuerfel_21Wuerfel_21 Posts: 5,074
    edited 2021-09-07 12:17

    The debug ISR code can write to protected memory, right? In that case, adding a debug command to change the baudrate should be trivial. I think there's some 24 slots for special commands left.

    Relatedly, a DEBUG_ variant that doesn't print CogN is also entirely possible (which you'd want when setting the baudrate).

  • evanhevanh Posts: 15,969
    edited 2021-09-07 12:38

    Is there such a command? Oh, you mean Chip could put that in without a redesign.

  • cgraceycgracey Posts: 14,156

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

    Floating-point math with normal operator precedence has now been added to Spin2.

    DEBUG can now print floating-point values using FDEC, FDEC_REG_ARRAY, and FDEC_ARRAY commands.

  • evanhevanh Posts: 15,969
    edited 2021-10-03 00:21

    I think I've got a solution to run-time detecting of the board's crystal or oscillator frequency, as per https://forums.parallax.com/discussion/comment/1527484/#Comment_1527484 I had to take a break for a few days and clear my head before it sank in.

    Since Pnut, and Flex has followed, uses a collection of optional constants to setup the board specific clkmode for boot up, and there is always a clkmode_ symbol that exists as a result. Then clkmode_ can be bitwise interrogated to work out what was specified.

    This spin code now prefaces the calculation of the PLL parameters:

        mode := clkmode_
    
        if clkmode_.[24]                    ' compiled with PLL on
            divd := clkmode_.[23..18] + 1
            mult := clkmode_.[17..8] + 1
            divp := (clkmode_.[7..4] + 1) & $f
            divp := divp ? divp * 2 : 1
            xinfreq := mul2div65( divp, divd, clkfreq_, mult )
    
        elseif clkmode_.[3..2]                  ' 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
    

    EDIT: Bug fix - divp wasn't bounded correctly.

  • evanhevanh Posts: 15,969
    edited 2021-10-03 00:23
  • Francis BauerFrancis Bauer Posts: 368
    edited 2021-09-23 08:20

    @cgracey said:
    I posted a new v35o at the top of this thread.

    Floating-point math with normal operator precedence has now been added to Spin2.

    DEBUG can now print floating-point values using FDEC, FDEC_REG_ARRAY, and FDEC_ARRAY commands.

    Yippee, Floating point is here, Thank you @cgracey !!!

    I just downloaded v35o and ran your 'floating_point_demo.spin2' code.

    It appears to be working OK, however when I added the following:

    debug(fdec(PI))
    debug(fdec(FSQRT(PI)))
    

    I get the following output:

    cog0 PI = 3.141593e+00
    cog0 FSQRT(PI) = -1.747309e+29
    

    The PI value is correct, but the Square Root should be: 1.772454e00
    I think we have a problem, unless I'm missing something about using FSQRT

  • evanhevanh Posts: 15,969

    Maybe can't put a function call inside a string formatting.

  • evanhevanh Posts: 15,969
    edited 2021-09-23 11:20

    Ah, Smile. Me source above doesn't compile in Pnut. Pnut doesn't like bit-indexing of constants ... or something ...

    Chip,
    Is that something you'd want to improve in Pnut?

    The error I get is error:Expected end of line. It occurs at the dot for:
    if clkmode_.[24]

  • evanhevanh Posts: 15,969

    Good stuff Wuerfel_21. And quick. I'm sure Eric is happy there is someone else with the skills to help.

  • That took no skill, just had to merge in the new code and fix the opcode table in the compiler.

  • evanhevanh Posts: 15,969

    Lol, all of that is skill!

  • JUST skill?

    I am a Wuerfel-Fan...

    Mike

  • cgraceycgracey Posts: 14,156

    @"Francis Bauer" said:

    @cgracey said:
    I posted a new v35o at the top of this thread.

    Floating-point math with normal operator precedence has now been added to Spin2.

    DEBUG can now print floating-point values using FDEC, FDEC_REG_ARRAY, and FDEC_ARRAY commands.

    Yippee, Floating point is here, Thank you @cgracey !!!

    I just downloaded v35o and ran your 'floating_point_demo.spin2' code.

    It appears to be working OK, however when I added the following:

    debug(fdec(PI))
    debug(fdec(FSQRT(PI)))
    

    I get the following output:

    cog0 PI = 3.141593e+00
    cog0 FSQRT(PI) = -1.747309e+29
    

    The PI value is correct, but the Square Root should be: 1.772454e00
    I think we have a problem, unless I'm missing something about using FSQRT

    I just posted a new version 35p that fixed a compile-time bug in FSQRT. The problem was that the compiler was optimizing and solving constant floating-point expressions at compile-time, but the FSQRT function was not implemented for compile-time, yet. Should be all fine now.

  • cgraceycgracey Posts: 14,156

    @evanh said:
    Ah, Smile. Me source above doesn't compile in Pnut. Pnut doesn't like bit-indexing of constants ... or something ...

    Chip,
    Is that something you'd want to improve in Pnut?

    The error I get is error:Expected end of line. It occurs at the dot for:
    if clkmode_.[24]

    Okay. Let me think about that. Never occurred to me.

  • @cgracey excited to see the floating-point released. Thank you, great work!

  • @Wuerfel_21 did I read your comments correctly? This is also now in flexspin? Good work too, thankyou.

  • @"Stephen Moraco" said:
    @Wuerfel_21 did I read your comments correctly? This is also now in flexspin? Good work too, thankyou.

    The debugger support is, the actual float ops aren't. Though they'll be easy to add.

  • RaymanRayman Posts: 14,683

    Great to see floating point in Spin2!

    Does Spin2 use up more of the cog memory now?

  • @Wuerfel_21 thanks for clarifying, I jumped the gun... I'll look forward to the new operations arriving when they do!

  • cgraceycgracey Posts: 14,156
    edited 2021-09-23 21:33

    @Rayman said:
    Great to see floating point in Spin2!

    Does Spin2 use up more of the cog memory now?

    The Spin2 interpreter is now 4,784 bytes long, occupying $00000..$012AF. The floating-point instructions added a total of 554 bytes of code and data to the interpreter, increasing its size by 13%.

Sign In or Register to comment.