I've been working with Chips FFS driver and wanted to make sure what I was doing with Propeller Tool also played nicely in Spin Tools IDE. Out of the blue, the indentation lines seem to be off (by one full line height). I tried changing fonts but that didn't fix it.
Thanks
-- Jon
PS: How do you think Ferrari will do in Singapore this weekend?
I've been working with Chips FFS driver and wanted to make sure what I was doing with Propeller Tool also played nicely in Spin Tools IDE. Out of the blue, the indentation lines seem to be off (by one full line height). I tried changing fonts but that didn't fix it.
Thanks
-- Jon
PS: How do you think Ferrari will do in Singapore this weekend?
Thought it was related but after testing may be different indent render issue (noticed a bit ago but have been distracted lately). Editing a block comment screws up the indent lines. Saving the file, closing, and re-opening fixes it until another line is added to a block comment above any source. Taken from the latest from the master branch on github (50c7d7a).
That's a weird thing, there is also an issue on GitHub https://github.com/maccasoft/spin-tools/issues/7 but so far i wasn't able to reproduce.
I guess that somehow a newline character is not recognized and the indentation lines are not aligned.
Released version 0.31.0 with some bugfixes, including the indentation lines bug.
The interpreter is updated to the latest PNut v40 (2023.09.21) with the new repeat with syntax implemented.
This release requires the Java 17 runtime because the newest SWT library requires it.
As an experiment, there are packages that includes a stripped-down jre built with jlink that should run without installing anything else (with the -jre in the name).
Requests for the terminal (PST mode):
-- allow it to scroll back like PST
-- backspace (8) seems to be implemented as cursor-left; the cursor moves but the last character is not erased
I thought the line continuation feature had been implemented -- or is it a case of me splitting a long string across lines? This code does work in Propeller Tool and FlexProp.
@JonnyMac said:
Requests for the terminal (PST mode):
-- allow it to scroll back like PST
Yes, this is on the todo-list since the beginning...
-- backspace (8) seems to be implemented as cursor-left; the cursor moves but the last character is not erased
Yes, this is how it works for other terminals, the application should erase the character (or do something else). I can change it to automatically erase the character in PST-only, I guess this how it works there (seems I can't find the PST codes documentation...).
Well, darn, I just ran into this.
I thought the line continuation feature had been implemented -- or is it a case of me splitting a long string across lines? This code does work in Propeller Tool and FlexProp.
The line continuation works, however I found this is the same CR/LF issue that caused the indentation line draw issue on Windows, the first CR triggers the line end but also the next LF resulting in a blank line that breaks the line continuation. Will fix soon.
debug(`SCOPE_XY MyXY SIZE 160 COLOR black black RANGE 80_000 SAMPLES 0 'MSE') ' plot MSE for each training cycle
repeat TrainingCycle from 1 to POSX-1 ' Begin training, approx. 6ms per loop
debug(`MyXY `(TrainingCycle, fError))
The first debug is ok but the 2nd has an error, doesn't like the 2nd variable fError.
Both these work in pnut 41 and propeller tool.
Note: These aren't working examples but just enough lines to show the issue.
I also got a lot of exception dialogs on shutting the ide down. The attached file contains the exception stack.
Spin Tools IDE can't invoke any of the graphical debugging features from PNut/Propeller Tool. It can use basic debug statements through its own debug pane.
I have noticed, though, that when switching back to Propeller Tool after running Spin Tools IDE -- it's as if it's not releasing the serial port when exiting.
What I really miss in SpinTool is a way to use RTS for reset instead of DTR. PropTool has a Preference setting for that. I always have this set to RTS & DTR, and never had problems. So maybe you can just switch RTS together with DTR all the times.
@ngeneer said:
Any chance of getting a 32bit ARM version for the RPi 400?
Unfortunately, the SWT library is only available for 64-bit ARM. I don't know if it's possible to recompile it for 32 bit, but even if so, it's not officially supported so any bugs/issues won't be fixed.
Sooner or later, I'd like to test it on a 64-bit Raspberry Pi OS.
@pik33 I had initially installed it 64bit, but ran into issues early on where something in the RP2040 SDK and tools worked better/only worked in 32 bit. So, I reverted to 32 bit.
Hi All, I am just trying out spin tools ide for the first time, @JonnyMac recommended I try it in another discussion.
I really like the look and feel of it, much nicer than Propeller tool in my opinion.
Good Job @macca
My code worked ok with Propeller tool but i have an error with spin tools and I have no idea why.
The code is writen for the P1 and uses "PST Debug Lite" because I needed 5 serial ports so I made this my debugger window along with a slightly modified version of "fullDuplexSerial4port" for the other 4 ports.
The problem is, it doesn't like "PST Debug Lite"
Looking in PST Debug Lite, it has 2 warning about unused variables, which are clearly used just below:-
And it gives a syntax error on the line starting "repeat long[strOffsetAddr] from 0 to strLength"
I can see nothing wrong here and Propeller tool has been working fine with it for years?
Any hints or advice on how to proceed here?
I could probably replace "PST Debug Lite" with something else if needed but I thought it should just work?
@lab_ges said:
And it gives a syntax error on the line starting "repeat long[strOffsetAddr] from 0 to strLength"
Yes, it doesn't like that long[...] syntax, will fix it soon.
The warning are just informative and cause no harm in this case, probably I have missed the reference count somewhere, will fix this too.
Hi, @macca, thanks for your work, it must have taken you a long time to get this project this far.
OK to the informative warnings, that makes sense.
I will have to continue using Propeller tool for now as I am not able to proceed because all options just say [Program has Errors.] and stops till the Syntax problem is corrected.
I will keep an eye on this and look back once this error disappears.
The other day on the live event I asked about an issue I am having. I am not a compiler guy. My code 197,000 Bytes compiled and it compiles clean on all the current spin compilers. However it will only run when compiled on pnut or propeller tool. Spin tools and Flexprop compile it and upload it but it appears to freeze / lockup as soon as it starts. It was mentioned by @Wuerfel_21 I believe that it may be a stack issue or an issue of space; byte code vs assembly. I am using some home made hardware and some off the shelf hardware so It may be an issue for you to run the code. I am willing to provide any info needed. I am on a mac and I have to borrow a PC in order to get workable code in the prop. Is there anything I can do to provide you info to see why this is happening ?
Stack is usually only an issue if launching multiple cogs running full Spin objects in each. Most objects don't do this, they will either run inline on the same cog or spin off something as fast pasm in its own cog.
Compiled native machine code will be bigger than compiled bytecode but you've got a lot of space left so this shouldn't be an issue. Each compiler should be reporting the binary size as well, so can be checked.
Flexspin can compile to bytecode as well. Change the compiler option from -2 to -2nu.
@"Greg LaPolla" said:
The other day on the live event I asked about an issue I am having. I am not a compiler guy. My code 197,000 Bytes compiled and it compiles clean on all the current spin compilers. However it will only run when compiled on pnut or propeller tool. Spin tools and Flexprop compile it and upload it but it appears to freeze / lockup as soon as it starts. It was mentioned by @Wuerfel_21 I believe that it may be a stack issue or an issue of space; byte code vs assembly. I am using some home made hardware and some off the shelf hardware so It may be an issue for you to run the code. I am willing to provide any info needed. I am on a mac and I have to borrow a PC in order to get workable code in the prop. Is there anything I can do to provide you info to see why this is happening ?
You can send me the source code privately, if you want.
I don't run the code, I just compile and compare the binary output, if it is byte-by-byte equal it must run correctly.
You can do the same:
Compile and generate the binary with PNut (make sure to use the latest version)
Compile and generate the binary with Spin Tools IDE (F8 -> Save Binary)
Compare the two binary files
Don't enable the debug, Spin Tools IDE doesn't fully support the debug statements and there may be differences with the debug stub used by PNut.
If the files are of different size there may be some issue with the bytecode generation that may be hard to fix without the source code.
If the files are same size but some bytes are different, there are chances that the problem may be identified by looking at the listing generated by Spin Tools IDE at around the location that differs. There may be some minor differences caused by how expressions are compiled / evaluated that should not cause any issue.
Macca,
Thanks for Spin Tools. I just started using it to get around IT spawned issues at work that prevent Propeller Tool from working. It does so brilliantly because of the ability to select the library path.
Love the code analysis function, but I seem to have found a problem,
The attached code compiles in Propeller tool, but shows a red tab and will not compile in Spin Tools. There is no other indication of error except the red tab color.
I have narrowed down the problem to line 32. If i remove the array reference from the first 'Times' variable, the red tab goes away and it will compile. (But clearly won't work as intended that way)
Warning: the attached code is my attempt to debug my use of use Phil Pilgrims background button monitor idea and see how tight I can make timing with PLC-generated pulses.. As-is the attached code does nothing useful, and may not work at all. It does, however illustrate my problem.
Comments
Is it possible to run a Debug session as a separate window instead of the bottom of the main window?
No, the window is not detachable.
Marco,
I've been working with Chips FFS driver and wanted to make sure what I was doing with Propeller Tool also played nicely in Spin Tools IDE. Out of the blue, the indentation lines seem to be off (by one full line height). I tried changing fonts but that didn't fix it.
Thanks
-- Jon
PS: How do you think Ferrari will do in Singapore this weekend?
Thought it was related but after testing may be different indent render issue (noticed a bit ago but have been distracted lately). Editing a block comment screws up the indent lines. Saving the file, closing, and re-opening fixes it until another line is added to a block comment above any source. Taken from the latest from the master branch on github (50c7d7a).
@JonnyMac @DarkInsanePyro
That's a weird thing, there is also an issue on GitHub https://github.com/maccasoft/spin-tools/issues/7 but so far i wasn't able to reproduce.
I guess that somehow a newline character is not recognized and the indentation lines are not aligned.
Will do more tests.
Released version 0.31.0 with some bugfixes, including the indentation lines bug.
The interpreter is updated to the latest PNut v40 (2023.09.21) with the new
repeat withsyntax implemented.This release requires the Java 17 runtime because the newest SWT library requires it.
As an experiment, there are packages that includes a stripped-down jre built with jlink that should run without installing anything else (with the -jre in the name).
Thanks Marco.
Requests for the terminal (PST mode):
-- allow it to scroll back like PST
-- backspace (8) seems to be implemented as cursor-left; the cursor moves but the last character is not erased
Well, darn, I just ran into this.
I thought the line continuation feature had been implemented -- or is it a case of me splitting a long string across lines? This code does work in Propeller Tool and FlexProp.
Yes, this is on the todo-list since the beginning...
Yes, this is how it works for other terminals, the application should erase the character (or do something else). I can change it to automatically erase the character in PST-only, I guess this how it works there (seems I can't find the PST codes documentation...).
The line continuation works, however I found this is the same CR/LF issue that caused the indentation line draw issue on Windows, the first CR triggers the line end but also the next LF resulting in a blank line that breaks the line continuation. Will fix soon.
Release version 0.32.0 with the line continuation and backspace fixes and the Spin2 interpreter update that fixes the floating point operators.
Thank you, Marco.
Has anyone had stability issues with the latest release ? I have experienced freezing, crashing and complete lockups.
I am running MAC OS 13.5.2
Couple of issues spinide 0.32 complains about
Unary floating point -ve, e.g.
and debug scope_xy, e.g.
debug(`SCOPE_XY MyXY SIZE 160 COLOR black black RANGE 80_000 SAMPLES 0 'MSE') ' plot MSE for each training cycle repeat TrainingCycle from 1 to POSX-1 ' Begin training, approx. 6ms per loop debug(`MyXY `(TrainingCycle, fError))The first debug is ok but the 2nd has an error, doesn't like the 2nd variable fError.
Both these work in pnut 41 and propeller tool.
Note: These aren't working examples but just enough lines to show the issue.
I also got a lot of exception dialogs on shutting the ide down. The attached file contains the exception stack.
Tim
Spin Tools IDE can't invoke any of the graphical debugging features from PNut/Propeller Tool. It can use basic debug statements through its own debug pane.
I have noticed, though, that when switching back to Propeller Tool after running Spin Tools IDE -- it's as if it's not releasing the serial port when exiting.
Dear Macca,
now Spin Tools load and work perfectly on my M1-based MacBook Air.
Thanks!!!
Carlo
Good!
Are you using the package that includes the java runtime ?
Ciao macca
What I really miss in SpinTool is a way to use RTS for reset instead of DTR. PropTool has a Preference setting for that. I always have this set to RTS & DTR, and never had problems. So maybe you can just switch RTS together with DTR all the times.
Andy
Ciao macca!
Yes, exactly, I use the jre version.
I'll keep you informed, it is running flawlessly up to now.
Carlo
Any chance of getting a 32bit ARM version for the RPi 400?
Unfortunately, the SWT library is only available for 64-bit ARM. I don't know if it's possible to recompile it for 32 bit, but even if so, it's not officially supported so any bugs/issues won't be fixed.
Sooner or later, I'd like to test it on a 64-bit Raspberry Pi OS.
However RPi400 has a 64-bit CPU and new versions of Raspbery Pi OS are 64-bit too.
@macca understood.. thank you.
@pik33 I had initially installed it 64bit, but ran into issues early on where something in the RP2040 SDK and tools worked better/only worked in 32 bit. So, I reverted to 32 bit.
Hi All, I am just trying out spin tools ide for the first time, @JonnyMac recommended I try it in another discussion.
I really like the look and feel of it, much nicer than Propeller tool in my opinion.
Good Job @macca
My code worked ok with Propeller tool but i have an error with spin tools and I have no idea why.
The code is writen for the P1 and uses "PST Debug Lite" because I needed 5 serial ports so I made this my debugger window along with a slightly modified version of "fullDuplexSerial4port" for the other 4 ports.
The problem is, it doesn't like "PST Debug Lite"
Looking in PST Debug Lite, it has 2 warning about unused variables, which are clearly used just below:-
And it gives a syntax error on the line starting "repeat long[strOffsetAddr] from 0 to strLength"
I can see nothing wrong here and Propeller tool has been working fine with it for years?
Any hints or advice on how to proceed here?
I could probably replace "PST Debug Lite" with something else if needed but I thought it should just work?
Yes, it doesn't like that long[...] syntax, will fix it soon.
The warning are just informative and cause no harm in this case, probably I have missed the reference count somewhere, will fix this too.
Hi, @macca, thanks for your work, it must have taken you a long time to get this project this far.
OK to the informative warnings, that makes sense.
I will have to continue using Propeller tool for now as I am not able to proceed because all options just say [Program has Errors.] and stops till the Syntax problem is corrected.
I will keep an eye on this and look back once this error disappears.
@macca,
The other day on the live event I asked about an issue I am having. I am not a compiler guy. My code 197,000 Bytes compiled and it compiles clean on all the current spin compilers. However it will only run when compiled on pnut or propeller tool. Spin tools and Flexprop compile it and upload it but it appears to freeze / lockup as soon as it starts. It was mentioned by @Wuerfel_21 I believe that it may be a stack issue or an issue of space; byte code vs assembly. I am using some home made hardware and some off the shelf hardware so It may be an issue for you to run the code. I am willing to provide any info needed. I am on a mac and I have to borrow a PC in order to get workable code in the prop. Is there anything I can do to provide you info to see why this is happening ?
Stack is usually only an issue if launching multiple cogs running full Spin objects in each. Most objects don't do this, they will either run inline on the same cog or spin off something as fast pasm in its own cog.
Compiled native machine code will be bigger than compiled bytecode but you've got a lot of space left so this shouldn't be an issue. Each compiler should be reporting the binary size as well, so can be checked.
Flexspin can compile to bytecode as well. Change the compiler option from
-2to-2nu.You can send me the source code privately, if you want.
I don't run the code, I just compile and compare the binary output, if it is byte-by-byte equal it must run correctly.
You can do the same:
Don't enable the debug, Spin Tools IDE doesn't fully support the debug statements and there may be differences with the debug stub used by PNut.
If the files are of different size there may be some issue with the bytecode generation that may be hard to fix without the source code.
If the files are same size but some bytes are different, there are chances that the problem may be identified by looking at the listing generated by Spin Tools IDE at around the location that differs. There may be some minor differences caused by how expressions are compiled / evaluated that should not cause any issue.
Macca,
Thanks for Spin Tools. I just started using it to get around IT spawned issues at work that prevent Propeller Tool from working. It does so brilliantly because of the ability to select the library path.
Love the code analysis function, but I seem to have found a problem,
The attached code compiles in Propeller tool, but shows a red tab and will not compile in Spin Tools. There is no other indication of error except the red tab color.
I have narrowed down the problem to line 32. If i remove the array reference from the first 'Times' variable, the red tab goes away and it will compile. (But clearly won't work as intended that way)
Warning: the attached code is my attempt to debug my use of use Phil Pilgrims background button monitor idea and see how tight I can make timing with PLC-generated pulses.. As-is the attached code does nothing useful, and may not work at all. It does, however illustrate my problem.
Thanks!
The problem is in your slightly unwieldy case statement -- if you comment it out, the red tab goes away.
You can use if-then to fix that code.
if (count => minPulse) and (count < times[0]) io.pulse_out(Led26, 50_000) elseif (count => times[0]) and (count < times[1]) repeat io.pulse_out(Led26, 50_000) waitcnt(cnt + ms * 50)