@Wuerfel_21 said:
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.
Oh yeah! Thanks for the reminder.
@evanh said:
Oh, that was another RevB silicon change wasn't it.
Yes and it seems my code was last run om a P2 Eval Rev A Glob top. It's all coming back to me now....
@cgracey said:
Has anyone tried out the DEBUG keyboard and mouse stuff,, yet?
I tried your demo and it worked...
I'm writing some debug "user input routines" with radio buttons that toggle color when clicked on, and buttons that look like they are "pressed" when the mouse is over them and the left button is pressed...
The white mouse cross hairs disappear when it moves over a white background... any way to make the cross hair color like inverse of background color? And any other cross hair shapes besides the x?
I have been working on a p2 GRBL stepper motor cnc program that interfaces to a g-code file sender program like "Universal G-Code Sender".
The G-code sender program has buttons for Axis jogging, homing, feedrate overrides and things like that, but mostly it allows you to pick a g-code file from a directory and stream it to the GRBL stepper motor controller.
This debug mouse/keyboard functionality may allow me to create my own G-code sender program using debug routines.
You don't have any file reading type functionality in debug yet, I'm not sure if you are planning it...
I have used the file feature to read a g-code file into a DAT area, and stream this inside my p2 GRBL, and this may be a workaround for now, or have the p2 read a usb thumb drive or micro sd card with g-code files on it...
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..
Does double hash solve?
rdlut pa,##l_addr
Yes.
The code was originally targeted to Rev.A silicon which compiled fine at the time.
Rev.B compile trips, but as it turns out the code is now is very obsolete now.
Nothing to see here, moving on....
I found in writing windows code, it wasn't good to trust anything beyond a button. It's not hard to write little controls yourself, and just monitor screen location and button presses to make everything go.
@rogloh said in post:
Why does this simple DEBUG test program fail and spew out continuous debug data in PropellerTool?
...
I get this from Flex which is what I wanted to see, but PropellerTool doesn't stop printing:
Thanks for reporting this. I had no idea why that'd happen but have finally found the discrepancy in Propeller Tool that caused it and am working with Chip so I can solve it. The debugger image that is auto-inserted into the user app before download via Propeller Tool v2.6.0 and v2.6.1 doesn't match that of PNut v35q (that it was intended to match). All debugging features I'd tried during testing worked fine, so I didn't catch this early. It appears the procedure I've used to match the intended release failed me this time, so we'll address that and make another release soon.
@rogloh said:
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.
That's right, the REPEAT doesn't matter in this case.
re: the crash from time to time - It happens very rarely for me and I haven't been able to trace it. If it happens again to you, on the error dialog please click on the Call Stack tab and take a screenshot. This will help me determine if the crash is happening in the same code region for every instance.
Note: On the next session, Propeller Tool automatically recovers your project source code as it was from the last successful compile, so I hope the crash hasn't caused to too much grief.
@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.
Why not have CLKSET() automatically perform the "BAUDVAL()" idea's routine itself (if debugging is enabled) to eliminate the chances of bugs from innocent developers?
... finally found the discrepancy in Propeller Tool that caused it... The debugger image that is auto-inserted into the user app before download via Propeller Tool v2.6.0 and v2.6.1 doesn't match that of PNut v35q (that it was intended to match).
@"Jeff Martin" said:
Why not have CLKSET() automatically perform the "BAUDVAL()" idea's routine itself (if debugging is enabled) to eliminate the chances of bugs from innocent developers?
AFAIK the standard library is all pre-built. I think, debug being compile-time conditional, there would need to be two pre-built clkset()s. One with debug enabled, and one without.
@rogloh said:
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.
That's right, the REPEAT doesn't matter in this case.
re: the crash from time to time - It happens very rarely for me and I haven't been able to trace it. If it happens again to you, on the error dialog please click on the Call Stack tab and take a screenshot. This will help me determine if the crash is happening in the same code region for every instance.
Note: On the next session, Propeller Tool automatically recovers your project source code as it was from the last successful compile, so I hope the crash hasn't caused to too much grief.
@"Jeff Martin" Thanks for fixing this so quickly in 2.6.2. If I do see the crash again I will try to capture the call stack for you. I don't typically use PropellerTool as it is not on my main Mac system so it might take some time before I see it again.
I found what I feel is a floating point assignment bug in Propeller Tool v2.6.2
@"Jeff Martin" and @cgracey please take a look (spin2 code attached).
in a PUB section, if I assign a local variable with a negative floating point value of -120.0 , it does not get assigned correctly.
if a similar local variable is assigned to a constant with the same value of -120.0, it does get assigned correctly.
@wummi said:
I think you must use:
target_speed_f1 := -.120.0
This is correct. In CON blocks, the compiler has always figured it out contextually, but in runtime code you must use "-." for float negations. Might as well start using "-." in CON blocks, as well, for consistency.
Let's rationalize this for a sec.
If I have a negative integer, and ask spin to do a similar assignment. Is the integer stored as a positive value, and the minus sign does the 2's complement before the assignment?
I'm rather just not getting it. The number -120.0 is very much it's own unique value. It's not stored as a positive 120.0 then floating point negated at runtime. Or is it?
As far as compiler complexity, is it really that much to treat the most recent - as part of the string of numeric digits among the possible . or e that tells the parser this is floating point?
If it's already working in the CON section, why break it?
Again I'll admit to not going thru every single case, is there some place where this rationalization fails?
@whicker said:
Let's rationalize this for a sec.
If I have a negative integer, and ask spin to do a similar assignment. Is the integer stored as a positive value, and the minus sign does the 2's complement before the assignment?
I'm rather just not getting it. The number -120.0 is very much it's own unique value. It's not stored as a positive 120.0 then floating point negated at runtime. Or is it?
As far as compiler complexity, is it really that much to treat the most recent - as part of the string of numeric digits among the possible . or e that tells the parser this is floating point?
If it's already working in the CON section, why break it?
Again I'll admit to not going thru every single case, is there some place where this rationalization fails?
Runtime code is a lot more open-ended than CON block declarations. The code compiler needs to be told whether you want a '-' integer negation or a '-.' floating-point negation.
@cgracey I think it's just a matter of how the characters in "-1.0" should be parsed. Is this two tokens, an operator "-" and a number "1.0"? Or is it one single token, the number "-1.0"? I think most people would intuitively characterize it as the latter. Implementing it that way shouldn't be too difficult: when the parser encounters a "-" character it should look ahead at the next character, and if it is any of "0-9" then it should keep grabbing characters and form a number.
@ersmith said:
@cgracey I think it's just a matter of how the characters in "-1.0" should be parsed. Is this two tokens, an operator "-" and a number "1.0"? Or is it one single token, the number "-1.0"? I think most people would intuitively characterize it as the latter. Implementing it that way shouldn't be too difficult: when the parser encounters a "-" character it should look ahead at the next character, and if it is any of "0-9" then it should keep grabbing characters and form a number.
Yes. Users will expect to be able to cut and paste already tested and proven floating point code, from any other platform, and have it simply work.
They will not expect to need obtuse semantics to magically get correct/expected operation.
A new version v35s is posted at the top of this thread.
Negative floating-point constants can be preceded with a simple '-', so that '-.' is only needed for variables and expressions.
Fixed FSQRT() bugs in the compiler and the interpreter. Both were failing on FSQRT(-0.0) and the compiler was generating a wrong result for FSQRT(0.0).
Improved floating-point rounding operations in both the compiler and the interpreter, so that even mantissas with fractions of 0.500 will not have the usual 0.500 added to them before truncation. This eliminates rounding bias.
Added BYTEFIT, which is like BYTE for use in DAT sections, but verifies byte data are -$80 to $FF.
Added WORDFIT, which is like WORD for use in DAT sections, but verifies word data are -$8000 to $FFFF.
Added @"Text", which is a shorthand version of STRING() that only allows text between quotes.
Comments
Oh yeah! Thanks for the reminder.
Yes and it seems my code was last run om a P2 Eval Rev A Glob top. It's all coming back to me now....
Has anyone tried out the DEBUG keyboard and mouse stuff,, yet?
I ran your mouse/keyboard demo, which is working as expected as far as I can tell.
I'm in the process of adding some PC keyboard input to one of my programs that uses debug windows.
I'll post my results soon, hopefully. It is always hard to carve out enough time to play with new toys.
So far so good, thank you Chip for getting this debug mouse/keyboard ability working :-)
I tried your demo and it worked...
I'm writing some debug "user input routines" with radio buttons that toggle color when clicked on, and buttons that look like they are "pressed" when the mouse is over them and the left button is pressed...
The white mouse cross hairs disappear when it moves over a white background... any way to make the cross hair color like inverse of background color? And any other cross hair shapes besides the x?
I have been working on a p2 GRBL stepper motor cnc program that interfaces to a g-code file sender program like "Universal G-Code Sender".
The G-code sender program has buttons for Axis jogging, homing, feedrate overrides and things like that, but mostly it allows you to pick a g-code file from a directory and stream it to the GRBL stepper motor controller.
This debug mouse/keyboard functionality may allow me to create my own G-code sender program using debug routines.
You don't have any file reading type functionality in debug yet, I'm not sure if you are planning it...
I have used the file feature to read a g-code file into a DAT area, and stream this inside my p2 GRBL, and this may be a workaround for now, or have the p2 read a usb thumb drive or micro sd card with g-code files on it...
I gave the demo a quick try because I have a project idea -- but I'll wait on that until everything is ported to Propeller Tool.
Does double hash solve?
rdlut pa,##l_addr
Yes.
The code was originally targeted to Rev.A silicon which compiled fine at the time.
Rev.B compile trips, but as it turns out the code is now is very obsolete now.
Nothing to see here, moving on....
@cgracey , Here is a mouse button and slider demo...
Just downloaded your code and it works great, thank you.
MwRoberts, that works pretty well.
I found in writing windows code, it wasn't good to trust anything beyond a button. It's not hard to write little controls yourself, and just monitor screen location and button presses to make everything go.
Thanks for reporting this. I had no idea why that'd happen but have finally found the discrepancy in Propeller Tool that caused it and am working with Chip so I can solve it. The debugger image that is auto-inserted into the user app before download via Propeller Tool v2.6.0 and v2.6.1 doesn't match that of PNut v35q (that it was intended to match). All debugging features I'd tried during testing worked fine, so I didn't catch this early. It appears the procedure I've used to match the intended release failed me this time, so we'll address that and make another release soon.
That's right, the REPEAT doesn't matter in this case.
re: the crash from time to time - It happens very rarely for me and I haven't been able to trace it. If it happens again to you, on the error dialog please click on the Call Stack tab and take a screenshot. This will help me determine if the crash is happening in the same code region for every instance.
Note: On the next session, Propeller Tool automatically recovers your project source code as it was from the last successful compile, so I hope the crash hasn't caused to too much grief.
Why not have CLKSET() automatically perform the "BAUDVAL()" idea's routine itself (if debugging is enabled) to eliminate the chances of bugs from innocent developers?
I'm happy to report this problem has been fixed in Propeller Tool v2.6.2.
AFAIK the standard library is all pre-built. I think, debug being compile-time conditional, there would need to be two pre-built clkset()s. One with debug enabled, and one without.
@"Jeff Martin" Thanks for fixing this so quickly in 2.6.2. If I do see the crash again I will try to capture the call stack for you. I don't typically use PropellerTool as it is not on my main Mac system so it might take some time before I see it again.
I found what I feel is a floating point assignment bug in Propeller Tool v2.6.2
@"Jeff Martin" and @cgracey please take a look (spin2 code attached).
in a PUB section, if I assign a local variable with a negative floating point value of -120.0 , it does not get assigned correctly.
if a similar local variable is assigned to a constant with the same value of -120.0, it does get assigned correctly.
Fails in Pnut 35q. Works in Flexspin 5.9.4-beta.
I note it's a negative float issue. A direct assignment of a positive float works in Pnut.
I think you must use:
target_speed_f1 := -.120.0
This is correct. In CON blocks, the compiler has always figured it out contextually, but in runtime code you must use "-." for float negations. Might as well start using "-." in CON blocks, as well, for consistency.
Ugh! The number already has a ".". Negative sign isn't an operator.
Let's rationalize this for a sec.
If I have a negative integer, and ask spin to do a similar assignment. Is the integer stored as a positive value, and the minus sign does the 2's complement before the assignment?
I'm rather just not getting it. The number -120.0 is very much it's own unique value. It's not stored as a positive 120.0 then floating point negated at runtime. Or is it?
As far as compiler complexity, is it really that much to treat the most recent - as part of the string of numeric digits among the possible . or e that tells the parser this is floating point?
If it's already working in the CON section, why break it?
Again I'll admit to not going thru every single case, is there some place where this rationalization fails?
Runtime code is a lot more open-ended than CON block declarations. The code compiler needs to be told whether you want a '-' integer negation or a '-.' floating-point negation.
Sorry, nowhere near convincing enough Chip. A negative value is not a negation.
@cgracey I think it's just a matter of how the characters in "-1.0" should be parsed. Is this two tokens, an operator "-" and a number "1.0"? Or is it one single token, the number "-1.0"? I think most people would intuitively characterize it as the latter. Implementing it that way shouldn't be too difficult: when the parser encounters a "-" character it should look ahead at the next character, and if it is any of "0-9" then it should keep grabbing characters and form a number.
Substantial time saving possible for inline PASM routine - please see attachment.
EDIT:
Should be 10 cycles for REGEXEC in line 3.
Yes. Users will expect to be able to cut and paste already tested and proven floating point code, from any other platform, and have it simply work.
They will not expect to need obtuse semantics to magically get correct/expected operation.
I hear what you guys are saying.
In the case of negating variables, we need to use '-.' vs '-' to distinguish between float vs integer negation.
I will look into parsing negative floats as '-1.0'. It would be better that way, I agree.
A new version v35s is posted at the top of this thread.
Cool. I've not delved into floats yet but that negative constants improvement will definitely prevent some extra swear words.
Did the Cordic pipeline trick work out for de-biasing?