@wummi said:
But the IDE can not find the Propeller.
Wenn I try upload to RAM, the P2 ist reseted and 612ms later you send > Prop_Chk 0 0 0 0
That will not work, you habe only 150ms time after RESET to send > Prop_Chk 0 0 0 0
After 150ms the program in the FLASH will loaded and run.
The expected delay from reset should be in the order of 75-100msec. max, can't be 100% accurate because the OSes are not realtime, I can reduce the reset timing a bit but not that much, such large delay must be something else.
Is there some latency settings for the serial ports like in Windows ?
Are you using the aarch64 version (not the the x86_64 which runs through the Rosetta translator) right ?
Thank you, Marco. Version 0.43 seems to have -- on initial testing, anyway -- cleared up some of the download problems I was having (in Windows). Going to get the Holiday Light kit back out and retry the WiFi connection.
Thank you, Marco, for the new version. Quick check did work fine on MacOS 13.7.2 without the appbundler version. I unpack the archive always from console.
Also the upload to the Propeller was working well with tasks and with debug output to the console.
I like the new behavior with unused methods with all warnings on. Now only the top unused methods are marked and not the called sub methods too. Good job.
@wummi said:
But the IDE can not find the Propeller.
Wenn I try upload to RAM, the P2 ist reseted and 612ms later you send > Prop_Chk 0 0 0 0
That will not work, you habe only 150ms time after RESET to send > Prop_Chk 0 0 0 0
After 150ms the program in the FLASH will loaded and run.
The expected delay from reset should be in the order of 75-100msec. max, can't be 100% accurate because the OSes are not realtime, I can reduce the reset timing a bit but not that much, such large delay must be something else.
Is there some latency settings for the serial ports like in Windows ?
Are you using the aarch64 version (not the the x86_64 which runs through the Rosetta translator) right ?
I use the aarch64 version, and make some more Tests on 3 different Macs.
1. Mac Studio M2 Max, MacOS 15.2, aarch64 version, RESET to > Prop_Chk = 1100ms
2. MacBook Pro M1 Pro, MacOS 15.0, aarch64 version, RESET to > Prop_Chk = 1100ms
3. iMac Intel, MacOS 13.6, x86_64 version, RESET to > Prop_Chk = 100ms (works)
I think there are no latency settings for the FTDI driver in the MacOS.
After Reset you wait 1.1s
Then send > Prop_Chk 0 0 0 0
Then wait 44s and display: no Propeller found
You try only one time to find the Propeller before the message: no Propeller found
I can send you the Logic Pro Logfile if you want.
@wummi said:
I use the aarch64 version, and make some more Tests on 3 different Macs.
1. Mac Studio M2 Max, MacOS 15.2, aarch64 version, RESET to > Prop_Chk = 1100ms
2. MacBook Pro M1 Pro, MacOS 15.0, aarch64 version, RESET to > Prop_Chk = 1100ms
3. iMac Intel, MacOS 13.6, x86_64 version, RESET to > Prop_Chk = 100ms (works)
I think there are no latency settings for the FTDI driver in the MacOS.
After Reset you wait 1.1s
Then send > Prop_Chk 0 0 0 0
Then wait 44s and display: no Propeller found
You try only one time to find the Propeller before the message: no Propeller found
I can send you the Logic Pro Logfile if you want.
I don't doubt your measurements, I'm just saying that I don't think it's a problem with the program, otherwise your test with the x86_64 Mac (3) would have failed as well (the source is the same for all platforms). There are also other users for which the upload works.
@wummi said:
I use the aarch64 version, and make some more Tests on 3 different Macs.
1. Mac Studio M2 Max, MacOS 15.2, aarch64 version, RESET to > Prop_Chk = 1100ms
2. MacBook Pro M1 Pro, MacOS 15.0, aarch64 version, RESET to > Prop_Chk = 1100ms
3. iMac Intel, MacOS 13.6, x86_64 version, RESET to > Prop_Chk = 100ms (works)
I think there are no latency settings for the FTDI driver in the MacOS.
After Reset you wait 1.1s
Then send > Prop_Chk 0 0 0 0
Then wait 44s and display: no Propeller found
You try only one time to find the Propeller before the message: no Propeller found
I can send you the Logic Pro Logfile if you want.
I don't doubt your measurements, I'm just saying that I don't think it's a problem with the program, otherwise your test with the x86_64 Mac (3) would have failed as well (the source is the same for all platforms). There are also other users for which the upload works.
It sounds like MacOS 15.x is the problem.
Is there an other user with has MacOS 15.x (aarch64) and the upload works?
Can you change your program to handle this open delay of 500ms.
Maybe simple try to connect the propeller multiple times, not only once.
@wummi said:
It sounds like MacOS 15.x is the problem.
Is there an other user with has MacOS 15.x (aarch64) and the upload works?
Can you change your program to handle this open delay of 500ms.
Maybe simple try to connect the propeller multiple times, not only once.
Just occurred to me that you can try a small test to verify if it is the open delay: open the Spin Tools IDE serial terminal (Tools -> Serial Terminal or the Terminal icon on the toolbar) and keep it open, now try to upload a program.
When the serial terminal is open the upload process doesn't close and reopen the serial port. If the issue is the open delay this should be a workaround.
@wummi said:
It sounds like MacOS 15.x is the problem.
Is there an other user with has MacOS 15.x (aarch64) and the upload works?
Can you change your program to handle this open delay of 500ms.
Maybe simple try to connect the propeller multiple times, not only once.
Just occurred to me that you can try a small test to verify if it is the open delay: open the Spin Tools IDE serial terminal (Tools -> Serial Terminal or the Terminal icon on the toolbar) and keep it open, now try to upload a program.
When the serial terminal is open the upload process doesn't close and reopen the serial port. If the issue is the open delay this should be a workaround.
No, it don't work but,
wenn terminal is open and I start the download there ist a 610ms delay after RESET
wenn terminal is not open and I start the download there ist a 1200ms delay after RESET
I try to compile my big program with Spin Tool IDE and found 8 compiler Errors.
I write a demo Programm to demonstrate the Problems.
{Spin2_v47}
CON
_CLKFREQ = 160_000_000
VAR aborttext
PUB start() | A, B
clkmode.[23..18] := 49
aborttext := \xyz()
if aborttext and A := 5
B := lookdown(select(A): "LH")
B.byte[1]~
B.byte[0]~~
if A <> B\A
B := A^3
PRI xyz()
abort @"Error1"
PRI select(val): indx 'indx is not unused
return val.[1]
This Programm can compiled with Pnut48 without Errors.
@wummi said:
No, it don't work but,
wenn terminal is open and I start the download there ist a 610ms delay after RESET
wenn terminal is not open and I start the download there ist a 1200ms delay after RESET
That seems to confirm that there is effectively a delay on port open, but also that there are additional delays somewhere, maybe with the control lines (DTR/RTS) toggle or the beginning of the serial transfer.
I don't think there is something I can do, even adding a second attempt to detect the Propeller there is always the delay due to something else.
Unless there are driver updates or some other way to fix, I believe MacOS 15 is busted for serial programming.
I try to compile my big program with Spin Tool IDE and found 8 compiler Errors.
I write a demo Programm to demonstrate the Problems.
Thank you very much, I'll look at it and fix the errors.
Hi Marco,
MacOS 15.x is the Problem.
I write a small Phyton Program to bring the Propeller in the Monitor Mode.
And I have the same Problems after the 1. Reset.
Then I try ist 10 times and the first failed and the next 9 are ok.
import serial
import time
com = serial.Serial(port="/dev/cu.usbserial-DN4UOJOP", baudrate=2000000, timeout=0.1)
for i in range(10):
com.dtr = True
com.dtr = False
time.sleep(0.05)
com.write(b"> \r> Prop_Chk 0 0 0 0\r")
answer = com.read_until() #read CR LF
answer = com.read_until() #read answer
print(i, answer)
if answer[:-2] == b"Prop_Ver G":
print("Propeller found")
break
time.sleep(0.5)
com.close()
Cannot load compiled binaries in Spin Tools IDE (0.43.0), on MacOS 15.2 (Sequoia 15.2 (24C101)) on Apple Silicon M2 Max (MacBook Pro)...
I get similar results as wummi. SpinTools IDE does not load binaries to the P2 Edge Mini Breakout board. After compiling the simple blink1.spin2 code from flexprop's samples directory (I use that as my test code whenever I'm trying to debug load issues on P2), SpinTools IDE will basically hang for from 20 to 30 seconds before 'sometimes' returning the "cannot find P2" dialog. Most times, it does not return at all and MacOS asks me to force quit Spin Tools IDE.
But... loadp2 (version 0.076) is able to load the binary and run the code without issue (9 times out of 10). After compiling the code with SpinTools IDE (.bin) or compiling with flexprop (.binary) loadp2 happily loads & runs the code.
I've attached MacOS's Sample & SpinDump logs that were acquired during the SpinTools hang period. Maybe those will help.
With a slightly modified version (it dumps found serial devices in /dev & runs the loop to find a P2 10 times, always) of wummi's python code, the P2 is found successfully...
% python wakeP2.py
/dev/cu.debug-console
/dev/cu.Bluetooth-Incoming-Port
/dev/cu.usbserial-P8y12uhc
0 b'Prop_Ver G\r\n'
Propeller found
1 b'Prop_Ver G\r\n'
Propeller found
2 b'Prop_Ver G\r\n'
Propeller found
3 b'Prop_Ver G\r\n'
Propeller found
4 b'Prop_Ver G\r\n'
Propeller found
5 b'Prop_Ver G\r\n'
Propeller found
6 b'Prop_Ver G\r\n'
Propeller found
7 b'Prop_Ver G\r\n'
Propeller found
8 b'Prop_Ver G\r\n'
Propeller found
9 b'Prop_Ver G\r\n'
Propeller found
@wummi said:
I write a small Phyton Program to bring the Propeller in the Monitor Mode.
And I have the same Problems after the 1. Reset.
Then I try ist 10 times and the first failed and the next 9 are ok.
The serial terminal has buttons to start the rom Monitor and TAQOZ, do these works ?
@dgately said:
But... loadp2 (version 0.076) is able to load the binary and run the code without issue (9 times out of 10). After compiling the code with SpinTools IDE (.bin) or compiling with flexprop (.binary) loadp2 happily loads & runs the code.
Ok seems not completely busted, then.
The question now is why my loader works on all operating systems (including MacOS < 15) but not on MacOS 15 ?
I can tune some things but without knowing what is the source of the delays it is a shot in the dark and there an high risk of breaking other operating systems, and the serial port handling is already critical enough.
Without more informations, I'm not going to try to fix it for now, glad there is a workaround using an external loader.
@dgately said:
Cannot load compiled binaries in Spin Tools IDE (0.43.0), on MacOS 15.2 (Sequoia 15.2 (24C101)) on Apple Silicon M2 Max (MacBook Pro)...
With a slightly modified version (it dumps found serial devices in /dev & runs the loop to find a P2 10 times, always) of wummi's python code, the P2 is found successfully...
@dgately, can you post my modified Python Programm to give Marco a hint how to modify his Programm.
I think the workaround for MacOS 15.x is easy.
My knowledge about Java is nearly null and i can not modify Marcos java Programms.
@dgately said:
With a slightly modified version (it dumps found serial devices in /dev & runs the loop to find a P2 10 times, always) of wummi's python code, the P2 is found successfully...
...
@dgately, can you post my modified Python Programm to give Marco a hint how to modify his Programm.
import time
import serial
from serial.tools import list_ports
# list available ports
#port = list(list_ports.comports())
#for p in port:
# print(p.device)
com = serial.Serial('/dev/PORT_NAME_GOES_HERE', baudrate=2000000, timeout=0.1)
for i in range(10):
com.dtr = True
com.dtr = False
time.sleep(0.05)
com.write(b"> \r> Prop_Chk 0 0 0 0\r")
answer = com.read_until() #read CR LF
answer = com.read_until() #read answer
print(i, answer)
if answer[:-2] == b"Prop_Ver G":
print("Propeller found")
# break
time.sleep(0.5)
com.close()
/dev/cu.debug-console
/dev/cu.Bluetooth-Incoming-Port
/dev/cu.usbserial-DN4UOJOP
0 b''
1 b'Prop_Ver G\r\n'
Propeller found
2 b'Prop_Ver G\r\n'
Propeller found
3 b'Prop_Ver G\r\n'
Propeller found
4 b'Prop_Ver G\r\n'
Propeller found
5 b'Prop_Ver G\r\n'
Propeller found
6 b'Prop_Ver G\r\n'
Propeller found
7 b'Prop_Ver G\r\n'
Propeller found
8 b'Prop_Ver G\r\n'
Propeller found
9 b'Prop_Ver G\r\n'
Propeller found
The first try (I=0) failed and the 9 next are ok.
Marco try only one time to wake up the Propeller and this fails.
Wenn he try it 10 times in a loop, the first failed and then ist works.
@VonSzarvas said:
One other thing I noticed... Maybe Jon mentioned this before too, so forgive me if repeating. When we highlight a line of code, we can use shift-tab to decrement the tab indent. Cool. - But- if we highlight multiple lines (example, an if block), then we can't use shift-tab. The only way to realign seems to be line-by-line, or maybe the global auto-format.
Seems to work correctly here, it was implemented somtime ago, maybe some selection doesn't work as expected.
An example:
After 2 TABs
After Shift+TAB
I tried different selection variations, including the block selection, but don't see any problem.
Could the issue occur when copy/pasting code in from other editors? Maybe when spaces were used instead of tabs, or visa-versa ? Or a different number of indent spaces compared to the SpinTools default/preferences.
Either way- I'll keep an eye out and grab the raw ASCII next time I see it happen. And also email you the src file.
@VonSzarvas said:
Could the issue occur when copy/pasting code in from other editors? Maybe when spaces were used instead of tabs, or visa-versa ? Or a different number of indent spaces compared to the SpinTools default/preferences.
TABs are always converted to spaces either when loading a file or pasting a text. The TAB -> space conversion however uses the default 8 spaces (there isn't a preference for that) so an initial mis-alignment is expected, TAB and Shift-TAB then uses the tabstops defined in the preferences.
Selected lines are moved all by the same number of spaces and the tabstop reference is the leftmost column in the selection. I mean, if you have indented lines inside the block that are not tab-aligned, they will not be tab aligned. In the images above you can see that the case blocks lines indentation is the same, the whole block is moved by the same number of spaces.
And since it uses the tabstops list it doesn't align with the previous line (the repeat line in the case above) if not already aligned.
Thanks Marco,
but there are a new Problem with Pointers to Methods in V0.43.1
{Spin2_v47}
CON
_CLKFREQ = 160_000_000
PUB start() | head, a
head := @ABC
send(head(), "DEF") 'no Error in V0.43.0
a := head(): 1 'no Error in V0.43.0
a := head() :1 'Error in V0.43.0 and V0.43.1 but not in Pnut_v48
a := head():1 'Ok
PRI ABC()
send("ABC")
Are you working at a workaround to upload on MacOS 15.x?
@wummi said:
but there are a new Problem with Pointers to Methods in V0.43.1
{Spin2_v47}
CON
_CLKFREQ = 160_000_000
PUB start() | head, a
head := @ABC
send(head(), "DEF") 'no Error in V0.43.0
a := head(): 1 'no Error in V0.43.0
a := head() :1 'Error in V0.43.0 and V0.43.1 but not in Pnut_v48
a := head():1 'Ok
PRI ABC()
send("ABC")
The method pointer return count specifier must be without spaces as in your last line. This is a "limitation" of my compiler and I can't modify it as of now.
Are you working at a workaround to upload on MacOS 15.x?
Nope, as I wrote, I don't know what causes the delays so I can't fix it.
I made some changes to make the P2 WiFi upload more reliable, maybe something changed (P2 WiFi and serial are basically the same), I suggest to try the upload with each release and see what happens.
@macca said:
The method pointer return count specifier must be without spaces as in your last line. This is a "limitation" of my compiler and I can't modify it as of now.
Ok, but the Method Pointer in send() ist a problem.
This Error ist new in V0.43.1
Nope, as I wrote, I don't know what causes the delays so I can't fix it.
In my short Python Program I demonstrate the workaround for the MacOS 15.x problem.
Do you understand the Python Program?
I think you can easy implement this in your Java Software.
@wummi said:
Ok, but the Method Pointer in send() ist a problem.
This Error ist new in V0.43.1
Ok, I'll look at it.
Nope, as I wrote, I don't know what causes the delays so I can't fix it.
In my short Python Program I demonstrate the workaround for the MacOS 15.x problem.
Do you understand the Python Program?
I think you can easy implement this in your Java Software.
Yes, I understand Python, seems that we don't understand each other instead.
The loader works on Linux, Windows and MacOS 14, the timings are correct on all these platforms, there is no technical reasons for not working on MacOS 15, but clearly somethings changed in that OS.
What changed ? I don't know.
What command causes the delay ? I don't know.
You suggested to make a second attempt at detecting the Propeller, but your test with the terminal shows that won't work.
I repeat again, the sources are available, feel free to learn Java and submit a patch.
You can also gift me a Mac with MacOS 15 to test if you want.
This release was focused mainly on implement the firmware package tool for the Propeller Firmware Loader.
Available from the Tools -> Firmware Packages... menu.
The tool allows to build packages with more than one firmware (old version, variants, P1 and P2 implementations, etc.) for distribution to users / customers.
It also allows to bundle the package with the firmware loader. The user then just unpacks the loader package and on startup it automatically loads the bundled firmware.
The Show Info dialogs have an additional button "Save Package" to save the compiled binary to a firmware package and open the editor dialog.
Also .json files on the file explorer will open the package editor dialog.
Note: to bundle the firmware with the loader, you need to download the propeller firmware loader packages and place them in a sub-folder named loaders:
The tar.gz package will create a spin-tools folder containing the examples, library, command-line executables (previously contained within the .app folder) and the MacOS .app folder.
It is important to unpack from a terminal command line, or the OS will flag it as quarantined and won't allow to execute (still can be executed from the command line).
Several changes in this release, mostly internal implementations and refactorings, and also a number of bugfixes.
Implemented the new FRAME and CROP keywords in the PLOT debug window, allowing to run the amazing demonstration programs listed here.
The Editor preferences has new settings to define the code document hover popup and code navigation key modifiers.
The default is no modifier for document popup (move the mouse over a method and after a second it shows the documentation popup if available) and CTRL+Click to navigate to a method/variable/label definition. The preferences allows to define the key shift/control/alt/etc. combination associated to the popup display and mouse click for these two features.
The Spin2 interpreter was updated to the latest v49 - 2025.02.16 (or PNut v50, the interpreter seems the same) including the new features (string escape, orgh directive, pasm debug condition, etc.). I have not yet implemented the DITTO feature, will be implemented later.
This release implements the experimental PAsm NAMESP directive to set a namespace for PAsm labels. Some discussions can be found here. With a small difference: I have reverted the DAT block name in favor of the NAMESP directive as, after some real-world testing, seemed more appropriate and consistent with the behaviour.
The NAMESP defines the namespace prefix that is prepended to all subsequent labels (including subsequent DAT blocks). References inside the namespace can omit the prefix, reference outside the namespace must prepend the prefix, as shown in the image above.
The label rules are the same as before, including local labels, however code blocks with different namespaces can have the same label names without duplicate errors or cross references.
Since it is not officially supported by PNut this should be considered experimental and available only with Spin Tools.
Changes summary:
Spin2 interpreter updated to v49 - 2025.02.16
Import structure definitions from objects
Added @\ operator for strings with escape-character sequences
Implemented PAsm debug condition
Allow inline orgh directive
Allow predefined registers in CONstants expressions
Implemented FRAME and CROP keywords in PLOT debug window
Implemented PAsm NAMESP directive to set labels namespace
Token marker refactorings, mark excluded nodes as comment
Better compiler performances with large data buffers
Implemented alignl/alignw in VAR blocks
Serial port selection and error handling fixes
Fixed backtab with empty lines
Added hover doc and code navigation modifiers preferences
{Spin2_v50}
DAT
orgh
namesp a
bar long @glbl
namesp b
foo long @a.bar
namesp a
long @foo
namesp
glbl long 1,2,3
Why is foo still in scope after going back to namesp a? (bar is not in scope!) Also am I right in assuming that namesp without parameter returns to global mode?
Comments
The expected delay from reset should be in the order of 75-100msec. max, can't be 100% accurate because the OSes are not realtime, I can reduce the reset timing a bit but not that much, such large delay must be something else.
Is there some latency settings for the serial ports like in Windows ?
Are you using the aarch64 version (not the the x86_64 which runs through the Rosetta translator) right ?
Thank you, Marco. Version 0.43 seems to have -- on initial testing, anyway -- cleared up some of the download problems I was having (in Windows). Going to get the Holiday Light kit back out and retry the WiFi connection.
Thank you, Marco, for the new version. Quick check did work fine on MacOS 13.7.2 without the appbundler version. I unpack the archive always from console.
Also the upload to the Propeller was working well with tasks and with debug output to the console.
I like the new behavior with unused methods with all warnings on. Now only the top unused methods are marked and not the called sub methods too. Good job.
I use the aarch64 version, and make some more Tests on 3 different Macs.
1. Mac Studio M2 Max, MacOS 15.2, aarch64 version, RESET to > Prop_Chk = 1100ms
2. MacBook Pro M1 Pro, MacOS 15.0, aarch64 version, RESET to > Prop_Chk = 1100ms
3. iMac Intel, MacOS 13.6, x86_64 version, RESET to > Prop_Chk = 100ms (works)
I think there are no latency settings for the FTDI driver in the MacOS.
After Reset you wait 1.1s
Then send > Prop_Chk 0 0 0 0
Then wait 44s and display: no Propeller found
You try only one time to find the Propeller before the message: no Propeller found
I can send you the Logic Pro Logfile if you want.
I don't doubt your measurements, I'm just saying that I don't think it's a problem with the program, otherwise your test with the x86_64 Mac (3) would have failed as well (the source is the same for all platforms). There are also other users for which the upload works.
I did some searches and found this discussions that seems to confirm that there are effectively problems with the FTDI serial on MacOS version 15+.
https://discussions.apple.com/thread/255763367?answerId=260820338022&sortBy=rank#260820338022
I'm not sure if that is your issue.
It sounds like MacOS 15.x is the problem.
Is there an other user with has MacOS 15.x (aarch64) and the upload works?
Can you change your program to handle this open delay of 500ms.
Maybe simple try to connect the propeller multiple times, not only once.
Just occurred to me that you can try a small test to verify if it is the open delay: open the Spin Tools IDE serial terminal (Tools -> Serial Terminal or the Terminal icon on the toolbar) and keep it open, now try to upload a program.
When the serial terminal is open the upload process doesn't close and reopen the serial port. If the issue is the open delay this should be a workaround.
No, it don't work but,
wenn terminal is open and I start the download there ist a 610ms delay after RESET
wenn terminal is not open and I start the download there ist a 1200ms delay after RESET
I try to compile my big program with Spin Tool IDE and found 8 compiler Errors.
I write a demo Programm to demonstrate the Problems.
{Spin2_v47} CON _CLKFREQ = 160_000_000 VAR aborttext PUB start() | A, B clkmode.[23..18] := 49 aborttext := \xyz() if aborttext and A := 5 B := lookdown(select(A): "LH") B.byte[1]~ B.byte[0]~~ if A <> B\A B := A^3 PRI xyz() abort @"Error1" PRI select(val): indx 'indx is not unused return val.[1]This Programm can compiled with Pnut48 without Errors.
That seems to confirm that there is effectively a delay on port open, but also that there are additional delays somewhere, maybe with the control lines (DTR/RTS) toggle or the beginning of the serial transfer.
I don't think there is something I can do, even adding a second attempt to detect the Propeller there is always the delay due to something else.
Unless there are driver updates or some other way to fix, I believe MacOS 15 is busted for serial programming.
Thank you very much, I'll look at it and fix the errors.
Hi Marco,
MacOS 15.x is the Problem.
I write a small Phyton Program to bring the Propeller in the Monitor Mode.
And I have the same Problems after the 1. Reset.
Then I try ist 10 times and the first failed and the next 9 are ok.
import serial import time com = serial.Serial(port="/dev/cu.usbserial-DN4UOJOP", baudrate=2000000, timeout=0.1) for i in range(10): com.dtr = True com.dtr = False time.sleep(0.05) com.write(b"> \r> Prop_Chk 0 0 0 0\r") answer = com.read_until() #read CR LF answer = com.read_until() #read answer print(i, answer) if answer[:-2] == b"Prop_Ver G": print("Propeller found") break time.sleep(0.5) com.close()Cannot load compiled binaries in Spin Tools IDE (0.43.0), on MacOS 15.2 (Sequoia 15.2 (24C101)) on Apple Silicon M2 Max (MacBook Pro)...
I get similar results as wummi. SpinTools IDE does not load binaries to the P2 Edge Mini Breakout board. After compiling the simple blink1.spin2 code from flexprop's samples directory (I use that as my test code whenever I'm trying to debug load issues on P2), SpinTools IDE will basically hang for from 20 to 30 seconds before 'sometimes' returning the "cannot find P2" dialog. Most times, it does not return at all and MacOS asks me to force quit Spin Tools IDE.
But... loadp2 (version 0.076) is able to load the binary and run the code without issue (9 times out of 10). After compiling the code with SpinTools IDE (.bin) or compiling with flexprop (.binary) loadp2 happily loads & runs the code.
I've attached MacOS's Sample & SpinDump logs that were acquired during the SpinTools hang period. Maybe those will help.
With a slightly modified version (it dumps found serial devices in /dev & runs the loop to find a P2 10 times, always) of wummi's python code, the P2 is found successfully...
dgately
The serial terminal has buttons to start the rom Monitor and TAQOZ, do these works ?
Ok seems not completely busted, then.
The question now is why my loader works on all operating systems (including MacOS < 15) but not on MacOS 15 ?
I can tune some things but without knowing what is the source of the delays it is a shot in the dark and there an high risk of breaking other operating systems, and the serial port handling is already critical enough.
Without more informations, I'm not going to try to fix it for now, glad there is a workaround using an external loader.
The source code is here https://github.com/maccasoft/spin-tools feel free to do your tests and propose a fix.
The Github release page includes all previous versions, you can try these to see if there is a version that works.
@dgately, can you post my modified Python Programm to give Marco a hint how to modify his Programm.
I think the workaround for MacOS 15.x is easy.
My knowledge about Java is nearly null and i can not modify Marcos java Programms.
Uwe
No, same 600ms delay after Reset
...
import time import serial from serial.tools import list_ports # list available ports #port = list(list_ports.comports()) #for p in port: # print(p.device) com = serial.Serial('/dev/PORT_NAME_GOES_HERE', baudrate=2000000, timeout=0.1) for i in range(10): com.dtr = True com.dtr = False time.sleep(0.05) com.write(b"> \r> Prop_Chk 0 0 0 0\r") answer = com.read_until() #read CR LF answer = com.read_until() #read answer print(i, answer) if answer[:-2] == b"Prop_Ver G": print("Propeller found") # break time.sleep(0.5) com.close()dgately
@ dgately
wenn i run your Python Prog. i get:
The first try (I=0) failed and the 9 next are ok.
Marco try only one time to wake up the Propeller and this fails.
Wenn he try it 10 times in a loop, the first failed and then ist works.
Uwe
Seems to work correctly here, it was implemented somtime ago, maybe some selection doesn't work as expected.
An example:
After 2 TABs
After Shift+TAB
I tried different selection variations, including the block selection, but don't see any problem.
@macca Thanks for looking into it.
Could the issue occur when copy/pasting code in from other editors? Maybe when spaces were used instead of tabs, or visa-versa ? Or a different number of indent spaces compared to the SpinTools default/preferences.
Either way- I'll keep an eye out and grab the raw ASCII next time I see it happen. And also email you the src file.
TABs are always converted to spaces either when loading a file or pasting a text. The TAB -> space conversion however uses the default 8 spaces (there isn't a preference for that) so an initial mis-alignment is expected, TAB and Shift-TAB then uses the tabstops defined in the preferences.
Selected lines are moved all by the same number of spaces and the tabstop reference is the leftmost column in the selection. I mean, if you have indented lines inside the block that are not tab-aligned, they will not be tab aligned. In the images above you can see that the case blocks lines indentation is the same, the whole block is moved by the same number of spaces.
And since it uses the tabstops list it doesn't align with the previous line (the repeat line in the case above) if not already aligned.
That all seems to agree with what I assumed and experienced.
I'll send you an example when I find the exception
Released version 0.43.1
Bugfix release to fix few compiler errors.
Also optimized a bit the P2 WiFi loader and now seems more reliable in detecting the remote P2 device.
Thanks Marco,
but there are a new Problem with Pointers to Methods in V0.43.1
{Spin2_v47} CON _CLKFREQ = 160_000_000 PUB start() | head, a head := @ABC send(head(), "DEF") 'no Error in V0.43.0 a := head(): 1 'no Error in V0.43.0 a := head() :1 'Error in V0.43.0 and V0.43.1 but not in Pnut_v48 a := head():1 'Ok PRI ABC() send("ABC")Are you working at a workaround to upload on MacOS 15.x?
The method pointer return count specifier must be without spaces as in your last line. This is a "limitation" of my compiler and I can't modify it as of now.
Nope, as I wrote, I don't know what causes the delays so I can't fix it.
I made some changes to make the P2 WiFi upload more reliable, maybe something changed (P2 WiFi and serial are basically the same), I suggest to try the upload with each release and see what happens.
Ok, but the Method Pointer in send() ist a problem.
This Error ist new in V0.43.1
In my short Python Program I demonstrate the workaround for the MacOS 15.x problem.
Do you understand the Python Program?
I think you can easy implement this in your Java Software.
Ok, I'll look at it.
Yes, I understand Python, seems that we don't understand each other instead.
The loader works on Linux, Windows and MacOS 14, the timings are correct on all these platforms, there is no technical reasons for not working on MacOS 15, but clearly somethings changed in that OS.
What changed ? I don't know.
What command causes the delay ? I don't know.
You suggested to make a second attempt at detecting the Propeller, but your test with the terminal shows that won't work.
I repeat again, the sources are available, feel free to learn Java and submit a patch.
You can also gift me a Mac with MacOS 15 to test if you want.
Release version 0.44.0
This release was focused mainly on implement the firmware package tool for the Propeller Firmware Loader.
Available from the Tools -> Firmware Packages... menu.
The tool allows to build packages with more than one firmware (old version, variants, P1 and P2 implementations, etc.) for distribution to users / customers.
It also allows to bundle the package with the firmware loader. The user then just unpacks the loader package and on startup it automatically loads the bundled firmware.
The Show Info dialogs have an additional button "Save Package" to save the compiled binary to a firmware package and open the editor dialog.
Also .json files on the file explorer will open the package editor dialog.
Note: to bundle the firmware with the loader, you need to download the propeller firmware loader packages and place them in a sub-folder named loaders:
It is not mandatory to download all packages, if your users only use windows you can download only that.
The MacOS package layout was changed to be consistent with other OSes and to allow for a (future) code signature implementation.
The tar.gz package will create a spin-tools folder containing the examples, library, command-line executables (previously contained within the .app folder) and the MacOS .app folder.
It is important to unpack from a terminal command line, or the OS will flag it as quarantined and won't allow to execute (still can be executed from the command line).
Other changes:
Enjoy!
@macca Great Job on this one! It works on mac perfectly!
@macca Great Job, all my reported compiles errors are fixed.
Uploading to the Propeller2 is still not working under MacOS 15.3
Released version 0.45.0
Several changes in this release, mostly internal implementations and refactorings, and also a number of bugfixes.
Implemented the new FRAME and CROP keywords in the PLOT debug window, allowing to run the amazing demonstration programs listed here.
The Editor preferences has new settings to define the code document hover popup and code navigation key modifiers.
The default is no modifier for document popup (move the mouse over a method and after a second it shows the documentation popup if available) and CTRL+Click to navigate to a method/variable/label definition. The preferences allows to define the key shift/control/alt/etc. combination associated to the popup display and mouse click for these two features.
The Spin2 interpreter was updated to the latest v49 - 2025.02.16 (or PNut v50, the interpreter seems the same) including the new features (string escape, orgh directive, pasm debug condition, etc.). I have not yet implemented the DITTO feature, will be implemented later.
This release implements the experimental PAsm NAMESP directive to set a namespace for PAsm labels. Some discussions can be found here. With a small difference: I have reverted the DAT block name in favor of the NAMESP directive as, after some real-world testing, seemed more appropriate and consistent with the behaviour.
The NAMESP defines the namespace prefix that is prepended to all subsequent labels (including subsequent DAT blocks). References inside the namespace can omit the prefix, reference outside the namespace must prepend the prefix, as shown in the image above.
The label rules are the same as before, including local labels, however code blocks with different namespaces can have the same label names without duplicate errors or cross references.
Since it is not officially supported by PNut this should be considered experimental and available only with Spin Tools.
Changes summary:
Spin2 interpreter updated to v49 - 2025.02.16
Implemented FRAME and CROP keywords in PLOT debug window
Thanks to @VonSzarvas for testing the prerelease.
Enjoy!
@macca
I think there's something not quite right
{Spin2_v50} DAT orgh namesp a bar long @glbl namesp b foo long @a.bar namesp a long @foo namesp glbl long 1,2,3Why is foo still in scope after going back to namesp a? (bar is not in scope!) Also am I right in assuming that namesp without parameter returns to global mode?