@lab_ges said:
Thanks for the reply @macca, Great program you have here!
Thank you.
Hi I am running Windows 11 Pro.
Ok, I have Windows 11 (Home) on the laptop but that doesn't have a displayport connector.
I was using the PC and Spin tools this morning with no problems.
I turned off the PC, replaced the cables and adapters and turned the PC back on, the problems occured streight away, in that I couldn't see the terminal window, it took a bit longer to findout about the Find Window.
Nothing else has changed that i know about but it is Windows, so who knows?, but there were no updates waiting to be loaded when I turned the PC off.
All I can think of is that the connection enabled a specific driver section, with a possible change in the resolution, what this has to do with the window positioning is unknown.
Unfortunately I don't think I can do much to fix that. Eclipse released the usual update few days ago, I'll try to see if there are changes in the SWT library that may have something to do with similar issues.
Is there a place where you store the window locations for these windows, it seems to have corrupted that location wherever it is, I am unable to use search at the moment just nothing happens.
The preferences are stored in a file named .spin-tools (starts with a dot) in the home directory.
It is a json-formatted text file so you can open it with any text editor.
It stores the window positions for the main window, terminal and the search dialog. All other windows are opened in the default position that is centered related to the main window.
You can safely delete (or rename) the file, it will be created at startup with the default values.
Hi @macca,
I plugged the origional cables back in and the Find window imediately came back.
It was on the Left Monitor and the Spin Tools IDE was on the right monitor, where I normally use it.
I dragged the windows back to the right windows with the Spin Tools IDE and closed the program and swapped the Display Port cables back in.
I re-opened Spin Tools IDE and Find is now working normally.
I don't know why or how this happened but it is definately something to do with HDMI V. Display port.
Thanks for your work on this IDE, it works really well.
@lab_ges said:
I plugged the origional cables back in and the Find window imediately came back.
It was on the Left Monitor and the Spin Tools IDE was on the right monitor, where I normally use it.
I dragged the windows back to the right windows with the Spin Tools IDE and closed the program and swapped the Display Port cables back in.
I re-opened Spin Tools IDE and Find is now working normally.
I don't know why or how this happened but it is definately something to do with HDMI V. Display port.
Interesting, maybe the direct DP connection changed how windows and dialogs are mapped to the monitors.
Glad you fixed it.
Thanks for your work on this IDE, it works really well.
@lab_ges You may want to check if there is a scaling difference between the monitors (after changing the cables) in Windows. Look at the "Make everything bigger" setting under display.
@ke4pjw said:
@lab_ges You may want to check if there is a scaling difference between the monitors (after changing the cables) in Windows. Look at the "Make everything bigger" setting under display.
I checked the scaling and it monitor resolution.
Scaling is at 100% & monitor resolution is set at the Maximun so both are unchanged from before.
Guess this goes in the too hard basket, changing the cable types partway through isn't something that would happen too often.
Renamed bytes/words/longs methods to byte/word/long (PNut_v43)
Implemented %"Text" constant syntax (PNut_v43)
Several other P1 and P2 compiler fixes
Added an experimental Raspberry Pi package for 64-bit only OS. Not much tested but seems to work, at least on the Pi 5 with bookworm (debian 12) OS. Should also work on the Pi 3, 4 and 400 provided you installed the 64 bit version OS.
Hi Macca, I tested the latest update (0.34.0) to see whether the upload to flash always works properly with P1. Unfortunately I have to report that it is not much better than with v0.33.0. despite the increase in timeout. About only 25% goes well.
To investigate whether I can discover, I placed an analyzer on the I2C, attached you can find in word the differences between right and wrong.
I hoop the pictures are clear. When things go wrong, an extra negative pulse always appears at the end!
I can't judge this further, but maybe this will be of some use to you.
@"Rob v.d. berg" said:
Hi Macca, I tested the latest update (0.34.0) to see whether the upload to flash always works properly with P1. Unfortunately I have to report that it is not much better than with v0.33.0. despite the increase in timeout. About only 25% goes well.
To investigate whether I can discover, I placed an analyzer on the I2C, attached you can find in word the differences between right and wrong.
I hoop the pictures are clear. When things go wrong, an extra negative pulse always appears at the end!
I can't judge this further, but maybe this will be of some use to you.
All I can guess from the pictures is that the write takes less than 5 seconds, the current timeout should be 10 seconds. To me, it seems more an hardware problem of some kind (what's that extra pulse ? seems it can't write the last block ?), but if Propeller Tools works I have absolutely no idea what may be wrong.
@macca said:
Added an experimental Raspberry Pi package for 64-bit only OS. Not much tested but seems to work, at least on the Pi 5 with bookworm (debian 12) OS. Should also work on the Pi 3, 4 and 400 provided you installed the 64 bit version OS.
Not able to run on RPi5, running with the following versions/commands:
pi@rpi-5:~ $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
pi@rpi-5:~/spin-tools $ java --version
openjdk 17.0.9 2023-10-17
OpenJDK Runtime Environment (build 17.0.9+9-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.9+9-Debian-1deb12u1, mixed mode)
pi@rpi-5:~/spin-tools $ uname -a
Linux rpi-5 6.1.0-rpi7-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux
pi@rpi-5:~ $ sudo apt list | grep swt
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libeclipse-e4-ui-css-swt-java/stable,stable 0.14.700+eclipse4.26-1 all
libeclipse-e4-ui-css-swt-theme-java/stable,stable 0.13.200+eclipse4.26-1 all
libeclipse-e4-ui-swt-gtk-java/stable,stable 1.1.200+eclipse4.26-1 all
libeclipse-e4-ui-workbench-addons-swt-java/stable,stable 1.4.500+eclipse4.26-1 all
libeclipse-e4-ui-workbench-renderers-swt-java/stable,stable 0.15.700+eclipse4.26-1 all
libeclipse-e4-ui-workbench-swt-java/stable,stable 0.16.700+eclipse4.26-1 all
libeclipse-swtchart-java/stable,stable 0.13.0-4 all
libjfreechart-swt-java/stable,stable 1.0.19-3 all
libswt-cairo-gtk-4-jni/stable 4.26.0-1 arm64
libswt-glx-gtk-4-jni/stable 4.26.0-1 arm64
libswt-gtk-4-java/stable 4.26.0-1 arm64
libswt-gtk-4-jni/stable 4.26.0-1 arm64
libswt-webkit-gtk-4-jni/stable 4.26.0-1 arm64
libswtcalendar-java/stable,stable 0.5-3 all
libswtchart-java-doc/stable,stable 0.10.0-4 all
libswtchart-java/stable,stable 0.10.0-4 all
libtss2-tcti-swtpm0/stable 3.2.1-3 arm64
libtss2-tcti-swtpm0/stable 3.2.1-3 armhf
python3-roswtf/stable,stable 1.15.15+ds-2 all
swtpm-dev/stable 0.7.1-1.3 arm64
swtpm-dev/stable 0.7.1-1.3 armhf
swtpm-libs/stable 0.7.1-1.3 arm64
swtpm-libs/stable 0.7.1-1.3 armhf
swtpm-tools/stable 0.7.1-1.3 arm64
swtpm-tools/stable 0.7.1-1.3 armhf
swtpm/stable 0.7.1-1.3 arm64
swtpm/stable 0.7.1-1.3 armhf
pi@rpi-5:~/spin-tools $ ./spinide
Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
no swt-gtk-4962r3 in java.library.path: /home/pi/spin-tools/lib:/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
no swt-gtk in java.library.path: /home/pi/spin-tools/lib:/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
no swt in java.library.path: /home/pi/spin-tools/lib:/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
/home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: /home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64 .so on a AARCH64 platform)
Can't load library: /home/pi/.swt/lib/linux/aarch64/libswt-gtk.so
Can't load library: /home/pi/.swt/lib/linux/aarch64/libswt.so
/home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: /home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64 .so on a AARCH64 platform)
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:346)
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:255)
at org.eclipse.swt.internal.C.<clinit>(C.java:19)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:209)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:155)
at org.eclipse.swt.widgets.Display.<clinit>(Display.java:169)
at com.maccasoft.propeller.SpinTools.<clinit>(SpinTools.java:3345)
I've installed spintools in the home directoey of the RPi5.
@dgately said:
Not able to run on RPi5, running with the following versions/commands:
You sure you have downloaded the right package ? I tried several times but I get that same exact error when I run the linux package (which is x86_64 only).
@"Rob v.d. berg" said:
Hi Macca, I tested the latest update (0.34.0) to see whether the upload to flash always works properly with P1. Unfortunately I have to report that it is not much better than with v0.33.0. despite the increase in timeout. About only 25% goes well.
I didn't see where this thread began but I have been using Spin tools exclusively on on my own boards that use the P1 processor for about 2 months or so now and have not had a single failour writing to the eeprom on my boards, in fact the main reason I moved from Propeller Tools (v2.x) to spin Tools in the first place was because Propeller Tools was failing most of the time writing to the P1 eeprom, it was constantly timing out, no idea why.
I have just updated to (0.34.0) and I will see if there are any differences for me and let you know.
@macca I've been testing using Prop Tool with debug as serial terminal. Seems to be working, unless you use actual debug statements, then have to take special care.
Anyway, was hoping this would also work with Spin Tools IDE.
But, seems the debug window ignores regular serial output...
@Rayman said:
@macca I've been testing using Prop Tool with debug as serial terminal. Seems to be working, unless you use actual debug statements, then have to take special care.
Anyway, was hoping this would also work with Spin Tools IDE.
But, seems the debug window ignores regular serial output...
Technically, the debug and terminal window are exactly the same, they take the serial input and display it. The debug window doesn't parse the received data at all, except for CR/LF characters.
A quick test shows that it works as intended.
Can you post a small example and what you expect to see ?
Ok, just noticed the "upload with terminal" option. That's much better approach. Wish Prop Tool had that...
I am having some issues with Spin Tools IDE not being able to upload code though.
Seems to happen when I switch back and forth between Prop Tool, Spin Tools, and FlexProp...
@"Rob v.d. berg" said:
Strange, I have exact the opposite!
Propeller Tools versions 1 and 2 have worked well for years without any problems
I would partly agree with that, in my case Propeller Tool V1 has worked well for years without any problems.
I had a lot of problems with V2, mostly serial port related constantly flagging the Props serial port as faulty even though it was working fine a minute before.
All the above is P1 related, I have made a few P2 boards and have had no problems with V2 on those.
@Rayman said:
Just got the 2bpp 1080p tile driver working with Spin Tools IDE.
Happy about that...
Was giving me an error that I didn't understand earlier...
Tracked it down to this:
print((value ROL = 1) & 1 + "0")
Changed to this to make work:
print((value ROL= 1) & 1 + "0")
Seems prop tool and FlexProp are OK with space between "ROL" and "=" but Spin Tools is not...
Yes, the compiler is a bit more strict about syntax, all multi-character operators must not have spaces.
So you just changed this to make it work?
I was comparing PNut's binary output and noticed some weird differences, but I'm happy to know they aren't significant.
Hi All,
Does anyone know if the Binary file output of "Spin Tools" should be compatible with that of Propeller tool?
I think i read somewhere that they were!
Is there anyway to convert these Binary format files to the eeprom format?
I don't have any clue about either format but guess the EEPROM version maps almost directly onto the boot 32K eeprom?
I saved my program using Spin Tools IDE 0.34.0 as a Binary file but I can't see any way of uploading that to a board using Spin tools?
Surely there is a way to do this, like their was using Propeller tool? Or is this Binary file meant for something else?
I then tried loading that Binary file created by Spin Tools into Propeller tool V1.3.2 but it gave an error message "Checksum Error! File '{file name}.binary' file is corrupt or is not a Propeller Application file! Byte5 (Checksum) is incorrect. >.
The same file loaded into Propeller tool V2.9.3 ok but looks strange. Only code/data seems to be present, the rest is greyed out.
I thought that this might be normal but I tried the same thing with another test program and it was fully populated, as if it had been created by Propeller tool.
This could be a problem for me as I normally send out Firmware updates as *.eeprom files, but spin tools doesn't seem to have that option, only binary.
I know I am getting short of resources in the P1 but this program seems to run normally, even though the binary files look strange.
@lab_ges said:
Does anyone know if the Binary file output of "Spin Tools" should be compatible with that of Propeller tool?
I think i read somewhere that they were!
Is there anyway to convert these Binary format files to the eeprom format?
I don't have any clue about either format but guess the EEPROM version maps almost directly onto the boot 32K eeprom?
[...]
I know I am getting short of resources in the P1 but this program seems to run normally, even though the binary files look strange.
The binary file you save from the Program Info dialog is the same that is uploaded to the Propeller with F11. Probably Propeller Tools complains because the checksum is not calculated in this case.
If I'm not wrong you can take the binary and write the eeprom as is, I don't think the P1 verify the checksum at runtime, only wen uploading. I don't know what is difference with a .eeprom file, if any.
With Spin Tools you can't upload a binary file (you can just upload the program with F11), this is supposed to be used with an external stand alone programmer such as the commonly used TL866.
It would be nice if Spin Tools had that feature internally. My friend John of JonyJib.com needs/wants to send binary files to customers who may not be using Windows.
It would be nice if Spin Tools had that feature internally. My friend John of JonyJib.com needs/wants to send binary files to customers who may not be using Windows.
Installing the whole IDE+Java runtime to upload a binary file is, IMHO, overkill for that cases.
There are stand alone programs like propeller-load that can be compiled for various platforms (I have a windows and linux x86_64 builds on my site).
I think that with some efforts a loader could be built in Python, or other portable language with serial port support. The protocol is documented somewhere and there are a number of sources to make a porting.
Installing the whole IDE+Java runtime to upload a binary file is, IMHO, overkill for that cases.
There are stand alone programs like propeller-load that can be compiled for various platforms (I have a windows and linux x86_64 builds on my site).
..
Hi @macca, thanks for your reply. I have found your "propeller-load.exe" and after searching for a while worked out how to use it, I tried the windows standard /? and /help for help from the progtram but nothing helped much till I used -P and then that gave me the program information I needed.
So far I haven't been able to upload the Spin tools binary files I have tired it with.
After it failed with my latest boards firmware, I decided to try a simpler program so I used your Spin tools IDE to make a binary version of an eemonitor program I use all the time.
Here I am just trying to write it to RAM, not save to the eeprom.
propeller-load.exe -r eemon.binary
Propeller Version 1 on COM3
Loading eemon.binary to hub memory
5520 bytes sent
Verifying RAM ... Checksum Error!
error: load failed
Renaming it to .eeprom and .bin made no difference, all failed.
Am I making a syntax error somewhere, this is a simular error to what I was getting from Propeller tool when trying to upload a binary file using that?
@lab_ges said:
Hi @macca, thanks for your reply. I have found your "propeller-load.exe" and after searching for a while worked out how to use it, I tried the windows standard /? and /help for help from the progtram but nothing helped much till I used -P and then that gave me the program information I needed.
Launching without arguments should give the help, at least on Linux, I guess it does the same on Windows ?
propeller-load.exe -r eemon.binary
Propeller Version 1 on COM3
Loading eemon.binary to hub memory
5520 bytes sent
Verifying RAM ... Checksum Error!
error: load failed
Ah... seems that propeller-load doesn't (re)generate the checksum on upload, I was sure it did that.
@macca said:
Launching without arguments should give the help, at least on Linux, I guess it does the same on Windows ?
Yes, it does, I didn't actually try that.
I tried the /? and /help options but not with no options.
I am an old DOS man and that is how we did things, running without a switch didn't do anything in a lot of programs, but things change.
Thanks for your help.
Minor release to fix some bugs, including the exported binary checksum (P1) and an offset calculation error in callpa/pb instructions (P2).
Also started to implement the selection tab/backtab function (select a group of lines and tab and shift-tab indents or back-indents them all at once). It works only with the normal line-mode selection, block selection has few quirks that needs more work.
With this release I have slightly changed the package names to reflect the target architecture and, now that Github allows it, I have added a build specific for MacOS M1 (aarch64) targets. As far as I can tell, it brings the correct jre and native libraries, hope it works correctly.
Comments
Thank you.
Ok, I have Windows 11 (Home) on the laptop but that doesn't have a displayport connector.
All I can think of is that the connection enabled a specific driver section, with a possible change in the resolution, what this has to do with the window positioning is unknown.
Unfortunately I don't think I can do much to fix that. Eclipse released the usual update few days ago, I'll try to see if there are changes in the SWT library that may have something to do with similar issues.
The preferences are stored in a file named .spin-tools (starts with a dot) in the home directory.
It is a json-formatted text file so you can open it with any text editor.
It stores the window positions for the main window, terminal and the search dialog. All other windows are opened in the default position that is centered related to the main window.
You can safely delete (or rename) the file, it will be created at startup with the default values.
Hi @macca,
I plugged the origional cables back in and the Find window imediately came back.
It was on the Left Monitor and the Spin Tools IDE was on the right monitor, where I normally use it.
I dragged the windows back to the right windows with the Spin Tools IDE and closed the program and swapped the Display Port cables back in.
I re-opened Spin Tools IDE and Find is now working normally.
I don't know why or how this happened but it is definately something to do with HDMI V. Display port.
Thanks for your work on this IDE, it works really well.
Interesting, maybe the direct DP connection changed how windows and dialogs are mapped to the monitors.
Glad you fixed it.
Thank you.
@lab_ges You may want to check if there is a scaling difference between the monitors (after changing the cables) in Windows. Look at the "Make everything bigger" setting under display.
I checked the scaling and it monitor resolution.
Scaling is at 100% & monitor resolution is set at the Maximun so both are unchanged from before.
Guess this goes in the too hard basket, changing the cable types partway through isn't something that would happen too often.
Released version 0.34.0
Added an experimental Raspberry Pi package for 64-bit only OS. Not much tested but seems to work, at least on the Pi 5 with bookworm (debian 12) OS. Should also work on the Pi 3, 4 and 400 provided you installed the 64 bit version OS.
Hi Macca, I tested the latest update (0.34.0) to see whether the upload to flash always works properly with P1. Unfortunately I have to report that it is not much better than with v0.33.0. despite the increase in timeout. About only 25% goes well.
To investigate whether I can discover, I placed an analyzer on the I2C, attached you can find in word the differences between right and wrong.
I hoop the pictures are clear. When things go wrong, an extra negative pulse always appears at the end!
I can't judge this further, but maybe this will be of some use to you.
All I can guess from the pictures is that the write takes less than 5 seconds, the current timeout should be 10 seconds. To me, it seems more an hardware problem of some kind (what's that extra pulse ? seems it can't write the last block ?), but if Propeller Tools works I have absolutely no idea what may be wrong.
My loader was (more or less) ported from https://github.com/dbetz/propeller-load I have a binary on my downloads page https://www.maccasoft.com/downloads/ you may try that to see if it works.
Not able to run on RPi5, running with the following versions/commands:
pi@rpi-5:~ $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" pi@rpi-5:~/spin-tools $ java --version openjdk 17.0.9 2023-10-17 OpenJDK Runtime Environment (build 17.0.9+9-Debian-1deb12u1) OpenJDK 64-Bit Server VM (build 17.0.9+9-Debian-1deb12u1, mixed mode) pi@rpi-5:~/spin-tools $ uname -a Linux rpi-5 6.1.0-rpi7-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux pi@rpi-5:~ $ sudo apt list | grep swt WARNING: apt does not have a stable CLI interface. Use with caution in scripts. libeclipse-e4-ui-css-swt-java/stable,stable 0.14.700+eclipse4.26-1 all libeclipse-e4-ui-css-swt-theme-java/stable,stable 0.13.200+eclipse4.26-1 all libeclipse-e4-ui-swt-gtk-java/stable,stable 1.1.200+eclipse4.26-1 all libeclipse-e4-ui-workbench-addons-swt-java/stable,stable 1.4.500+eclipse4.26-1 all libeclipse-e4-ui-workbench-renderers-swt-java/stable,stable 0.15.700+eclipse4.26-1 all libeclipse-e4-ui-workbench-swt-java/stable,stable 0.16.700+eclipse4.26-1 all libeclipse-swtchart-java/stable,stable 0.13.0-4 all libjfreechart-swt-java/stable,stable 1.0.19-3 all libswt-cairo-gtk-4-jni/stable 4.26.0-1 arm64 libswt-glx-gtk-4-jni/stable 4.26.0-1 arm64 libswt-gtk-4-java/stable 4.26.0-1 arm64 libswt-gtk-4-jni/stable 4.26.0-1 arm64 libswt-webkit-gtk-4-jni/stable 4.26.0-1 arm64 libswtcalendar-java/stable,stable 0.5-3 all libswtchart-java-doc/stable,stable 0.10.0-4 all libswtchart-java/stable,stable 0.10.0-4 all libtss2-tcti-swtpm0/stable 3.2.1-3 arm64 libtss2-tcti-swtpm0/stable 3.2.1-3 armhf python3-roswtf/stable,stable 1.15.15+ds-2 all swtpm-dev/stable 0.7.1-1.3 arm64 swtpm-dev/stable 0.7.1-1.3 armhf swtpm-libs/stable 0.7.1-1.3 arm64 swtpm-libs/stable 0.7.1-1.3 armhf swtpm-tools/stable 0.7.1-1.3 arm64 swtpm-tools/stable 0.7.1-1.3 armhf swtpm/stable 0.7.1-1.3 arm64 swtpm/stable 0.7.1-1.3 armhf pi@rpi-5:~/spin-tools $ ./spinide Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: no swt-gtk-4962r3 in java.library.path: /home/pi/spin-tools/lib:/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib no swt-gtk in java.library.path: /home/pi/spin-tools/lib:/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib no swt in java.library.path: /home/pi/spin-tools/lib:/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib /home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: /home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64 .so on a AARCH64 platform) Can't load library: /home/pi/.swt/lib/linux/aarch64/libswt-gtk.so Can't load library: /home/pi/.swt/lib/linux/aarch64/libswt.so /home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: /home/pi/.swt/lib/linux/aarch64/libswt-gtk-4962r3.so: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64 .so on a AARCH64 platform) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:346) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:255) at org.eclipse.swt.internal.C.<clinit>(C.java:19) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:209) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:155) at org.eclipse.swt.widgets.Display.<clinit>(Display.java:169) at com.maccasoft.propeller.SpinTools.<clinit>(SpinTools.java:3345)I've installed spintools in the home directoey of the RPi5.
You sure you have downloaded the right package ? I tried several times but I get that same exact error when I run the linux package (which is x86_64 only).
Try again:
Delete the .swt folder in the home (rm -rf .swt) where the native libraries are saved (unfortunately the swt loader doesn't overwrite them)
Download the spin-tools-raspberry-0.34.0.tar.gz or spin-tools-raspberry-0.34.0-jre.tar.gz, unpack and run ./spinide
That's what I get for previously trying to run the Linux version in wine...
Thank you
I didn't see where this thread began but I have been using Spin tools exclusively on on my own boards that use the P1 processor for about 2 months or so now and have not had a single failour writing to the eeprom on my boards, in fact the main reason I moved from Propeller Tools (v2.x) to spin Tools in the first place was because Propeller Tools was failing most of the time writing to the P1 eeprom, it was constantly timing out, no idea why.
I have just updated to (0.34.0) and I will see if there are any differences for me and let you know.
Strange, I have exact the opposite!
Propeller Tools versions 1 and 2 have worked well for years without any problems
@macca I've been testing using Prop Tool with debug as serial terminal. Seems to be working, unless you use actual debug statements, then have to take special care.
Anyway, was hoping this would also work with Spin Tools IDE.
But, seems the debug window ignores regular serial output...
Technically, the debug and terminal window are exactly the same, they take the serial input and display it. The debug window doesn't parse the received data at all, except for CR/LF characters.
A quick test shows that it works as intended.
Can you post a small example and what you expect to see ?
Actually, just figured out that it works if I add ser.tx(10) after every ser.tx(13).
Have to see what that does in Prop Tool now...
I do like that you can scroll the debug window up and see earlier output in Spin Tools IDE...
Ok, just noticed the "upload with terminal" option. That's much better approach. Wish Prop Tool had that...
I am having some issues with Spin Tools IDE not being able to upload code though.
Seems to happen when I switch back and forth between Prop Tool, Spin Tools, and FlexProp...
I've had that happen a couple times, too. I think it has to do serial port handling. I shut down both apps to clear the issue.
I would partly agree with that, in my case Propeller Tool V1 has worked well for years without any problems.
I had a lot of problems with V2, mostly serial port related constantly flagging the Props serial port as faulty even though it was working fine a minute before.
All the above is P1 related, I have made a few P2 boards and have had no problems with V2 on those.
Just got the 2bpp 1080p tile driver working with Spin Tools IDE.
Happy about that...
Was giving me an error that I didn't understand earlier...
Tracked it down to this:
print((value ROL = 1) & 1 + "0")Changed to this to make work:
print((value ROL= 1) & 1 + "0")Seems prop tool and FlexProp are OK with space between "ROL" and "=" but Spin Tools is not...
It seems like it ought to be together as
ROL=replaced the<-=operator/asignment.Yes, the compiler is a bit more strict about syntax, all multi-character operators must not have spaces.
So you just changed this to make it work?
I was comparing PNut's binary output and noticed some weird differences, but I'm happy to know they aren't significant.
Hi All,
Does anyone know if the Binary file output of "Spin Tools" should be compatible with that of Propeller tool?
I think i read somewhere that they were!
Is there anyway to convert these Binary format files to the eeprom format?
I don't have any clue about either format but guess the EEPROM version maps almost directly onto the boot 32K eeprom?
I saved my program using Spin Tools IDE 0.34.0 as a Binary file but I can't see any way of uploading that to a board using Spin tools?
Surely there is a way to do this, like their was using Propeller tool? Or is this Binary file meant for something else?
I then tried loading that Binary file created by Spin Tools into Propeller tool V1.3.2 but it gave an error message "Checksum Error! File '{file name}.binary' file is corrupt or is not a Propeller Application file! Byte5 (Checksum) is incorrect. >.
The same file loaded into Propeller tool V2.9.3 ok but looks strange. Only code/data seems to be present, the rest is greyed out.
I thought that this might be normal but I tried the same thing with another test program and it was fully populated, as if it had been created by Propeller tool.
This could be a problem for me as I normally send out Firmware updates as *.eeprom files, but spin tools doesn't seem to have that option, only binary.
I know I am getting short of resources in the P1 but this program seems to run normally, even though the binary files look strange.
Any comments, Hints or sugestions?
[...]
The binary file you save from the Program Info dialog is the same that is uploaded to the Propeller with F11. Probably Propeller Tools complains because the checksum is not calculated in this case.
If I'm not wrong you can take the binary and write the eeprom as is, I don't think the P1 verify the checksum at runtime, only wen uploading. I don't know what is difference with a .eeprom file, if any.
With Spin Tools you can't upload a binary file (you can just upload the program with F11), this is supposed to be used with an external stand alone programmer such as the commonly used TL866.
It would be nice if Spin Tools had that feature internally. My friend John of JonyJib.com needs/wants to send binary files to customers who may not be using Windows.
Installing the whole IDE+Java runtime to upload a binary file is, IMHO, overkill for that cases.
There are stand alone programs like propeller-load that can be compiled for various platforms (I have a windows and linux x86_64 builds on my site).
I think that with some efforts a loader could be built in Python, or other portable language with serial port support. The protocol is documented somewhere and there are a number of sources to make a porting.
..
..
Hi @macca, thanks for your reply. I have found your "propeller-load.exe" and after searching for a while worked out how to use it, I tried the windows standard /? and /help for help from the progtram but nothing helped much till I used -P and then that gave me the program information I needed.
So far I haven't been able to upload the Spin tools binary files I have tired it with.
After it failed with my latest boards firmware, I decided to try a simpler program so I used your Spin tools IDE to make a binary version of an eemonitor program I use all the time.
Here I am just trying to write it to RAM, not save to the eeprom.
Renaming it to .eeprom and .bin made no difference, all failed.
Am I making a syntax error somewhere, this is a simular error to what I was getting from Propeller tool when trying to upload a binary file using that?
Any advice / comments anyone?
Launching without arguments should give the help, at least on Linux, I guess it does the same on Windows ?
Ah... seems that propeller-load doesn't (re)generate the checksum on upload, I was sure it did that.
I'll fix the checksum with the binary save.
Yes, it does, I didn't actually try that.
I tried the /? and /help options but not with no options.
I am an old DOS man and that is how we did things, running without a switch didn't do anything in a lot of programs, but things change.
Thanks for your help.
Released version 0.34.1
Minor release to fix some bugs, including the exported binary checksum (P1) and an offset calculation error in callpa/pb instructions (P2).
Also started to implement the selection tab/backtab function (select a group of lines and tab and shift-tab indents or back-indents them all at once). It works only with the normal line-mode selection, block selection has few quirks that needs more work.
With this release I have slightly changed the package names to reflect the target architecture and, now that Github allows it, I have added a build specific for MacOS M1 (aarch64) targets. As far as I can tell, it brings the correct jre and native libraries, hope it works correctly.