@wummi said:
Hi maca,
The upload with MacOS 15 is still not running: I look at the sources at GitHub and found the problem.
in "spin-tools/spin-tools/src/com/maccasoft/propeller/devices/SerialComPort.java"
in function "public void hwreset(Control control, int delay)"
at line " serialPort.purgePort(SerialPort.PURGE_TXCLEAR | SerialPort.PURGE_RXCLEAR);" is the problem.
The function "SerialPort.PURGE_TXCLEAR" need 500ms to execute on MacOS 15
The function "SerialPort.PURGE_RXCLEAR" need not mutch time to execute
"SerialPort.PURGE_TXCLEAR" is not necessary at this time, you can delete it.
Uwe
Is this something that varies for different OS versions ?
I'm wondering if an "advanced setting" is required, to allow a user to override the TXCLEAR and RXCLEAR settings; hopefully that would allow all current (and future) MacOS variants to operate, without stomping on the settings for other OS users ?
I remember going through a similar thing when adding the P2 WiFi programming code to the Parallax WiFi module. I can't recall the details, but do remember we had to settle on a compromise delay to suit the masses-which didn't seem obvious from a Windows standpoint, and was tricky for me as I didn't have a Mac at that time!
The 500ms Delay is on macOS 15 only.
I think the TXCLEAR is not necessary at this Place.
Or we can also change the order, first executive TXCLEAR / RXCLEAR and then toggle DTR to reset the Propeller.
I think this will run on all Platforms and all macOS Versions.
@wummi said:
The function "SerialPort.PURGE_TXCLEAR" need 500ms to execute on MacOS 15
The function "SerialPort.PURGE_RXCLEAR" need not mutch time to execute
"SerialPort.PURGE_TXCLEAR" is not necessary at this time, you can delete it.
Ahhhh... can't believe it was that... thanks for looking at it.
@VonSzarvas said:
Is this something that varies for different OS versions ?
I'm wondering if an "advanced setting" is required, to allow a user to override the TXCLEAR and RXCLEAR settings; hopefully that would allow all current (and future) MacOS variants to operate, without stomping on the settings for other OS users ?
I'll do some tests but I don't think it needs any special setting. The TXCLEAR was added just to be safe but at that point the tx buffer is clear anyway.
@wummi said:
Or we can also change the order, first executive TXCLEAR / RXCLEAR and then toggle DTR to reset the Propeller.
RXCLEAR is needed AFTER the reset toggle because when the Propeller is in the reset state the TX pin may float and the PC side may receive garbage preventing the upload to work correctly. This is mostly necessary for P1 that has a bit "weird" upload protocol, the P2 is bit more immune (if I'm not wrong, recent Edge boards have a pull-up on the RX/TX pins) but still better clear the input buffer anyway.
The TXCLEAR may be issued before the reset toggle, but I don't think it is necessary.
I'll do a new release tomorrow so I can fix an issue with the Raspberry Pi OS that I forgot to fix (actually I tought I have fixed sometime ago...).
I do some more Tests:
1. DTR=ON --> DTR=OFF --> RXCLEAR --> TXCLEAR : do not work
2. RXCLEAR --> TXCLEAR -> DTR=ON --> DTR=OFF : do work. First Reset Pulse is 1000ms long after open the Port, all next are short.
3. DTR=ON --> RXCLEAR --> TXCLEAR --> DTR=OFF : do work. First Reset Pulse is 1000ms long after open the Port, all next are 500ms long.
4. DTR=ON --> DTR=OFF --> RXCLEAR : do work. First Reset Pulse is 500ms long after open the Port, all next are short.
5. DTR=ON --> RXCLEAR --> DTR=OFF : do work. First Reset Pulse is 500ms long after open the Port, all next are short.
You can use #2 to #5, and I think this will also work on Windows and Linux.
Hi Macca,
None of my current SPIN2 Projects can compiled with Version 0.47.1
The next two programs shows the Errors.
PNUT v51.1 compiles this without Errors.
{TestSpinTools.spin2}
{Spin2_v51}
CON ' Constants
_CLKFREQ = 160_000_000
struct sTOPIC ( Str, Meth, Mem, crc )
ADR = 0 addbits 19
VAR ' Variables
sTOPIC Topic 'topic is used
^sTOPIC pTopic 'pointer to struct not recognized
long Meth
OBJ ' Objects
o1: "TestObj"
PUB start() | halt, ^o1.sLIST x 'x ist used
Topic.Str.[ADR] := @"/1/2" 'Bitfields on struct members not working
halt := taskhlt 'taskhlt : Register which holds the HALT bits (in reverse order) {Spin2_v47}
[x] := o1.start()
x.Part[0].adr := @"Uwe" 'struct not recognized
if [x] and Meth 'Error ??????
'bla,bla,bla
{TestObj.spin2}
{Spin2_v51}
CON ' Constants
struct sPART ( long adr, byte len )
struct sLIST(byte len, sPART Part[10])
VAR ' Variables
sLIST List
PUB start(): ^sLIST Result
return @List
Hi Macca,
All my current SPIN2 Projects can now compiled with Version 0.47.2
But the compiled code is so buggy that non of my programs are running.
PNUT v51.a can compile it and all the programs are running.
Sorry, I give up with Spin Tools and wait for PNUT-TS for MacOS.
@wummi said:
All my current SPIN2 Projects can now compiled with Version 0.47.2
But the compiled code is so buggy that non of my programs are running.
PNUT v51.a can compile it and all the programs are running.
The code snippet you posted above generates the exact same binary as PNut, I always use PNut binary as a reference and make sure that it generate the same code, however it is possible that some path don't generate the same code for some reasons, especially if you are heavily using the new features like structure and pointers with that weird and confusing syntax, if you want to share a code snippet that compiles but doesn't work as expected I can look at it and fix the issues. If you want I can also look at your whole verbatim source (privately if you can't share it, I can assure you that I'll not disclose it to anyone else).
I found 3 more compile errors and which line the program crashes.
After you find this Errors, I will test it with my programs.
maybe there are more errors.
{Spin2_v51}
CON ' Constants
_CLKFREQ = 160_000_000
struct sTOPIC ( Str, byte pos, byte key[1] )
VAR ' Variables
sTOPIC Topic[4]
PUB start() | i, x
Topic[1].key[0] := 55
CompileErrors(@Topic[1])
repeat 4 with i
x := @Topic[i].Str 'this Line crashes the program
debug(uhex(x))
debug("loop ", sdec(i))
debug("loop End")
PRI CompileErrors ( adr ): ^sTOPIC p | x
[p] := adr
'x := p.key[p.pos++] 'compile Error
x := p.key[p.pos] 'Workaround in two lines
p.pos++ '<-----
debug(sdec(x), uhex([p])) 'Error x = 55
'[p]~~ 'compile Error
'[p]~ 'compile Error
if [p] \ 0 'Workaround but not working
debug(uhex([p])) 'this line is not executing, but shoud be
debug("End CompileErrors")
Another bugfix release for the reported issues mainly on pointer usage.
Took a lot of time to sort out all the syntax and it isn't yet 100% fixed, the reported snippets all compile binary exact as PNut, so I hope there are some less-used cases to fix.
Some fixes requires more deep changes in the compiler structure so will take more time.
Known issues so far:
Address of the pointer variable @[ptr] is not working (compile error)
Pointer pre-inc/dec inside an index like buffer[[++]ptr] doesn't cause errors but the increment is applied to the pointed value and not to the pointer, the post-inc/dec however buffer[ptr[++]] works (need a deep compiler change to fix).
Hi macca, i tested the new Vers. and found 1 Compile Error and 1 Runtime Error.
Here the Test-Prog.
{Spin2_v51}
CON ' Constants
_CLKFREQ = 160_000_000
struct sTOPIC ( Str, byte pos, byte key[1] )
VAR ' Variables
sTOPIC Topic[4]
PUB start()
CompileErrors1(@Topic[1]) 'Runtime Error
CompileErrors2(@Topic[1]) 'Runtime Error
CompileErrors3(@Topic[1]) 'Runtime Error
CompileErrors4(@Topic[1]) 'no Runtime Error
Topic~ 'Compile Error
PRI CompileErrors1 ( adr ): ^sTOPIC p | x 'local Var x is decl but not used
[p] := adr
debug("L17 ",uhex([p]))
if [p]~
debug("L19 ",uhex([p])) 'this line is not executing, but shoud be
debug("End CompileErrors1")
PRI CompileErrors2 ( adr ): ^sTOPIC p 'no local Vars
[p] := adr
debug("L24 ",uhex([p]))
if [p]~
debug("L26 ",uhex([p])) 'this line is now executing, but [p] shoud be 0
debug("End CompileErrors2")
PRI CompileErrors3 ( adr ) | ^sTOPIC p 'p is now a local Var
[p] := adr
debug("L31 ",uhex([p]))
if [p]~
debug("L33 ",uhex([p])) 'this line is not executing, but shoud be
debug("End CompileErrors3")
PRI CompileErrors4 ( adr ) 'no Runtime Errors
debug("L37 ",uhex(adr))
if adr~
debug("L39 ",uhex(adr)) 'OK
debug("End CompileErrors4")
Comments
Is this something that varies for different OS versions ?
I'm wondering if an "advanced setting" is required, to allow a user to override the TXCLEAR and RXCLEAR settings; hopefully that would allow all current (and future) MacOS variants to operate, without stomping on the settings for other OS users ?
I remember going through a similar thing when adding the P2 WiFi programming code to the Parallax WiFi module. I can't recall the details, but do remember we had to settle on a compromise delay to suit the masses-which didn't seem obvious from a Windows standpoint, and was tricky for me as I didn't have a Mac at that time!
The 500ms Delay is on macOS 15 only.
I think the TXCLEAR is not necessary at this Place.
Or we can also change the order, first executive TXCLEAR / RXCLEAR and then toggle DTR to reset the Propeller.
I think this will run on all Platforms and all macOS Versions.
Ahhhh... can't believe it was that... thanks for looking at it.
I'll do some tests but I don't think it needs any special setting. The TXCLEAR was added just to be safe but at that point the tx buffer is clear anyway.
RXCLEAR is needed AFTER the reset toggle because when the Propeller is in the reset state the TX pin may float and the PC side may receive garbage preventing the upload to work correctly. This is mostly necessary for P1 that has a bit "weird" upload protocol, the P2 is bit more immune (if I'm not wrong, recent Edge boards have a pull-up on the RX/TX pins) but still better clear the input buffer anyway.
The TXCLEAR may be issued before the reset toggle, but I don't think it is necessary.
I'll do a new release tomorrow so I can fix an issue with the Raspberry Pi OS that I forgot to fix (actually I tought I have fixed sometime ago...).
I do some more Tests:
1. DTR=ON --> DTR=OFF --> RXCLEAR --> TXCLEAR : do not work
2. RXCLEAR --> TXCLEAR -> DTR=ON --> DTR=OFF : do work. First Reset Pulse is 1000ms long after open the Port, all next are short.
3. DTR=ON --> RXCLEAR --> TXCLEAR --> DTR=OFF : do work. First Reset Pulse is 1000ms long after open the Port, all next are 500ms long.
4. DTR=ON --> DTR=OFF --> RXCLEAR : do work. First Reset Pulse is 500ms long after open the Port, all next are short.
5. DTR=ON --> RXCLEAR --> DTR=OFF : do work. First Reset Pulse is 500ms long after open the Port, all next are short.
You can use #2 to #5, and I think this will also work on Windows and Linux.
Uwe
Released version 0.47.1
Great, thank you Macca.
MacOS 15 can upload to Propeller 2.
in Terminal, switch to the Monitor and TAQOZ runs now.
Tools/Show Devices works.
I found some more Compiler Errors, and will report this next Week.
Uwe
Hi Macca,
None of my current SPIN2 Projects can compiled with Version 0.47.1
The next two programs shows the Errors.
PNUT v51.1 compiles this without Errors.
{TestSpinTools.spin2} {Spin2_v51} CON ' Constants _CLKFREQ = 160_000_000 struct sTOPIC ( Str, Meth, Mem, crc ) ADR = 0 addbits 19 VAR ' Variables sTOPIC Topic 'topic is used ^sTOPIC pTopic 'pointer to struct not recognized long Meth OBJ ' Objects o1: "TestObj" PUB start() | halt, ^o1.sLIST x 'x ist used Topic.Str.[ADR] := @"/1/2" 'Bitfields on struct members not working halt := taskhlt 'taskhlt : Register which holds the HALT bits (in reverse order) {Spin2_v47} [x] := o1.start() x.Part[0].adr := @"Uwe" 'struct not recognized if [x] and Meth 'Error ?????? 'bla,bla,bla{TestObj.spin2} {Spin2_v51} CON ' Constants struct sPART ( long adr, byte len ) struct sLIST(byte len, sPART Part[10]) VAR ' Variables sLIST List PUB start(): ^sLIST Result return @ListTested 0.47.1 on macOS 15.3.2...
Definitely better uploading to the P2. Even when I got a few "cant find a P2" dialogs, a press of the reset button and retry works!
dgately
Released version 0.47.2
Bugfix release for the reported issues:
Hi Macca,
All my current SPIN2 Projects can now compiled with Version 0.47.2
But the compiled code is so buggy that non of my programs are running.
PNUT v51.a can compile it and all the programs are running.
Sorry, I give up with Spin Tools and wait for PNUT-TS for MacOS.
The code snippet you posted above generates the exact same binary as PNut, I always use PNut binary as a reference and make sure that it generate the same code, however it is possible that some path don't generate the same code for some reasons, especially if you are heavily using the new features like structure and pointers with that weird and confusing syntax, if you want to share a code snippet that compiles but doesn't work as expected I can look at it and fix the issues. If you want I can also look at your whole verbatim source (privately if you can't share it, I can assure you that I'll not disclose it to anyone else).
Helping Macca would be more productive than just sitting around waiting.
Ok, I can try to find the problems and isolate them.
And yes, I use the new features like structure and pointers extensive.
I found 3 more compile errors and which line the program crashes.
After you find this Errors, I will test it with my programs.
maybe there are more errors.
{Spin2_v51} CON ' Constants _CLKFREQ = 160_000_000 struct sTOPIC ( Str, byte pos, byte key[1] ) VAR ' Variables sTOPIC Topic[4] PUB start() | i, x Topic[1].key[0] := 55 CompileErrors(@Topic[1]) repeat 4 with i x := @Topic[i].Str 'this Line crashes the program debug(uhex(x)) debug("loop ", sdec(i)) debug("loop End") PRI CompileErrors ( adr ): ^sTOPIC p | x [p] := adr 'x := p.key[p.pos++] 'compile Error x := p.key[p.pos] 'Workaround in two lines p.pos++ '<----- debug(sdec(x), uhex([p])) 'Error x = 55 '[p]~~ 'compile Error '[p]~ 'compile Error if [p] \ 0 'Workaround but not working debug(uhex([p])) 'this line is not executing, but shoud be debug("End CompileErrors")Just found a small "gotcha." I changed the font size for the editor and it seemed like the editor then mixed fonts.
I ended up closing and re-opening the file to get everything tidy again.
Released version 0.47.3
Another bugfix release for the reported issues mainly on pointer usage.
Took a lot of time to sort out all the syntax and it isn't yet 100% fixed, the reported snippets all compile binary exact as PNut, so I hope there are some less-used cases to fix.
Some fixes requires more deep changes in the compiler structure so will take more time.
Known issues so far:
@[ptr]is not working (compile error)buffer[[++]ptr]doesn't cause errors but the increment is applied to the pointed value and not to the pointer, the post-inc/dec howeverbuffer[ptr[++]]works (need a deep compiler change to fix).Changes:
Hi macca, i tested the new Vers. and found 1 Compile Error and 1 Runtime Error.
Here the Test-Prog.
{Spin2_v51} CON ' Constants _CLKFREQ = 160_000_000 struct sTOPIC ( Str, byte pos, byte key[1] ) VAR ' Variables sTOPIC Topic[4] PUB start() CompileErrors1(@Topic[1]) 'Runtime Error CompileErrors2(@Topic[1]) 'Runtime Error CompileErrors3(@Topic[1]) 'Runtime Error CompileErrors4(@Topic[1]) 'no Runtime Error Topic~ 'Compile Error PRI CompileErrors1 ( adr ): ^sTOPIC p | x 'local Var x is decl but not used [p] := adr debug("L17 ",uhex([p])) if [p]~ debug("L19 ",uhex([p])) 'this line is not executing, but shoud be debug("End CompileErrors1") PRI CompileErrors2 ( adr ): ^sTOPIC p 'no local Vars [p] := adr debug("L24 ",uhex([p])) if [p]~ debug("L26 ",uhex([p])) 'this line is now executing, but [p] shoud be 0 debug("End CompileErrors2") PRI CompileErrors3 ( adr ) | ^sTOPIC p 'p is now a local Var [p] := adr debug("L31 ",uhex([p])) if [p]~ debug("L33 ",uhex([p])) 'this line is not executing, but shoud be debug("End CompileErrors3") PRI CompileErrors4 ( adr ) 'no Runtime Errors debug("L37 ",uhex(adr)) if adr~ debug("L39 ",uhex(adr)) 'OK debug("End CompileErrors4")