While doing some more testing, it has become apparent that the case sensitivity issue is becoming a real problem, and at the very least a PIA.
Most of the examples that I have come across have this problem. It seems like a lot of this stuff will have to be proof read and edited before you can actually do any thing with the program on a Linux system. So, what should be done, a separate OBEX for programs that will run on a Linux system without having to resort to proof reading and editing? Oh, I know, a "Gold Standard". Or, just get rid of support for Linux and other stuff, and just stick with Windows support, at least that way everybody will be on the same page.
In the options, I have PASM and Binary, but I noticed in my folder that it only contains .pasm file but no .binary file.
spincvt produced a PASM file, with this:
./bin/spin2cpp --noheader -g --asm --code=cog --data=hub --binary -o /home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.binary /home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.spin
/home/ray/Downloads/work/spincvt/examples/work/jm_ebadge_2015-07-01b.pasm:3111: error: fit 496 failed: pc is 1257
Notice the last line: there was an error (the code did not fit in COG memory). That's why there was no binary. You'll have to use LMM mode on that example.
BST on Linux doesn't require cases of OBJ filenames to match. Openspin does seem to, though. It probably wouldn't be a bad idea for you to fix this in spincvt, for compatibility reasons.
Hmmm, that's odd -- I wonder how Brad did that? I'm not even sure it's a good idea. In Linux "Foo.spin" and "foo.spin" are two completely different files; which one does bst use if they're both present?
While doing some more testing, it has become apparent that the case sensitivity issue is becoming a real problem, and at the very least a PIA.
Most of the examples that I have come across have this problem. It seems like a lot of this stuff will have to be proof read and edited before you can actually do any thing with the program on a Linux system. So, what should be done, a separate OBEX for programs that will run on a Linux system without having to resort to proof reading and editing?
There's not that much proof reading or editing needed -- it is *only* the object file names that are case sensitive on Linux, so it's not that hard to fix the problem when it arises. Everything else in the .spin file is case insensitive just like on Windows.
With the case issue that I cited, it ran with PropellerIDE without any issues. In fact PropellerIDE did produce a binary file. So, I guess PropellerIDE is using some kind of magic, but the problem remains, if you have a Foo and a foo program, how does PropellerIDE resolve that issue? I guess the simple answer is, don't produce a Foo and a foo program.
There is no "magic". It is a bug in Windows. Inherited from MSDOS. The underlying NTFS file system is case sensitive but the WIN32 API is not. See here: https://support.microsoft.com/en-us/kb/100625
As a result PropellerIDE does not have to do anything special when opening files, it just ends up ignoring case because of the Windows API.
With PropellerIDE you cannot have a "foo" and a "Foo" program, Windows won't see one of them.
Yep, in general I would think having a "Foo" and a "foo" is not a good idea but there may be good reasons to want to do it.
Also I hate to see upper case and spaces and other weird characters in file names.
I tried the suggestion that Eric had made, use the LMM feature, the program works as expected. It also produced an 8.8 kB binary file.
Now, I am scratching my head, and wondering why the example program runs as is with PropellerIDE and with spincvt you have to implement LMM? And I guess the follow up question is, how do you determine when to use the spinconvert program for maximum efficiency?
Now, I am scratching my head, and wondering why the example program runs as is with PropellerIDE and with spincvt you have to implement LMM? And I guess the follow up question is, how do you determine when to use the spinconvert program for maximum efficiency?
Again, I think you've misunderstood what PropellerIDE does and what spinconvert does. PropellerIDE translates Spin files into spin bytecode (.binary). There's no notion of LMM for this; the spin byte codes are always in HUB memory, and are always read and interpreted by an program in ROM (the "Spin interpreter"). Byte codes are very small and space efficient, but the process of interpretation is slow.
spinconvert, on the other hand, translates Spin files into machine language (PASM). This also goes into a .binary file, but that's where the similarity with bytecode ends. The machine language can be directly executed by a COG, if it will fit in COG memory. If it does not fit in COG memory, it can be run with a very simple program (the "LMM kernel") that fetches the instructions from HUB and runs them in COG. LMM mode is slower than COG mode, but is still way faster than spin bytecode. It's a lot bigger than bytecode, though.
So the choice is: a big PASM binary file that executes quickly (spinconvert) or a much smaller but slower bytecode binary file (PropellerIDE). The choice is about trading memory space for speed. For a small program I would choose spinconvert, since the output will run much faster. For a *very* small program I would compile without LMM, for the fastest possible result, but only very small programs can fit into a COG. In fact LMM is what you'll normally have to use, and I'll make that the default in the next version of spinconvert.
For a large program the spinconvert code might not even fit in HUB memory, and then you'll have to use PropellerIDE (or bst, which also translates to spin byte codes).
Expanding the exploration process of spincvt, I will be trying out the next logical item, for me, anyways, the C option.
First off I notice that there is no CMM option, will that be added at some point? And if so, will you be able to make and run a Spin file(PASM?) with that option?
When you do a conversion to C, does all of the resulting programs have a Main function, or is there a way of creating a Main-less function without resorting to spin2cpp? I guess this should suffice for now.
The following is just using the C option with hello.spin. Not working as expected.
./bin/spin2cpp --noheader --ccode --binary -O -o /home/ray/Downloads/work/spincvt/temp/hello.binary /home/ray/Downloads/work/spincvt/temp/hello.spin
sh: 1: propeller-elf-gcc: not found
child process exited abnormally
Application error
Propeller Version 1 on /dev/ttyUSB0
error: failed to open '/home/ray/Downloads/work/spincvt/temp/hello.binary'
error: load failed
child process exited abnormally
Propeller Version 1 on /dev/ttyUSB0
error: failed to open '/home/ray/Downloads/work/spincvt/temp/hello.binary'
error: load failed
child process exited abnormally
while executing
"exec bin/propeller-load -r $binfile"
(procedure "doRun" line 19)
invoked from within
"doRun "
invoked from within
".#mbar.#mbar#run invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0
"
(procedure "tk::MenuInvoke" line 50)
invoked from within
"tk::MenuInvoke .#mbar.#mbar#run 1"
(command bound to event)
In the Application error window, I see failed to open ...hello.binary, in the folder I do not see that file. When using the C option, are you also supposed to use the binary option? You would think that would be a default setting.
spin2cpp is not capable of compiling C/C++ code. It can create it, but it can't compile it. So if you want to convert a Spin file to a binary file with C or C++ in the middle, then you need propgcc available for the second step. The first error tells you that spin2cpp was unable to find propgcc. I would take a gander that spin2cpp searches for propgcc on your PATH and only on your PATH, so you'll need to modify your PATH variable before it will function as you expect.
I think Eric is probably regretting adding that RUN option to spincvt. A big note in spincvt should be displayed that C/C++ conversions cannot be RUN with spincvt. Although, it would be a very convenient item to add too spincvt, that way you could do a quick test and see if that is what you are after with the Spin conversion.
I think Eric is probably regretting adding that RUN option to spincvt. A big note in spincvt should be displayed that C/C++ conversions cannot be RUN with spincvt. Although, it would be a very convenient item to add too spincvt, that way you could do a quick test and see if that is what you are after with the Spin conversion.
Ray
But they can be run with spincvt. You just need to add PropGCC's bin directory to your PATH.
I just checked the bin folder in spincvt, it only has propeller-load and spin2cpp, I guess he would have to include PropGCC in there also. I think most people that are trying spincvt out, are not going to do a separate PropGCC install.
So, do you remove C/C++ options from spincvt? I know that I am not going to be the first person that would think that the RUN option should be available for C/C++ option with the spincvt program.
I went ahead and installed SimpleIDE on my Ubuntu system, and I also used spincvt on hello.spin, to see how it ran as a C program.
Refresher course:
Spincvt creates hello.c, hello.h, SimpleSerial.c, and SimpleSerial.h, what to do next, with SimpleIDE. In the earlier edition(s) of SimpleIDE, you were able to 'Open file', and then do a conversion of that to a Project file, that is no longer available.
Now the procedure is, using SimpleIDE, you have to create a hello project, then you have to cut and paste the contents of hello.c into the newly created hello project file. Then you have to switch over to Project Manager mode to include SimpleSerial.c and SimpleSerial.h to the hello project file, and then... ???
I guess the other method is the command line alternative, use the PropGCC commands to compile hello.c and then Propeller-load to load the new hello program. I am not so sure which method is the easiest at this point, lots of bumps in the road to get a spincvt to C converted program to run. Easy peasy, I wonder why not more people are using this method, or the SimpleIDE method, for that matter.
I think spincvt(spinconvert) is a very good idea, but the difficulties start after the Spin conversion process, just my two cents on the matter.
Use the --binary option. There is no need for you to invoke PropGCC, spin2cpp/spincvt will do that for you.
I will let Eric answer the question of the PATH variable. Since you used SimpleIDE to acquire PropGCC, I don't know if spin2cpp is smart enough to look in the default installation directory (/opt/parallax) or if you'll need to add /opt/parallax/bin to your PATH. If you do need it on your PATH, run "sudo gedit /etc/environment" and then add the following line to it
PATH="$PATH:/opt/parallax/bin"
and then save and exit. A reboot will allow that change to take affect. Placing this change in /etc/environment will allow GUI programs like spincvt to pick it up. If you start everything from the command line (as opposed to double-clicking an icon on your Desktop or in the file manager) then you only need to add it to your PATH in your local account:
Open ~/.bashrc: "gedit ~/.bashrc"
Add the following line:
export PATH="$PATH:/opt/parallax/bin"
This only takes closing and re-opening your terminal to activate
Sorry, I've been very busy with some other things, but it looks like others have stepped up to answer the questions here (thanks!).
I'll try to make a minor release this weekend with the Windows version of the new GUI and all the bug fixes so far. I've been working on P2 support, but that will take a bit longer.
There's an updated version (v3.0.4) on https://github.com/totalspectrum/spin2cpp/releases. P2 support isn't working yet, but there are a few bug fixes and optimization improvements, and a few new options in the GUI.
Sorry if I'm being an idiot somewhere along the way, but I have downloaded and unzipped both the zip, and tar files from GitHub, and even my PC can't find spincvt with any extension anywhere.
What have I missed?
Sorry if I'm being an idiot somewhere along the way, but I have downloaded and unzipped both the zip, and tar files from GitHub, and even my PC can't find spincvt with any extension anywhere.
What have I missed?
I've updated the first post with more recent information. spin2cpp/fastspin has had Propeller 2 support for a while now, but that wasn't mentioned on this forum. I've also added FCACHE to the Propeller 1 assembly output. FCACHE is a way to run small loops directly in COG memory instead of using the LMM interpreter to run them from HUB. For some things this can result in a significant speed-up.
I've updated the first post with more recent information. spin2cpp/fastspin has had Propeller 2 support for a while now, but that wasn't mentioned on this forum. I've also added FCACHE to the Propeller 1 assembly output. FCACHE is a way to run small loops directly in COG memory instead of using the LMM interpreter to run them from HUB. For some things this can result in a significant speed-up.
Parallax should consider adopting FastSpin as the official Spin compiler for the P2!
I've updated the first post with more recent information. spin2cpp/fastspin has had Propeller 2 support for a while now, but that wasn't mentioned on this forum. I've also added FCACHE to the Propeller 1 assembly output. FCACHE is a way to run small loops directly in COG memory instead of using the LMM interpreter to run them from HUB. For some things this can result in a significant speed-up.
Parallax should consider adopting FastSpin as the official Spin compiler for the P2!
Can't go quite that far until it merges with OpenSpin/bstc/HomeSpun. I'd say a fourth option is to implement a CMM option, but that seems silly when the Prop has the Spin interpreter in ROM already. CMM might also be a valid feature of FastSpin, but FastSpin can't be the Spin compiler until it can compile native Spin bytecode.
Parallax should consider adopting FastSpin as the official Spin compiler for the P2!
Well, except that fastspin output (being LMM code) is about 4x bigger than Spin output. So there's a tradeoff there. I think it's nice that both openspin and fastspin exist, they complement each other.
I've updated the first post with more recent information. spin2cpp/fastspin has had Propeller 2 support for a while now, but that wasn't mentioned on this forum. I've also added FCACHE to the Propeller 1 assembly output. FCACHE is a way to run small loops directly in COG memory instead of using the LMM interpreter to run them from HUB. For some things this can result in a significant speed-up.
Parallax should consider adopting FastSpin as the official Spin compiler for the P2!
Can't go quite that far until it merges with OpenSpin/bstc/HomeSpun. I'd say a fourth option is to implement a CMM option, but that seems silly when the Prop has the Spin interpreter in ROM already. CMM might also be a valid feature of FastSpin, but FastSpin can't be the Spin compiler until it can compile native Spin bytecode.
I'm not sure that I believe that there will be a single tool that will compile both P1 Spin and P2 Spin. My guess is that they will be two separate compilers with different language features. In that case, there is no reason FastSpin couldn't be the compiler for the P2.
Parallax should consider adopting FastSpin as the official Spin compiler for the P2!
Well, except that fastspin output (being LMM code) is about 4x bigger than Spin output. So there's a tradeoff there. I think it's nice that both openspin and fastspin exist, they complement each other.
I'm talking about Spin on the P2 not the P1. There you might be able to tolerate the lower code density to gain much better performance. And if better code density is really needed, I guess you could implement CMM on the P2.
Comments
Most of the examples that I have come across have this problem. It seems like a lot of this stuff will have to be proof read and edited before you can actually do any thing with the program on a Linux system. So, what should be done, a separate OBEX for programs that will run on a Linux system without having to resort to proof reading and editing? Oh, I know, a "Gold Standard". Or, just get rid of support for Linux and other stuff, and just stick with Windows support, at least that way everybody will be on the same page.
Ray
Compiling with -mcog didn't work (the result was too big to fit in COG memory).
Hmmm, that's odd -- I wonder how Brad did that? I'm not even sure it's a good idea. In Linux "Foo.spin" and "foo.spin" are two completely different files; which one does bst use if they're both present?
There's not that much proof reading or editing needed -- it is *only* the object file names that are case sensitive on Linux, so it's not that hard to fix the problem when it arises. Everything else in the .spin file is case insensitive just like on Windows.
Eric
Ray
As a result PropellerIDE does not have to do anything special when opening files, it just ends up ignoring case because of the Windows API.
With PropellerIDE you cannot have a "foo" and a "Foo" program, Windows won't see one of them.
Yep, in general I would think having a "Foo" and a "foo" is not a good idea but there may be good reasons to want to do it.
Also I hate to see upper case and spaces and other weird characters in file names.
Now, I am scratching my head, and wondering why the example program runs as is with PropellerIDE and with spincvt you have to implement LMM? And I guess the follow up question is, how do you determine when to use the spinconvert program for maximum efficiency?
Ray
Again, I think you've misunderstood what PropellerIDE does and what spinconvert does. PropellerIDE translates Spin files into spin bytecode (.binary). There's no notion of LMM for this; the spin byte codes are always in HUB memory, and are always read and interpreted by an program in ROM (the "Spin interpreter"). Byte codes are very small and space efficient, but the process of interpretation is slow.
spinconvert, on the other hand, translates Spin files into machine language (PASM). This also goes into a .binary file, but that's where the similarity with bytecode ends. The machine language can be directly executed by a COG, if it will fit in COG memory. If it does not fit in COG memory, it can be run with a very simple program (the "LMM kernel") that fetches the instructions from HUB and runs them in COG. LMM mode is slower than COG mode, but is still way faster than spin bytecode. It's a lot bigger than bytecode, though.
So the choice is: a big PASM binary file that executes quickly (spinconvert) or a much smaller but slower bytecode binary file (PropellerIDE). The choice is about trading memory space for speed. For a small program I would choose spinconvert, since the output will run much faster. For a *very* small program I would compile without LMM, for the fastest possible result, but only very small programs can fit into a COG. In fact LMM is what you'll normally have to use, and I'll make that the default in the next version of spinconvert.
For a large program the spinconvert code might not even fit in HUB memory, and then you'll have to use PropellerIDE (or bst, which also translates to spin byte codes).
First off I notice that there is no CMM option, will that be added at some point? And if so, will you be able to make and run a Spin file(PASM?) with that option?
When you do a conversion to C, does all of the resulting programs have a Main function, or is there a way of creating a Main-less function without resorting to spin2cpp? I guess this should suffice for now.
Ray
Application error
In the Application error window, I see failed to open ...hello.binary, in the folder I do not see that file. When using the C option, are you also supposed to use the binary option? You would think that would be a default setting.
Ray
spin2cpp is not capable of compiling C/C++ code. It can create it, but it can't compile it. So if you want to convert a Spin file to a binary file with C or C++ in the middle, then you need propgcc available for the second step. The first error tells you that spin2cpp was unable to find propgcc. I would take a gander that spin2cpp searches for propgcc on your PATH and only on your PATH, so you'll need to modify your PATH variable before it will function as you expect.
Ray
But they can be run with spincvt. You just need to add PropGCC's bin directory to your PATH.
So, do you remove C/C++ options from spincvt? I know that I am not going to be the first person that would think that the RUN option should be available for C/C++ option with the spincvt program.
Ray
Perhaps that's true. Perhaps it's not. It's certainly not hard though. Download. Extract. Edit PATH. Done.
I don't think so. Perhpas, at most, a dialogue explaining that PropGCC can't be found if the user selects C/C++ mode without having PropGCC on PATH.
Refresher course:
Spincvt creates hello.c, hello.h, SimpleSerial.c, and SimpleSerial.h, what to do next, with SimpleIDE. In the earlier edition(s) of SimpleIDE, you were able to 'Open file', and then do a conversion of that to a Project file, that is no longer available.
Now the procedure is, using SimpleIDE, you have to create a hello project, then you have to cut and paste the contents of hello.c into the newly created hello project file. Then you have to switch over to Project Manager mode to include SimpleSerial.c and SimpleSerial.h to the hello project file, and then... ???
I guess the other method is the command line alternative, use the PropGCC commands to compile hello.c and then Propeller-load to load the new hello program. I am not so sure which method is the easiest at this point, lots of bumps in the road to get a spincvt to C converted program to run. Easy peasy, I wonder why not more people are using this method, or the SimpleIDE method, for that matter.
I think spincvt(spinconvert) is a very good idea, but the difficulties start after the Spin conversion process, just my two cents on the matter.
Ray
I will let Eric answer the question of the PATH variable. Since you used SimpleIDE to acquire PropGCC, I don't know if spin2cpp is smart enough to look in the default installation directory (/opt/parallax) or if you'll need to add /opt/parallax/bin to your PATH. If you do need it on your PATH, run "sudo gedit /etc/environment" and then add the following line to it
and then save and exit. A reboot will allow that change to take affect. Placing this change in /etc/environment will allow GUI programs like spincvt to pick it up. If you start everything from the command line (as opposed to double-clicking an icon on your Desktop or in the file manager) then you only need to add it to your PATH in your local account:
Open ~/.bashrc: "gedit ~/.bashrc"
Add the following line:
This only takes closing and re-opening your terminal to activate
I'll try to make a minor release this weekend with the Windows version of the new GUI and all the bug fixes so far. I've been working on P2 support, but that will take a bit longer.
Eric
What have I missed?
The .tar file (and one of the .zip files) is the source code, which you only want if you're planning to build it yourself from source. Try downloading https://github.com/totalspectrum/spin2cpp/releases/download/v3.0.5/spincvt.zip.
Can't go quite that far until it merges with OpenSpin/bstc/HomeSpun. I'd say a fourth option is to implement a CMM option, but that seems silly when the Prop has the Spin interpreter in ROM already. CMM might also be a valid feature of FastSpin, but FastSpin can't be the Spin compiler until it can compile native Spin bytecode.
Well, except that fastspin output (being LMM code) is about 4x bigger than Spin output. So there's a tradeoff there. I think it's nice that both openspin and fastspin exist, they complement each other.