@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.
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.
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
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.
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.
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.
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.
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).
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
@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.
@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%.
Comments
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.
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
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
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:
_CLKFREQvsCLKFREQ_PS:
_XINFREQ/XINFREQ_is same story as_XTLFREQ/XTLFREQ_None exist without being explicitly defined.Documentation error in Clock Setup section of Spin2 document. Where it describes defining of both
_XINFREQand_CLKFREQit 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.
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:
_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.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.
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.
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).Is there such a command? Oh, you mean Chip could put that in without a redesign.
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.
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. Thenclkmode_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 restEDIT: Bug fix - divp wasn't bounded correctly.
Newer test program here - https://forums.parallax.com/discussion/comment/1529415/#Comment_1529415
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:
I get the following output:
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
Maybe can't put a function call inside a string formatting.
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]Aaaand sync'd into flexspin!
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.
Lol, all of that is skill!
JUST skill?
I am a Wuerfel-Fan...
Mike
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.
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.
The debugger support is, the actual float ops aren't. Though they'll be easy to add.
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!
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%.