@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.
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.