I noticed a small difference in the crop feature when opacity is not $FF: in PNut, it seems only to apply to manual drawing, but in Spin Tools it seems like it's applied to crops, too. In the attached screen shots you can see what I mean. In the analog meter demo the needle is drawn first and then partially hidden by crop commands. When the needle is set to translucent, the lower portion shows up through the crops.
I got around this by reducing opacity just before the needle draw, then putting it back to $FF before the crop that hides the bottom of the needle.
I noticed a small difference in the crop feature: in PNut, it seems only to apply to manual drawing, but in Spin Tools it seems like it's applied to crops, too. In the attached screen shots you can see what I mean. In the analog meter demo the needle is drawn first and then partially hidden by crop commands. When the needle is set to transparent, the lower portion shows up through the crops.
Ahah... it is the bitmap draw, I forgot to reset the opacity before drawing the bitmaps.... will fix soon.
Bugfix release for the namespace scope and crop bitmap opacity bugs.
The namespace still has some issues with the content proposals but I can't fix for now, I need to do a good cleanup of that messy code.
Now the bad news: seems that somehow I broke the P2-EC board, yesterday it was working and allowed me to test the fixes above, today it doesn't work anymore "No Propeller found!", no monitor, no Taqoz, not even PNut works so I believe something is broken for good (already tried to change prop-plug, no changes).
Guess it is time to get the P2-EC32MB finally...
@macca Would it be hard for your parser to support %namesp as an alternate keyword for namesp, at least until Chip officially makes namesp a keyword? In flexspin I've special cased % followed by a letter (which cannot happen in regular Spin) so that we can define all kinds of keywords that won't conflict with PNut.
@ersmith said:
@macca Would it be hard for your parser to support %namesp as an alternate keyword for namesp, at least until Chip officially makes namesp a keyword? In flexspin I've special cased % followed by a letter (which cannot happen in regular Spin) so that we can define all kinds of keywords that won't conflict with PNut.
I need to do some changes because I assume % is for bin or quad numbers, but not very complicated.
Why ? The namespace is not compatible with PNut anyway.
@ersmith said:
@macca Would it be hard for your parser to support %namesp as an alternate keyword for namesp, at least until Chip officially makes namesp a keyword? In flexspin I've special cased % followed by a letter (which cannot happen in regular Spin) so that we can define all kinds of keywords that won't conflict with PNut.
I need to do some changes because I assume % is for bin or quad numbers, but not very complicated.
Why ? The namespace is not compatible with PNut anyway.
Right, but using % in front of extension keywords makes sure they can't conflict with any user variables or labels. It's not a big deal but I've found it handy for doing experiments in flexspin.
@ersmith said:
@macca Would it be hard for your parser to support %namesp as an alternate keyword for namesp, at least until Chip officially makes namesp a keyword? In flexspin I've special cased % followed by a letter (which cannot happen in regular Spin) so that we can define all kinds of keywords that won't conflict with PNut.
I need to do some changes because I assume % is for bin or quad numbers, but not very complicated.
Why ? The namespace is not compatible with PNut anyway.
Right, but using % in front of extension keywords makes sure they can't conflict with any user variables or labels. It's not a big deal but I've found it handy for doing experiments in flexspin.
In that case I can't just add an alias but rename the keyword, because otherwise it will have the same problems.
I'll think about it.
A number of compiler bug fixes, some debug windows fixes, and a couple of new additions:
Added a Serial port preference page:
This page allows to select the reset method between DTR, RTS or both (default is both as it was until now), enable or disable the auto discovery of the port where the target propeller (P1 or P2) is connected, and to exclude certain ports from being selected or used with the discovery. This may be useful for those who have devices that may have issues when probed for the P1 or P2 presence.
Also added a preference in the Console page to hide the backtick commands lines from the debug output, this allows to display standard debug lines without being cluttered by debug windows commands.
I have changed the P2 detection code, I'm not sure if this changes something for the Mac OS 15 issue but I think is worth to try.
The Serial port option to exclude troublesome ports is great. Bluetooth headsets are often mischievous, and this update will solve that issue nicely! Thank you Marco.
Could I ask you to expand on: A number of compiler bug fixes ?
@VonSzarvas said:
Could I ask you to expand on: A number of compiler bug fixes ?
The use of string variants ( @ and @\ ) in SEND function.
The data type override in DAT blocks (like LONG 1, 2 BYTE 3, WORD 4).
Return count checks when using structures
Some fixes with the inline use of local variables (previously it allowed to use byte/word local variables, now it generates an error if the variables are not long/struct/pointers and not long aligned), also added alignl/alignw to local variables definition.
Some additional checks for the PUB/PRI local and return variables definition (was a bit permissive, now is more aligned with PNut).
I have changed the P2 detection code, I'm not sure if this changes something for the Mac OS 15 issue but I think is worth to try.
Not working on Mac OS 15.
I do not see any changes.
still 500ms delay after RESET to "> Prop_Chk 0 0 0 0"
Can you try to change the P2 reset method setting in the serial port preferences page (see screenshot in the release announcement post) from DTR+RTS to DTR only ?
I have changed the P2 detection code, I'm not sure if this changes something for the Mac OS 15 issue but I think is worth to try.
Not working on Mac OS 15.
I do not see any changes.
still 500ms delay after RESET to "> Prop_Chk 0 0 0 0"
Can you try to change the P2 reset method setting in the serial port preferences page (see screenshot in the release announcement post) from DTR+RTS to DTR only ?
I have try RTS only, this works never.
I have also try DTR+RTS and DTR only and we have the Problem with the 500ms delay after RESET.
The workaround is so easy:
1. make RESET with DTR and wait 50ms
2. send "> Prop_Chk 0 0 0 0"
3. when you not get the answer "Prop_Ver G" Immediately, do not close the port and try a second time step 1. and 2. and it will work.
@wummi said:
I have try RTS only, this works never.
RTS won't work with the standard prop-plug as it uses DTR to reset (it is here because some may have custom adapters that use RTS instead of DTR).
I have also try DTR+RTS and DTR only and we have the Problem with the 500ms delay after RESET.
The workaround is so easy:
1. make RESET with DTR and wait 50ms
2. send "> Prop_Chk 0 0 0 0"
3. when you not get the answer "Prop_Ver G" Immediately, do not close the port and try a second time step 1. and 2. and it will work.
You already tested that this option doesn't work.
You can try again, keep the terminal window open and try to upload, the terminal will keep the serial port open.
BTW, I don't know if you have something in the flash memory, maybe try to disable the flash switch on the edge board, this should give 60 seconds for the serial programming window, this should work regardless of the delays introduced by the OS (if I'm intepreting the documentation correctly).
I was able to have more success in uploading to a P2 with SpinTools 46.0 running os MacOS...
I still only get a few of the debug graphic windows to work:
I get blank windows except for a few of the simple debug tests. What might you need to help debug those issues?
I have to admit that after recent issues with loading to a P@, I resoldered all of my PropPlugs and got better results. SPinTools 46.0 has helped even more.
@dgately said:
I was able to have more success in uploading to a P2 with SpinTools 46.0 running os MacOS...
Good.
I still only get a few of the debug graphic windows to work:
The scope debug is not very tested because there aren't much examples to run.
The example in the documentation however should display something:
Could be some issue with the MacOS display update. The scope portion of the SPECTRO example however doesn't work here.
I get blank windows except for a few of the simple debug tests. What might you need to help debug those issues?
The main problem is that I'm not sure to understand the meaning of all the parameters and what result is expected, I tried to match the PNut display but I can't test all parameters without an example.
Arg... After my initial success with Spin Tools 0.46.0, I am not able to load compiled code to any of my P2s. I've used 3 different Prop Plugs, several cables, powered USB hub, resetting of the MacBook Pro (Apple M2 Silicon, OS version 15.3.2), etc... I've tried DTR/RTS, DTR, RTS... Automatic devices discovery ON/OFF, also... Perplexed!
I'm quite able to upload compiled code with flexprop & loadp2. How different is the method that Spin Tools uses for upload versus loadp2?
One thing to note: When the upload is started, the dialog that says it can't find the P2 displays immediately. It doesn't seem to retry.
@dgately said:
Arg... After my initial success with Spin Tools 0.46.0, I am not able to load compiled code to any of my P2s. I've used 3 different Prop Plugs, several cables, powered USB hub, resetting of the MacBook Pro (Apple M2 Silicon, OS version 15.3.2), etc... I've tried DTR/RTS, DTR, RTS... Automatic devices discovery ON/OFF, also... Perplexed!
There are two more things to test:
Keep the terminal window open, this prevents the serial port from begin open. I think that stil doesn't work because there is another delay after the reset.
Disable the flash/sd card boot (all dip switches to off, except maybe the leds). This gives a 60 seconds serial programming window that should allow any delay between the reset and when the detection command is sent.
I'm quite able to upload compiled code with flexprop & loadp2. How different is the method that Spin Tools uses for upload versus loadp2?
To my point of view, loadp2 should not work, the question is what it is doing to make the serial port work ?
Maybe it is the low leve serial implmentation of the Java library, I don't know.
One thing to note: When the upload is started, the dialog that says it can't find the P2 displays immediately. It doesn't seem to retry.
There is no point to retry when I already know it won't work.
@dgately said:
Arg... After my initial success with Spin Tools 0.46.0, I am not able to load compiled code to any of my P2s. I've used 3 different Prop Plugs, several cables, powered USB hub, resetting of the MacBook Pro (Apple M2 Silicon, OS version 15.3.2), etc... I've tried DTR/RTS, DTR, RTS... Automatic devices discovery ON/OFF, also... Perplexed!
There are two more things to test:
Keep the terminal window open, this prevents the serial port from begin open. I think that stil doesn't work because there is another delay after the reset.
Disable the flash/sd card boot (all dip switches to off, except maybe the leds). This gives a 60 seconds serial programming window that should allow any delay between the reset and when the detection command is sent.
Disabling the Flash/SD card boot works in allowing loading of the code! That's good for Edge cards, not so for the KISS board that I have as well.
@dgately said:
Arg... After my initial success with Spin Tools 0.46.0, I am not able to load compiled code to any of my P2s. I've used 3 different Prop Plugs, several cables, powered USB hub, resetting of the MacBook Pro (Apple M2 Silicon, OS version 15.3.2), etc... I've tried DTR/RTS, DTR, RTS... Automatic devices discovery ON/OFF, also... Perplexed!
There are two more things to test:
Keep the terminal window open, this prevents the serial port from begin open. I think that stil doesn't work because there is another delay after the reset.
Disable the flash/sd card boot (all dip switches to off, except maybe the leds). This gives a 60 seconds serial programming window that should allow any delay between the reset and when the detection command is sent.
Disabling the Flash/SD card boot works in allowing loading of the code! That's good for Edge cards, not so for the KISS board that I have as well.
Thanks,
dgately
I have the same Problem with Mac OS 15.
I can not disable the Flash on my Card, and Spin Tools do not work for me.
@dgately said:
Disabling the Flash/SD card boot works in allowing loading of the code! That's good for Edge cards, not so for the KISS board that I have as well.
In that case, probably the only way is to invalidate the flash content so the boot falls-back to serial. I don't think there is a command to erase the flash, however if you manage to start TAQOZ (which is a problem by itself, since the trigger command has the same problem as the programming command), the command sferase should work.
Can you confirm that the "trick" to keep the terminal window open and upload does not work ?
Edit: I just saw another option, if you manage to pull-up P59, this seems to override flash and SD and always use the 60 seconds serial window.
Suggestion: As we have two members of the Px family, could you add the processor type in the name of the archive? I did this manually for driver demos I uploaded to ObEx. Thanks, @macca!
@JonnyMac said:
Suggestion: As we have two members of the Px family, could you add the processor type in the name of the archive? I did this manually for driver demos I uploaded to ObEx. Thanks, @macca!
@dgately said:
Disabling the Flash/SD card boot works in allowing loading of the code! That's good for Edge cards, not so for the KISS board that I have as well.
In that case, probably the only way is to invalidate the flash content so the boot falls-back to serial. I don't think there is a command to erase the flash, however if you manage to start TAQOZ (which is a problem by itself, since the trigger command has the same problem as the programming command), the command sferase should work.
Can you confirm that the "trick" to keep the terminal window open and upload does not work ?
More succcess today with keeping the terminal window open while attempting uploads. Works well for most of the time, especially on Edge board P2s. Less success with the KISS P2 board, which BTW does not have a reset button (requires closing & re-opening the terminal window in order to reset the P2).
When I was able to get the terminal window to allow bringing up TAQOZ, sferase did give slightly higher success along with or without the terminal window being open. Eventually, it resorts back to requiring the open terminal window to succeed.
And of course, most of the debug graphics either do not put up a window or put up a blank window (on MacOS). I get a better chance of graphic debug success when running on WIN 11 (emulation with Parallels Desktop & some luck in uploading).
Comments
Yes, there is something wrong in the scope handling, will look at it.
Yes.
Thank you, Marco!
I noticed a small difference in the crop feature when opacity is not $FF: in PNut, it seems only to apply to manual drawing, but in Spin Tools it seems like it's applied to crops, too. In the attached screen shots you can see what I mean. In the analog meter demo the needle is drawn first and then partially hidden by crop commands. When the needle is set to translucent, the lower portion shows up through the crops.
I got around this by reducing opacity just before the needle draw, then putting it back to $FF before the crop that hides the bottom of the needle.
Ahah... it is the bitmap draw, I forgot to reset the opacity before drawing the bitmaps.... will fix soon.
Released version 0.45.1
Bugfix release for the namespace scope and crop bitmap opacity bugs.
The namespace still has some issues with the content proposals but I can't fix for now, I need to do a good cleanup of that messy code.
Now the bad news: seems that somehow I broke the P2-EC board, yesterday it was working and allowed me to test the fixes above, today it doesn't work anymore "No Propeller found!", no monitor, no Taqoz, not even PNut works so I believe something is broken for good (already tried to change prop-plug, no changes).
Guess it is time to get the P2-EC32MB finally...
@macca Would it be hard for your parser to support
%namespas an alternate keyword fornamesp, at least until Chip officially makesnamespa keyword? In flexspin I've special cased%followed by a letter (which cannot happen in regular Spin) so that we can define all kinds of keywords that won't conflict with PNut.I need to do some changes because I assume % is for bin or quad numbers, but not very complicated.
Why ? The namespace is not compatible with PNut anyway.
Right, but using
%in front of extension keywords makes sure they can't conflict with any user variables or labels. It's not a big deal but I've found it handy for doing experiments in flexspin.In that case I can't just add an alias but rename the keyword, because otherwise it will have the same problems.
I'll think about it.
Released version 0.46.0
A number of compiler bug fixes, some debug windows fixes, and a couple of new additions:
Added a Serial port preference page:
This page allows to select the reset method between DTR, RTS or both (default is both as it was until now), enable or disable the auto discovery of the port where the target propeller (P1 or P2) is connected, and to exclude certain ports from being selected or used with the discovery. This may be useful for those who have devices that may have issues when probed for the P1 or P2 presence.
Also added a preference in the Console page to hide the backtick commands lines from the debug output, this allows to display standard debug lines without being cluttered by debug windows commands.
I have changed the P2 detection code, I'm not sure if this changes something for the Mac OS 15 issue but I think is worth to try.
Other changes:
The Serial port option to exclude troublesome ports is great. Bluetooth headsets are often mischievous, and this update will solve that issue nicely! Thank you Marco.
Could I ask you to expand on: A number of compiler bug fixes ?
The use of string variants ( @ and @\ ) in SEND function.
The data type override in DAT blocks (like LONG 1, 2 BYTE 3, WORD 4).
Return count checks when using structures
Some fixes with the inline use of local variables (previously it allowed to use byte/word local variables, now it generates an error if the variables are not long/struct/pointers and not long aligned), also added alignl/alignw to local variables definition.
Some additional checks for the PUB/PRI local and return variables definition (was a bit permissive, now is more aligned with PNut).
< deleted, sent by mistake >
Not working on Mac OS 15.
I do not see any changes.
still 500ms delay after RESET to "> Prop_Chk 0 0 0 0"
Can you try to change the P2 reset method setting in the serial port preferences page (see screenshot in the release announcement post) from DTR+RTS to DTR only ?
I have try RTS only, this works never.
I have also try DTR+RTS and DTR only and we have the Problem with the 500ms delay after RESET.
The workaround is so easy:
1. make RESET with DTR and wait 50ms
2. send "> Prop_Chk 0 0 0 0"
3. when you not get the answer "Prop_Ver G" Immediately, do not close the port and try a second time step 1. and 2. and it will work.
RTS won't work with the standard prop-plug as it uses DTR to reset (it is here because some may have custom adapters that use RTS instead of DTR).
You already tested that this option doesn't work.
You can try again, keep the terminal window open and try to upload, the terminal will keep the serial port open.
BTW, I don't know if you have something in the flash memory, maybe try to disable the flash switch on the edge board, this should give 60 seconds for the serial programming window, this should work regardless of the delays introduced by the OS (if I'm intepreting the documentation correctly).
I was able to have more success in uploading to a P2 with SpinTools 46.0 running os MacOS...
I still only get a few of the debug graphic windows to work:
I get blank windows except for a few of the simple debug tests. What might you need to help debug those issues?
I have to admit that after recent issues with loading to a P@, I resoldered all of my PropPlugs and got better results. SPinTools 46.0 has helped even more.
dgately
Good.
The scope debug is not very tested because there aren't much examples to run.
The example in the documentation however should display something:
Could be some issue with the MacOS display update. The scope portion of the SPECTRO example however doesn't work here.
The main problem is that I'm not sure to understand the meaning of all the parameters and what result is expected, I tried to match the PNut display but I can't test all parameters without an example.
Arg... After my initial success with Spin Tools 0.46.0, I am not able to load compiled code to any of my P2s. I've used 3 different Prop Plugs, several cables, powered USB hub, resetting of the MacBook Pro (Apple M2 Silicon, OS version 15.3.2), etc... I've tried DTR/RTS, DTR, RTS... Automatic devices discovery ON/OFF, also... Perplexed!
I'm quite able to upload compiled code with flexprop & loadp2. How different is the method that Spin Tools uses for upload versus loadp2?
One thing to note: When the upload is started, the dialog that says it can't find the P2 displays immediately. It doesn't seem to retry.
dgately
There are two more things to test:
Keep the terminal window open, this prevents the serial port from begin open. I think that stil doesn't work because there is another delay after the reset.
Disable the flash/sd card boot (all dip switches to off, except maybe the leds). This gives a 60 seconds serial programming window that should allow any delay between the reset and when the detection command is sent.
To my point of view, loadp2 should not work, the question is what it is doing to make the serial port work ?
Maybe it is the low leve serial implmentation of the Java library, I don't know.
There is no point to retry when I already know it won't work.
Disabling the Flash/SD card boot works in allowing loading of the code! That's good for Edge cards, not so for the KISS board that I have as well.
Thanks,
dgately
I have the same Problem with Mac OS 15.
I can not disable the Flash on my Card, and Spin Tools do not work for me.
In that case, probably the only way is to invalidate the flash content so the boot falls-back to serial. I don't think there is a command to erase the flash, however if you manage to start TAQOZ (which is a problem by itself, since the trigger command has the same problem as the programming command), the command
sferaseshould work.Can you confirm that the "trick" to keep the terminal window open and upload does not work ?
Edit: I just saw another option, if you manage to pull-up P59, this seems to override flash and SD and always use the 60 seconds serial window.
Suggestion: As we have two members of the Px family, could you add the processor type in the name of the archive? I did this manually for driver demos I uploaded to ObEx. Thanks, @macca!
Sure, I'll add it in the next release.
More succcess today with keeping the terminal window open while attempting uploads. Works well for most of the time, especially on Edge board P2s. Less success with the KISS P2 board, which BTW does not have a reset button (requires closing & re-opening the terminal window in order to reset the P2).
When I was able to get the terminal window to allow bringing up TAQOZ, sferase did give slightly higher success along with or without the terminal window being open. Eventually, it resorts back to requiring the open terminal window to succeed.
And of course, most of the debug graphics either do not put up a window or put up a blank window (on MacOS). I get a better chance of graphic debug success when running on WIN 11 (emulation with Parallels Desktop & some luck in uploading).
dgately