@DarkInsanePyro said:
Line 10, "unexpected #"
Line 17, "symbol PR0 not found"
Will implement them (PRx are available for inline pasm only, not for generic pasm).
Pure PASM project makes sense not to include, but a file with mixed Spin2/PASM per the example (and in an example in the Spin2 language documentation) is valid. Handy for argument passing. Though if really need be I could alias it myself to those memory registers using org/res.
Also, PTRA and PTRB symbols don't appear to be defined (to get their register address) when used as a literal. Found a line of the spin2 interpreter it was complaining about. As an address instead of literal it works though. Simplified example:
mov PTRA, #PTRA '<-- symbol #PTRA not found
` same for PTRB, but the remaining appear to work (IJMP3, IRET3, IJMP2, IRET2, IJMP1, IRET1, PA, PB, DIRA, DIRB, OUTA, OUTB, INA, and INB)
@DarkInsanePyro said:
Also, PTRA and PTRB symbols don't appear to be defined (to get their register address) when used as a literal. Found a line of the spin2 interpreter it was complaining about. As an address instead of literal it works though. Simplified example:
mov PTRA, #PTRA '<-- symbol #PTRA not found
` same for PTRB, but the remaining appear to work (IJMP3, IRET3, IJMP2, IRET2, IJMP1, IRET1, PA, PB, DIRA, DIRB, OUTA, OUTB, INA, and INB)
Yes, PTRx are a special case because of the pre/post-increment and index variants, need to review the parser.
I have checked out your P2 Library from GitHub and added to my tests. Still need to fix some things.
Apparently it can't tell that the call to Get_TS_XY() returns two values.
2.
Another thing I noted is that within a file if you accidentally mix and match cases for a symbol, it gives an error instead of a warning. I'm actually glad I found some of these instances in my code as I prefer consistent use of upper/lower cases but my project uses several libraries which I didn't write, and I was getting all these errors, so now I'm forced to fixup all those other libraries to be able to tell if my code works. To me it might be a good idea if it points these as warnings instead of errors as the specification of Spin is not case sensitive.
3.
Please consider adding support for Object Pointers, a feature that FlexSpin already implements that apparently was proposed for Spin2 but never saw the daylight in Pnut. I use it extensively and find it very useful to overcome some limitations of Spin and method pointers.
Decided today to try out the interface, really liked the setup! I was surprised that it is case-sensitive but it did help me find and be more consistent in my typing, Prop Tools doesn’t care so it is easy to get careless.
The pop-ups for variables and methods are something I really like, along with the right side bar with all the methods, much easier way to navigate around code.
I have to figure out the Terminal window yet, I normally use PST to display and input data to the Propellor. The terminal window seems to cut off some display data at the beginning (I re-read this discussion thread and someone said a delay might work) but I haven’t been able to figure out how to enter data into the terminal window to send to the propellor. I saw the PST option on the terminal but that didn’t appear to do anything.
Anyway, I think this could easily become my favorite programming tool! I am going to play around with it some more and load P2 code in and try out Debug once I get the PST problem figured out.
Thanks you for all the work you have put into this!
@DiverBob said:
Decided today to try out the interface, really liked the setup! I was surprised that it is case-sensitive but it did help me find and be more consistent in my typing, Prop Tools doesn’t care so it is easy to get careless.
The pop-ups for variables and methods are something I really like, along with the right side bar with all the methods, much easier way to navigate around code.
I have to figure out the Terminal window yet, I normally use PST to display and input data to the Propellor. The terminal window seems to cut off some display data at the beginning (I re-read this discussion thread and someone said a delay might work) but I haven’t been able to figure out how to enter data into the terminal window to send to the propellor. I saw the PST option on the terminal but that didn’t appear to do anything.
Anyway, I think this could easily become my favorite programming tool! I am going to play around with it some more and load P2 code in and try out Debug once I get the PST problem figured out.
Thanks you for all the work you have put into this!
It my favorite tool as well , especially for the MAC, Are you using MAC OS??
I really like the real time compiler, as you said, it helps with typing consistency, as it immediately informs you of typing in rubbish.
I like how also the tabs turn RED when there is an error and any line numbers and code get highlighted in red as well, it's so easy to find and fix errors!
I really love the indentation lines!
I managed to get the serial terminal working, I am using the one built into SPINTOOLS!
Just use the FullDuplexSerial.spin program as your debug tool. refer to it as
OBJ Debug: "FullDuplexSerial"
@DiverBob said:
I have to figure out the Terminal window yet, I normally use PST to display and input data to the Propellor. The terminal window seems to cut off some display data at the beginning (I re-read this discussion thread and someone said a delay might work) but I haven’t been able to figure out how to enter data into the terminal window to send to the propellor. I saw the PST option on the terminal but that didn’t appear to do anything.
Just type it ?
Maybe I don't understand the problem, the terminal doesn't have a line input field, when focused all keys typed are sent to the serial port.
About the display data cut off, it is a known issue that I haven't yet figured out how to fix, seems that the propeller is too fast and the switch between the upload baud rate and normal terminal baud rate causes some characters to be lost. The workaround is to add a small delay before starting to send data to the serial port (just 100ms should be enough). Or use JonnyMac's startup method that waits for a key to be pressed.
The terminal drop-down selects the interpreted control codes: TTY=none, PST=Parallax Serial Terminal, ANSI=ANSI ESCape codes. Doesn't have an immediate effect on what is displayed.
Maybe with PST I can add a line input field, if that's what is expected.
I added a delay before the first transmit to the terminal and that allowed the terminal to display all the data.
I understand that the terminal doesn't have a specific line input field. I found that if I enter information from the keyboard, the characters I type in are not being reflected on the screen. However the data is being understood as I get the expected results, just not seeing the data entry. Is there something else I need to do to display the input data on the terminal window?
Edit: I’m running Windows 10
@DiverBob said:
I understand that the terminal doesn't have a specific line input field. I found that if I enter information from the keyboard, the characters I type in are not being reflected on the screen. However the data is being understood as I get the expected results, just not seeing the data entry. Is there something else I need to do to display the input data on the terminal window?
The terminal doesn't have a local echo option (I can add it), the characters should be sent back by the program.
Try to run Monitor or TAQOZ (with the terminal buttons) and you can see the echo back from the program itself.
Release version 0.21 with a number of fixes and enhancements.
Compiler fixes: generally all things reported should be fixed (method pointers reference count, call register index, multiple returns as parameters, absolute addresses, etc.)
Case sensitive symbols preference (default off to be compatible with Spin standard)
Added continue on next line ... operator
Outline view show/hide toggle
Menu command (or F5) to refresh the file browser
Added local echo and line input field toggles to the terminal window preferences
I downloaded the new version to try it out. Sadly the terminal window was not echoing the keyboard input and now it appears the terminal is not responding to the keyboard input as it did in the previous version.
I did run the same program in Prop Tool to verify the program still operated correctly.
@DiverBob said:
I downloaded the new version to try it out. Sadly the terminal window was not echoing the keyboard input and now it appears the terminal is not responding to the keyboard input as it did in the previous version.
I did run the same program in Prop Tool to verify the program still operated correctly.
I don't see problems with the terminal, I'm using Windows 11.
Can you run TAQOZ and tell me what happens ?
TAQOZ will echo the typed characters so you should see them, and if you enable local echo you should see them twice. When using the line input, the characters are echoed when you press ENTER.
Can you run TAQOZ and tell me what happens ?
TAQOZ will echo the typed characters so you should see them, and if you enable local echo you should see them twice. When using the line input, the characters are echoed when you press ENTER.
Running TAQOZ did not echo keypresses or respond
Still no keypress showing on the terminal. Where/what is the function to enable local echo?
EDIT - I just found the Local Echo option under the Preferences - I get the Input line and my input keypresses are being shown now but still no response from the robot. _The terminal also only shows a single line of text, whatever the last line that was last sent_ EDIT2 - Cancel the last remark, I was in TTY mode, changing back to PST shows multiple lines again, but still no robot response.
Also with the previous version of the IDE, even though my keypress's weren't being displayed, the terminal still generated a response from the robot output. With this version of the IDE the robot isn't responding at all. As a check, I ran the same code in the Parallax Prop Tool and it worked as expected.
Thanks for the latest update. I was able to get my demo working with nearly no changes. Awesome turnaround time. it appears all odd language constructs I use that you've added seem to be working. With that said, of course I found a few quirks.
1) The clock mode solver's value that gets compiled into address $40 seems to yield an unexpected mode when targeting 20 MHz output with 20 MHz input. Or intentionally switching to internal clock but I hope not since it isn't the same accuracy as external + PLL or external without PLL (yes, 20 MHz -> PLL -> 20 MHz is silly, I was just poking around... lol. And heavily under-clocking/under-utilizing the P2). I swear I had my demo working at 20 MHz but... I seem to be going crazy (or the internal oscillator happened to be within spec for UART to work). This also could be the allowable error being exceeded but not bailing out?
Also, more of an fyi, if I do specify an unrealistic frequency, it just... doesn't build. No error or anything indicated. It was some unrealistic value though (< 1 MHz).
2) Regarding relative paths for objs: The issue I ran into is when a library within a folder depends on another library file within the same folder. It looks in the working directory as expected (top object) but ended up throwing an error* since I have library files depend on each other.
You can't actually view what the error is since there isn't an error list. It only shows the red underline on the upper-level file but If I navigate to that file, that problematic file is suddenly is fine since now the working directory is the library's folder.
Simpliified example:
This would build if MyLibB is in the same folder as Project.spin2 (confirmed). Would it be possible to also include the file being built's directory for the obj search paths?
@DiverBob said:
Running TAQOZ did not echo keypresses or respond
Still no keypress showing on the terminal. Where/what is the function to enable local echo?
EDIT - I just found the Local Echo option under the Preferences - I get the Input line and my input keypresses are being shown now but still no response from the robot. _The terminal also only shows a single line of text, whatever the last line that was last sent_ EDIT2 - Cancel the last remark, I was in TTY mode, changing back to PST shows multiple lines again, but still no robot response.
That doesn't make sense. Are you sure you are using the correct COM port ? It can be selected from Tools -> Port and displayed on the terminal window title bar, there is no auto detection.
Activity on the prop-plug rx/tx leds when you press keys or reset to TAQOZ ?
@evanh said:
Don't use hard coded addresses. There should be clkfreq and clkmode symbols instead.
Agreed, however in this case I was looking at the memory map from the Program Information window in the IDE after building, not even loading it into the P2. This assumes Spin Tools is using the standard/latest interpreter source and initializes on boot using the compile-time generated values instead of something custom. I didn't see the interpreter source it is building off of so I assume it is a pre-built binary blob in the executable itself, so I couldn't check (easily).
With that said, it also seems going into oscillator-only mode (no PLL) [A] or rc-slow mode [B] doesn't work and yields $00000000 as well.
[A]
CON
_rcslow ' boots with rc-fast
[B]
CON
_xtlfreq = 20_000_000 ' boots with rc-fast
' no _clkfreq to indicate not to use the PLL
@DarkInsanePyro said:
1) The clock mode solver's value that gets compiled into address $40 seems to yield an unexpected mode when targeting 20 MHz output with 20 MHz input. Or intentionally switching to internal clock but I hope not since it isn't the same accuracy as external + PLL or external without PLL (yes, 20 MHz -> PLL -> 20 MHz is silly, I was just poking around... lol. And heavily under-clocking/under-utilizing the P2). I swear I had my demo working at 20 MHz but... I seem to be going crazy (or the internal oscillator happened to be within spec for UART to work). This also could be the allowable error being exceeded but not bailing out?
The clock mode and frequency calculation is a bit "experimental". In theory I'm using the code used by spin2cpp but it is an old implementation and probably it is missing something, I always use _CLKFREQ in my programs and never used the other variants. I'll try to port the code from a recent source to see if it is better. Hope to find some tests to check the implementation.
This assumes Spin Tools is using the standard/latest interpreter source and initializes on boot using the compile-time generated values instead of something custom. I didn't see the interpreter source it is building off of so I assume it is a pre-built binary blob in the executable itself, so I couldn't check (easily).
The interpreter is pre-built and embedded in the application jar file, the source is dated 2022.01.14 and seems roughly PNut v35r or v35s. It is missing the most recent changes and the weird new loader made to allow debug serial speed change or something like that, can't remember.
This version should fix a bunch of issues including the object array count evaluation, method pointer array, pre- and post-increment (or generally effects), some bitfields compile issues, strings defined as dat word/long (this prevents to correctly compile @DarkInsanePyro demos).
Added an initial support for relative paths in object file names. This is a bit experimental and should work reliably with descendent paths, ascending paths (like ../lib/myobject) may not work as expected.
Added an experimental PASM include pseudo-instruction with which it is possible to include CON/DAT only sources to the current DAT source. It works like the file instruction but the source is compiled. The idea was to be able to reuse PASM code in DAT-only projects.
Reviewed and updated the clock calculation code, hope it is correct now.
Also added an experimental version with a self-update feature, provided by the update4j package. This is currently separated from the "regular" version as I'm not sure how reliable it is. There is a new menu item under Help to check for updates, if available it asks to download and then asks to restart the application to apply updates. These versions have the -update suffix in the package.
@jrullan said:
Thanks for the update. Found this issue. Looks like it doesn't recognize the argument.
Actually, it doesn't understand the method pointer argument and thinks it is a method call, which doesn't have return values so it fails...
This may be a good chance of testing the self-update feature. I have fixed the issue and released the updated jar. If you have the -update variant installed, try Help -> Check for Updates...
@jrullan said:
Thanks for the update. Found this issue. Looks like it doesn't recognize the argument.
Actually, it doesn't understand the method pointer argument and thinks it is a method call, which doesn't have return values so it fails...
This may be a good chance of testing the self-update feature. I have fixed the issue and released the updated jar. If you have the -update variant installed, try Help -> Check for Updates...
Ha! Update worked! The only thing is that it asked if I wanted to restart the application, and it closed it but did not restarted it automatically, but that's not a big issue.
Now, the fix did work for the example code I showed above.
However there's a variant of the same issue I didn't catch previously that still persists:
@macca said:
Released version 0.22.
...
Also added an experimental version with a self-update feature, provided by the update4j package. This is currently separated from the "regular" version as I'm not sure how reliable it is. There is a new menu item under Help to check for updates, if available it asks to download and then asks to restart the application to apply updates. These versions have the -update suffix in the package.
I downloaded, extracted and tried to run both versions (no-update & self-update) on latest macOS (Ventura 13.2.1)... The no-update version runs, but the self-update version fails to launch. To test the difference in outcomes I launched them from the command line. The no-update versions runs without any errors, but does display a few errors on quit (has always done this, but the app runs fine). The self-update version quickly displays the following (see below) and fails. The Spin Tools IDE quickly shows its icon in the dock before disappearing...
% ./JavaAppLauncher
***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread
Exception in thread "Thread-2" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.update4j.service.DefaultLauncher.run(DefaultLauncher.java:123)
at org.update4j.ConfigImpl.lambda$25(ConfigImpl.java:693)
at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at org.update4j.service.DefaultLauncher.run(DefaultLauncher.java:118)
... 2 more
Caused by: org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(SWT.java:4918)
at org.eclipse.swt.SWT.error(SWT.java:4833)
at org.eclipse.swt.SWT.error(SWT.java:4804)
at org.eclipse.swt.widgets.Display.error(Display.java:1209)
at org.eclipse.swt.widgets.Display.createDisplay(Display.java:960)
at org.eclipse.swt.widgets.Display.create(Display.java:944)
at org.eclipse.swt.graphics.Device.<init>(Device.java:132)
at org.eclipse.swt.widgets.Display.<init>(Display.java:798)
at org.eclipse.swt.widgets.Display.<init>(Display.java:789)
at classpath//com.maccasoft.propeller.SpinTools.main(SpinTools.java:2430)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
... 4 more
Java version info:
% java --version
java 19.0.2 2023-01-17
Java(TM) SE Runtime Environment (build 19.0.2+7-44)
Java HotSpot(TM) 64-Bit Server VM (build 19.0.2+7-44, mixed mode, sharing)
@jrullan said:
Ha! Update worked! The only thing is that it asked if I wanted to restart the application, and it closed it but did not restarted it automatically, but that's not a big issue.
Good, yes that's expected (the text may not be clear, the program won't restart by itself).
However there's a variant of the same issue I didn't catch previously that still persists:
I fixed that however it showed another issue: the method is not counted as used and is removed from the binary (if not called directly somewhere else).
Comments
Sorry, my mistake -- I must have misinterpreted an error I saw the other day.
Pure PASM project makes sense not to include, but a file with mixed Spin2/PASM per the example (and in an example in the Spin2 language documentation) is valid. Handy for argument passing. Though if really need be I could alias it myself to those memory registers using org/res.
Also, PTRA and PTRB symbols don't appear to be defined (to get their register address) when used as a literal. Found a line of the spin2 interpreter it was complaining about. As an address instead of literal it works though. Simplified example:
Yes, PTRx are a special case because of the pre/post-increment and index variants, need to review the parser.
I have checked out your P2 Library from GitHub and added to my tests. Still need to fix some things.
Hello @macca While testing found the following:
1.
Apparently it can't tell that the call to Get_TS_XY() returns two values.
2.
Another thing I noted is that within a file if you accidentally mix and match cases for a symbol, it gives an error instead of a warning. I'm actually glad I found some of these instances in my code as I prefer consistent use of upper/lower cases but my project uses several libraries which I didn't write, and I was getting all these errors, so now I'm forced to fixup all those other libraries to be able to tell if my code works. To me it might be a good idea if it points these as warnings instead of errors as the specification of Spin is not case sensitive.
3.
Please consider adding support for Object Pointers, a feature that FlexSpin already implements that apparently was proposed for Spin2 but never saw the daylight in Pnut. I use it extensively and find it very useful to overcome some limitations of Spin and method pointers.
Btw, great work!!!
Decided today to try out the interface, really liked the setup! I was surprised that it is case-sensitive but it did help me find and be more consistent in my typing, Prop Tools doesn’t care so it is easy to get careless.
The pop-ups for variables and methods are something I really like, along with the right side bar with all the methods, much easier way to navigate around code.
I have to figure out the Terminal window yet, I normally use PST to display and input data to the Propellor. The terminal window seems to cut off some display data at the beginning (I re-read this discussion thread and someone said a delay might work) but I haven’t been able to figure out how to enter data into the terminal window to send to the propellor. I saw the PST option on the terminal but that didn’t appear to do anything.
Anyway, I think this could easily become my favorite programming tool! I am going to play around with it some more and load P2 code in and try out Debug once I get the PST problem figured out.
Thanks you for all the work you have put into this!
It my favorite tool as well , especially for the MAC, Are you using MAC OS??
I really like the real time compiler, as you said, it helps with typing consistency, as it immediately informs you of typing in rubbish.
I like how also the tabs turn RED when there is an error and any line numbers and code get highlighted in red as well, it's so easy to find and fix errors!
I really love the indentation lines!
I managed to get the serial terminal working, I am using the one built into SPINTOOLS!
Just use the FullDuplexSerial.spin program as your debug tool. refer to it as
OBJ Debug: "FullDuplexSerial"
Chip recently added a new feature to the Spin2 interpreter: You can continue onto the next line by putting ... at the end of the current line
For the moment, one has to use a block comment to get the same effect in Spin Tools
Just type it ?
Maybe I don't understand the problem, the terminal doesn't have a line input field, when focused all keys typed are sent to the serial port.
About the display data cut off, it is a known issue that I haven't yet figured out how to fix, seems that the propeller is too fast and the switch between the upload baud rate and normal terminal baud rate causes some characters to be lost. The workaround is to add a small delay before starting to send data to the serial port (just 100ms should be enough). Or use JonnyMac's startup method that waits for a key to be pressed.
The terminal drop-down selects the interpreted control codes: TTY=none, PST=Parallax Serial Terminal, ANSI=ANSI ESCape codes. Doesn't have an immediate effect on what is displayed.
Maybe with PST I can add a line input field, if that's what is expected.
I added a delay before the first transmit to the terminal and that allowed the terminal to display all the data.
I understand that the terminal doesn't have a specific line input field. I found that if I enter information from the keyboard, the characters I type in are not being reflected on the screen. However the data is being understood as I get the expected results, just not seeing the data entry. Is there something else I need to do to display the input data on the terminal window?
Edit: I’m running Windows 10
The terminal doesn't have a local echo option (I can add it), the characters should be sent back by the program.
Try to run Monitor or TAQOZ (with the terminal buttons) and you can see the echo back from the program itself.
The software at the other end should echo back if such is desired.
Release version 0.21 with a number of fixes and enhancements.
Hello @macca, found these other issues
1. Regarding the enumerations in Spin2:
2. Regarding method pointers (This is an array of method pointers. This syntax is supported in both Pnut and FlexSpin)
This is in version 0.21
That's not the enumeration, seems the object count is evaluated before the constants, which is obviously wrong.
That will be more complicated, the parser can't handle that syntax. Need to do some refactorings.
Gotchas encountered in 0.21.0
Suggestion: If possible, add terminal baud rate to the Tools menu and push to the terminal when being opened.
I downloaded the new version to try it out. Sadly the terminal window was not echoing the keyboard input and now it appears the terminal is not responding to the keyboard input as it did in the previous version.
I did run the same program in Prop Tool to verify the program still operated correctly.
I don't see problems with the terminal, I'm using Windows 11.
Can you run TAQOZ and tell me what happens ?
TAQOZ will echo the typed characters so you should see them, and if you enable local echo you should see them twice. When using the line input, the characters are echoed when you press ENTER.
I see... and it seems a Windows-only issue... that's crazy, never noticed before!
Found the bug in SWT: https://bugs.eclipse.org/bugs/show_bug.cgi?id=577190
Running TAQOZ did not echo keypresses or respond
Still no keypress showing on the terminal. Where/what is the function to enable local echo?
EDIT - I just found the Local Echo option under the Preferences - I get the Input line and my input keypresses are being shown now but still no response from the robot. _The terminal also only shows a single line of text, whatever the last line that was last sent_ EDIT2 - Cancel the last remark, I was in TTY mode, changing back to PST shows multiple lines again, but still no robot response.
Also with the previous version of the IDE, even though my keypress's weren't being displayed, the terminal still generated a response from the robot output. With this version of the IDE the robot isn't responding at all. As a check, I ran the same code in the Parallax Prop Tool and it worked as expected.
@macca
Thanks for the latest update. I was able to get my demo working with nearly no changes. Awesome turnaround time. it appears all odd language constructs I use that you've added seem to be working. With that said, of course I found a few quirks.
1) The clock mode solver's value that gets compiled into address $40 seems to yield an unexpected mode when targeting 20 MHz output with 20 MHz input. Or intentionally switching to internal clock but I hope not since it isn't the same accuracy as external + PLL or external without PLL (yes, 20 MHz -> PLL -> 20 MHz is silly, I was just poking around... lol. And heavily under-clocking/under-utilizing the P2). I swear I had my demo working at 20 MHz but... I seem to be going crazy (or the internal oscillator happened to be within spec for UART to work). This also could be the allowable error being exceeded but not bailing out?
Also, more of an fyi, if I do specify an unrealistic frequency, it just... doesn't build. No error or anything indicated. It was some unrealistic value though (< 1 MHz).
2) Regarding relative paths for objs: The issue I ran into is when a library within a folder depends on another library file within the same folder. It looks in the working directory as expected (top object) but ended up throwing an error* since I have library files depend on each other.
Simpliified example:
This would build if MyLibB is in the same folder as Project.spin2 (confirmed). Would it be possible to also include the file being built's directory for the obj search paths?
Don't use hard coded addresses. There should be
clkfreqandclkmodesymbols instead.That doesn't make sense. Are you sure you are using the correct COM port ? It can be selected from Tools -> Port and displayed on the terminal window title bar, there is no auto detection.
Activity on the prop-plug rx/tx leds when you press keys or reset to TAQOZ ?
Agreed, however in this case I was looking at the memory map from the Program Information window in the IDE after building, not even loading it into the P2. This assumes Spin Tools is using the standard/latest interpreter source and initializes on boot using the compile-time generated values instead of something custom. I didn't see the interpreter source it is building off of so I assume it is a pre-built binary blob in the executable itself, so I couldn't check (easily).
With that said, it also seems going into oscillator-only mode (no PLL) [A] or rc-slow mode [B] doesn't work and yields $00000000 as well.
[A]
[B]
The clock mode and frequency calculation is a bit "experimental". In theory I'm using the code used by spin2cpp but it is an old implementation and probably it is missing something, I always use _CLKFREQ in my programs and never used the other variants. I'll try to port the code from a recent source to see if it is better. Hope to find some tests to check the implementation.
The interpreter is pre-built and embedded in the application jar file, the source is dated 2022.01.14 and seems roughly PNut v35r or v35s. It is missing the most recent changes and the weird new loader made to allow debug serial speed change or something like that, can't remember.
Released version 0.22.
This version should fix a bunch of issues including the object array count evaluation, method pointer array, pre- and post-increment (or generally effects), some bitfields compile issues, strings defined as dat word/long (this prevents to correctly compile @DarkInsanePyro demos).
Added an initial support for relative paths in object file names. This is a bit experimental and should work reliably with descendent paths, ascending paths (like ../lib/myobject) may not work as expected.
Added an experimental PASM include pseudo-instruction with which it is possible to include CON/DAT only sources to the current DAT source. It works like the file instruction but the source is compiled. The idea was to be able to reuse PASM code in DAT-only projects.
Reviewed and updated the clock calculation code, hope it is correct now.
Also added an experimental version with a self-update feature, provided by the update4j package. This is currently separated from the "regular" version as I'm not sure how reliable it is. There is a new menu item under Help to check for updates, if available it asks to download and then asks to restart the application to apply updates. These versions have the -update suffix in the package.
@macca
Thanks for the update. Found this issue. Looks like it doesn't recognize the argument.
The argument is the address of a method defined in the same object later on
Actually, it doesn't understand the method pointer argument and thinks it is a method call, which doesn't have return values so it fails...
This may be a good chance of testing the self-update feature. I have fixed the issue and released the updated jar. If you have the -update variant installed, try Help -> Check for Updates...
Ha! Update worked! The only thing is that it asked if I wanted to restart the application, and it closed it but did not restarted it automatically, but that's not a big issue.
Now, the fix did work for the example code I showed above.
However there's a variant of the same issue I didn't catch previously that still persists:
I downloaded, extracted and tried to run both versions (no-update & self-update) on latest macOS (Ventura 13.2.1)... The no-update version runs, but the self-update version fails to launch. To test the difference in outcomes I launched them from the command line. The no-update versions runs without any errors, but does display a few errors on quit (has always done this, but the app runs fine). The self-update version quickly displays the following (see below) and fails. The Spin Tools IDE quickly shows its icon in the dock before disappearing...
% ./JavaAppLauncher ***WARNING: Display must be created on main thread due to Cocoa restrictions. Use vmarg -XstartOnFirstThread Exception in thread "Thread-2" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.update4j.service.DefaultLauncher.run(DefaultLauncher.java:123) at org.update4j.ConfigImpl.lambda$25(ConfigImpl.java:693) at java.base/java.lang.Thread.run(Thread.java:1589) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.update4j.service.DefaultLauncher.run(DefaultLauncher.java:118) ... 2 more Caused by: org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4918) at org.eclipse.swt.SWT.error(SWT.java:4833) at org.eclipse.swt.SWT.error(SWT.java:4804) at org.eclipse.swt.widgets.Display.error(Display.java:1209) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:960) at org.eclipse.swt.widgets.Display.create(Display.java:944) at org.eclipse.swt.graphics.Device.<init>(Device.java:132) at org.eclipse.swt.widgets.Display.<init>(Display.java:798) at org.eclipse.swt.widgets.Display.<init>(Display.java:789) at classpath//com.maccasoft.propeller.SpinTools.main(SpinTools.java:2430) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) ... 4 moreJava version info:
dgately
Good, yes that's expected (the text may not be clear, the program won't restart by itself).
I fixed that however it showed another issue: the method is not counted as used and is removed from the binary (if not called directly somewhere else).