I downloaded 1.39 and the LIB folder is gone. I assume, from the notes, that this was because the serial routines were updated. Can you please let me know what I have to do to use them? AdThanksVance
I downloaded 1.39 and the LIB folder is gone. I assume, from the notes, that this was because the serial routines were updated. Can you please let me know what I have to do to use them? AdThanksVance
The serial routines are in include/spin/ now. The default library path is "include", so you can (for example) refer to the SmartSerial routine as "spin/SmartSerial". See the code in samples/ for some examples.
The PrintfSerial code is gone because all of the serial versions (even P1 FullDuplexSerial) have a printf method now.
I think the issue is that loadp2 or its options have changed (since fastspin 1.3.6), and the runcmd config is not longer valid?
loadp2 has changed, but I'm not aware of any changes that should have broken the loading. I'll try to take a look later at Wine under Linux and see if I can reproduce it. In the meantime using the older loadp2 probably makes sense; the new loadp2 has some nice additions, but nothing critical.
Ooh, an odd one I've just noticed - fastspin opens source files in read-write mode, so fails on a read-only file,
and changes the last-modify timestamp which interacts badly with external editors. This is under wine on a Mac.
I think the issue is that loadp2 or its options have changed (since fastspin 1.3.6), and the runcmd config is not longer valid?
[ yes its something to do with loadp2, switching in the version from release 1.3.6 works ]
spin2gui 1.3.9 uses the latest version of loadp2, which uses a checksum in the -SINGLE mode. Earlier versions of loadp2 did not use a checksum. The NULL response indicates that loadp2 didn't wait long enough for the response. I call a waitdrain function that is suppose to return after the tx buffer is empty. On Linux and the Mac waitdrain calls tcdrain. This worked on another Mac, but some things that work on one Mac don't work on other Macs. On Windows waitdrain calls msleep(100) instead of tcdrain. Maybe I should use msleep(100) on all systems.
I'm thinking of just eliminating the waitdrain, and using a long delay like 200ms with rx_timeout when reading back the response. It seems like that should work for all platforms.
Ooh, an odd one I've just noticed - fastspin opens source files in read-write mode, so fails on a read-only file,
and changes the last-modify timestamp which interacts badly with external editors. This is under wine on a Mac.
The fastspin compiler itself (fastspin.exe) opens files read-only, as @yeti verified. The spin2gui IDE does open them read-write, since it is an editor, and in fact it saves the file before every compilation to make sure what you're compiling matches what you're editing.
I don't particularly recommend spin2gui; it more or less works, but it's something that I threw together fairly quickly just to give an IDE to people who really dislike the command line. There are better IDEs, like @Rayman's SpinEdit or one of the many IDEs like Geany or NotePad++ that can run external programs for compiling.
If you already have an external editor that you're using, I suggest that you use that and use a command line to compile your programs with fastspin. Usage is just:
fastspin -2 myfile.spin
to produce a P2 binary "myfile.binary" from "myfile.spin". spin2gui prints the exact command line it's using too, if you want to mimic it for things like finding library files or changing optimization options.
spin2gui 1.3.9 uses the latest version of loadp2, which uses a checksum in the -SINGLE mode. Earlier versions of loadp2 did not use a checksum. The NULL response indicates that loadp2 didn't wait long enough for the response. I call a waitdrain function that is suppose to return after the tx buffer is empty. On Linux and the Mac waitdrain calls tcdrain. This worked on another Mac, but some things that work on one Mac don't work on other Macs. On Windows waitdrain calls msleep(100) instead of tcdrain. Maybe I should use msleep(100) on all systems.
I think he's running loadp2 on the Mac, but using Wine to run the Windows version, which probably adds a whole new layer of uncertainty. Using tcdrain and msleep both seems like it would probably be the safest bet.
The behaviour I'd ideally expect from an unselfish editor is open file for reading only, saving the last-modify
timestamp on reading.
When the editor wants to save/auto-save it checks if the timestamp has changed and prompts for
confirmation if so, only then opening for writing. This means it doesn't clobber external modifications,
nor does it change the last-modify timestamp if it hasn't actually modified the file, and of course it can work
on read-only files and file systems.
A nice feature to have is a reload option to pick up external modifications, which only proceeds without
comfirmation if no local unsaved modifications have been made. Its useful to save a backup copy before
doing this so that this can be reverted if the external modification proves to be unwanted.
With all these precautions its intuitive to interwork with several editors on the same file, or with SCM tools
like git, without too much pain.
I've no idea if there's going to be any further work on spin2gui, so this is likely all academic
I've no idea if there's going to be any further work on spin2gui, so this is likely all academic
The source code for spin2gui is freely available, and I encourage those who are interested to contribute. I'm not averse to seeing it improved, I just don't have the cycles to do it myself right now.
The fastspin compiler itself (fastspin.exe) opens files read-only, as @yeti verified. The spin2gui IDE does open them read-write, since it is an editor, and in fact it saves the file before every compilation to make sure what you're compiling matches what you're editing.
Does it save-only-if-changed, or simply always save ?
The fastspin compiler itself (fastspin.exe) opens files read-only, as @yeti verified. The spin2gui IDE does open them read-write, since it is an editor, and in fact it saves the file before every compilation to make sure what you're compiling matches what you're editing.
Does it save-only-if-changed, or simply always save ?
It simply always saves. Yes, that's probably not the best way to do it. I really would encourage others to contribute better GUI/IDE code, or to use something like Geany or SpinEdit.
I wish the editor indicated (in a spin program at least) the indentation like Prop Tools does.
I don't know how to do that in Tcl. I think @Rayman 's SpinEdit program does that though, it's probably worth checking it out -- I think he's made the interface similar to PropTool, which will be much nicer than spin2gui.
I've created a new release, 3.9.22, of both spin2gui and fastspin (I've changed the version numbering of spin2gui to match fastspin to simplify things a bit). Links are:
If you're not familiar with fastspin, it's a compiler for PASM, Spin, BASIC, and C which can produce code for P1 or P2. The main language features are:
PASM: should be compatible with PNut, but adds #define and #ifdef and has warnings for some things like forgetting "wcz" on a "cmp" instruction.
Spin: a superset of Spin1, adding many Spin2 features like new operators, object pointers, and multiple return values, and a few other features like inline assembly and calling other languages. Documentation is in doc/spin.md or doc/spin.pdf.
BASIC: not PropBasic compatible, but rather more like QBasic or FreeBasic. It'll actually compile old school Basic programs with line numbers and GOTO / GOSUB, but it also has more modern features like lambdas. Able to use Spin objects directly. Documentation is in doc/basic.md or doc/basic.pdf.
C: The C compiler in fastspin is still under heavy development, and is still very incomplete. Eventually it should support all of C99, with extensions for calling out to BASIC and Spin functions, and inline assembly.
@Mark_T : the new spin2gui does not save unless the file is changed, and it checks for external changes before saving and before compiling. Use with caution, I'm not sure I caught all the possibilities, but it does seem to work when I edit a file with an external editor like emacs.
@Mark_T : the new spin2gui does not save unless the file is changed, and it checks for external changes before saving and before compiling. Use with caution, I'm not sure I caught all the possibilities, but it does seem to work when I edit a file with an external editor like emacs.
Great, that's really nice to have as it allows users to slip into their favorite editor for heavy editing code & it allows auto-generated files too.
Having this also eases pressure on adding new features in the spin2gui, as it cooperates well with other programs.
Does it have an option to silently auto-reload ? (useful for viewing generated files)
@Mark_T : the new spin2gui does not save unless the file is changed, and it checks for external changes before saving and before compiling. Use with caution, I'm not sure I caught all the possibilities, but it does seem to work when I edit a file with an external editor like emacs.
Does it have an option to silently auto-reload ? (useful for viewing generated files)
No, it doesn't have a silent re-load option, it always prompts. It does sound like an auto-reload option would be handy, thanks for the suggestion. (It's not too critical though because the compilation is done externally, so we'll always get the generated file; the prompt for reload only comes into play in the editor if you have one of the files open, and even if you don't reload the compiler will use the version on disk.)
Prompt to reload is fine.
What if the answer needs to be No?
Auto-reload is usually used for listing files, ie those that are created by the compiler where you want to scan to check code generated for example. You want that to be the newest copy, and there is no reason to say 'no'
The prompts ersmith mentions are needed when you have an Edited file, which changed inside spin2gui, and also changed on the disk - what to do then ? Usually due to a user oops...
edit -- Never mind. In the run command I used -PCOM9 instead of the correct -pCOM9. I downloaded spin2gui v 3.9.22 and unzipped it and set my com port in the configure run command. I tried running some of the samples. When I click on compile & run the screen quickly shows and closes a black window (looks like a command window) with some white text, (closes too quickly to read). Programs that flash leds don't flash anything.
I tried v 1.3.9 running the samples in the v 3.9.22 folder and they work.
Tom: glad you got the -pCOM9 sorted out. Just out of curiousity, does the "Port" menu and %P substitution work for you? That is, %P should put -pCOM9 in for you if you've selected COM9 in the Port menu.
Tom: glad you got the -pCOM9 sorted out. Just out of curiousity, does the "Port" menu and %P substitution work for you? That is, %P should put -pCOM9 in for you if you've selected COM9 in the Port menu.
Eric,
I tried using the port menu. I changed the configure run command back from -pCOM9 to %P. Then I clicked on port and checked my port (COM9). Clicked on compile & run and the program and terminal output worked.
When I then looked at the configure run command I saw that the %P was still there. No -pCOM9 had been added. That's great so it will be a lot easier to run programs on other boards (once we get them) without having to edit the configure.
Comments
the code loads and runs, its just the serial setup that has issue - I've copied my config from 1.3.6
which has compile config as:
runcmd {cmd.exe /c start "Propeller Output" "%D/bin/loadp2" -p COM1 -SINGLE -l230400 -b230400 "%B" -t -k}I think the issue is that loadp2 or its options have changed (since fastspin 1.3.6), and the runcmd config is not longer valid?
[ yes its something to do with loadp2, switching in the version from release 1.3.6 works ]
The serial routines are in include/spin/ now. The default library path is "include", so you can (for example) refer to the SmartSerial routine as "spin/SmartSerial". See the code in samples/ for some examples.
The PrintfSerial code is gone because all of the serial versions (even P1 FullDuplexSerial) have a printf method now.
Thanks, David, and thanks for your help with debugging the C compiler!
and changes the last-modify timestamp which interacts badly with external editors. This is under wine on a Mac.
spin2gui 1.3.9 uses the latest version of loadp2, which uses a checksum in the -SINGLE mode. Earlier versions of loadp2 did not use a checksum. The NULL response indicates that loadp2 didn't wait long enough for the response. I call a waitdrain function that is suppose to return after the tx buffer is empty. On Linux and the Mac waitdrain calls tcdrain. This worked on another Mac, but some things that work on one Mac don't work on other Macs. On Windows waitdrain calls msleep(100) instead of tcdrain. Maybe I should use msleep(100) on all systems.
Maybe Checksum choice, and even delay options, need to be command line explicit options ?
The fastspin compiler itself (fastspin.exe) opens files read-only, as @yeti verified. The spin2gui IDE does open them read-write, since it is an editor, and in fact it saves the file before every compilation to make sure what you're compiling matches what you're editing.
I don't particularly recommend spin2gui; it more or less works, but it's something that I threw together fairly quickly just to give an IDE to people who really dislike the command line. There are better IDEs, like @Rayman's SpinEdit or one of the many IDEs like Geany or NotePad++ that can run external programs for compiling.
If you already have an external editor that you're using, I suggest that you use that and use a command line to compile your programs with fastspin. Usage is just: to produce a P2 binary "myfile.binary" from "myfile.spin". spin2gui prints the exact command line it's using too, if you want to mimic it for things like finding library files or changing optimization options.
I think he's running loadp2 on the Mac, but using Wine to run the Windows version, which probably adds a whole new layer of uncertainty. Using tcdrain and msleep both seems like it would probably be the safest bet.
timestamp on reading.
When the editor wants to save/auto-save it checks if the timestamp has changed and prompts for
confirmation if so, only then opening for writing. This means it doesn't clobber external modifications,
nor does it change the last-modify timestamp if it hasn't actually modified the file, and of course it can work
on read-only files and file systems.
A nice feature to have is a reload option to pick up external modifications, which only proceeds without
comfirmation if no local unsaved modifications have been made. Its useful to save a backup copy before
doing this so that this can be reverted if the external modification proves to be unwanted.
With all these precautions its intuitive to interwork with several editors on the same file, or with SCM tools
like git, without too much pain.
I've no idea if there's going to be any further work on spin2gui, so this is likely all academic
The source code for spin2gui is freely available, and I encourage those who are interested to contribute. I'm not averse to seeing it improved, I just don't have the cycles to do it myself right now.
Does it save-only-if-changed, or simply always save ?
It simply always saves. Yes, that's probably not the best way to do it. I really would encourage others to contribute better GUI/IDE code, or to use something like Geany or SpinEdit.
Please leave it as simple as it is now, and do not try to make a 'better IDE' out of it. It is good as it is.
Enjoy!
Mike
I don't know how to do that in Tcl. I think @Rayman 's SpinEdit program does that though, it's probably worth checking it out -- I think he's made the interface similar to PropTool, which will be much nicer than spin2gui.
fastspin
spin2gui
If you're not familiar with fastspin, it's a compiler for PASM, Spin, BASIC, and C which can produce code for P1 or P2. The main language features are:
PASM: should be compatible with PNut, but adds #define and #ifdef and has warnings for some things like forgetting "wcz" on a "cmp" instruction.
Spin: a superset of Spin1, adding many Spin2 features like new operators, object pointers, and multiple return values, and a few other features like inline assembly and calling other languages. Documentation is in doc/spin.md or doc/spin.pdf.
BASIC: not PropBasic compatible, but rather more like QBasic or FreeBasic. It'll actually compile old school Basic programs with line numbers and GOTO / GOSUB, but it also has more modern features like lambdas. Able to use Spin objects directly. Documentation is in doc/basic.md or doc/basic.pdf.
C: The C compiler in fastspin is still under heavy development, and is still very incomplete. Eventually it should support all of C99, with extensions for calling out to BASIC and Spin functions, and inline assembly.
Great, that's really nice to have
Having this also eases pressure on adding new features in the spin2gui, as it cooperates well with other programs.
Does it have an option to silently auto-reload ? (useful for viewing generated files)
Excellent - I look forward to trying it out soon.
No, it doesn't have a silent re-load option, it always prompts. It does sound like an auto-reload option would be handy, thanks for the suggestion. (It's not too critical though because the compilation is done externally, so we'll always get the generated file; the prompt for reload only comes into play in the editor if you have one of the files open, and even if you don't reload the compiler will use the version on disk.)
What if the answer needs to be No?
Auto-reload is usually used for listing files, ie those that are created by the compiler where you want to scan to check code generated for example. You want that to be the newest copy, and there is no reason to say 'no'
The prompts ersmith mentions are needed when you have an Edited file, which changed inside spin2gui, and also changed on the disk - what to do then ? Usually due to a user oops...
edit -- Never mind. In the run command I used -PCOM9 instead of the correct -pCOM9.
I downloaded spin2gui v 3.9.22 and unzipped it and set my com port in the configure run command. I tried running some of the samples. When I click on compile & run the screen quickly shows and closes a black window (looks like a command window) with some white text, (closes too quickly to read). Programs that flash leds don't flash anything.
I tried v 1.3.9 running the samples in the v 3.9.22 folder and they work.
Any ideas?
Thanks
Tom
Eric,
I tried using the port menu. I changed the configure run command back from -pCOM9 to %P. Then I clicked on port and checked my port (COM9). Clicked on compile & run and the program and terminal output worked.
When I then looked at the configure run command I saw that the %P was still there. No -pCOM9 had been added. That's great so it will be a lot easier to run programs on other boards (once we get them) without having to edit the configure.
Tom