Will this work on any linux? I'd could give it a try and give comments, if it at the review stage.
I have ubuntu 13.10 with Mint 16 Petra, this is the only arrangement that is useable and runs Left4Dead2 properly.
I've been running virtualbox sessions for configurations that require installs that could screw up the rest of the system, for example anything windows. I was thinking of trying to build open spin on a virtual machinge. But I found that the USB virtual comports get weird, Virtualbox must be run as superuser to use the USB. The windows virtual machine running Go has had trouble talking to the prop, either the USB port, the prop, or the go interface program lock up intermittently.
I'd like to give it a try when we get this sorted out.
Just curious. I'm getting a RaspPi soon and am wondering what to do with it other than trying to talk to a Propeller from some of its GPIO pins.
I had the Pi running nginx serving up from an old 80GB hard drive in an external USB box. Worked a treat. I might try moving the blog thing there just to see how it goes.
What you need is a node.js based web server on the Pi tweaking those GPIO via a web interface:)
I didn't want to get into the details of that installation in my document. These things are well documented elsewhere.
It would be great if you could follow along and see that everything makes sense.
Cute but it's a bit slow:
/var/root # time cc hello.c
real 0m 7.01s
user 0m 6.26s
sys 0m 0.76s
/var/root # cat hello.c
/* This C source can be compiled with:
tcc -o hello hello.c
or if you have more time:
gcc -o hello hello.c
*/
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello World\n");
return 0;
}
In fact, the first time I tried this it took considerably longer.
I do get the usage instructions, but when I try to compile a simple test.spin, I get an error:
$ ~/source/openspin]$ node openspin.js test.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Jan 1 2014
Compiling...
test.spin
test.spin : error : Can not find/open file.
$ ~/source/openspin]$ ls
Makefile PropellerCompiler.sln openspin openspin.dSYM openspin.js.map test.spin
PropellerCompiler SpinSource openspin.bc openspin.js openspin.sln wiki
$ ~/source/openspin]$ cat test.spin
''This code example is from Propeller Education Kit Labs: Fundamentals, v1.1.
''A .pdf copy of the book is available from www.parallax.com, and also through
''the Propeller Tool software's Help menu (v1.2.6 or newer).
''
'' File: LedOnOffP26.spin
PUB LedOnOff
dira[1] := 1
repeat
outa[1] := 1
waitcnt(clkfreq/4 + cnt)
outa[1] := 0
waitcnt(clkfreq/4*3 + cnt)
I do get the usage instructions, but when I try to compile a simple test.spin, I get an error:
Looking back in the log, I see that the emcc exec had some issues finding sources that are inside /openspin/PropellerCompiler/... I'm assuming this may be the problem, but not sure how it could be fixed.
$ ~/source/openspin]$ emcc -o openspin.js openspin.bc
sourcemapper: Unable to find original file for PropellerCompiler.cpp at /Users/myUser/source/openspin/PropellerCompiler.cpp
sourcemapper: Unable to find original file for ./Elementizer.h at /Users/myUser/source/openspin/Elementizer.h
sourcemapper: Unable to find original file for SymbolEngine.cpp at /Users/myUser/source/openspin/SymbolEngine.cpp
sourcemapper: Unable to find original file for ./Utilities.h at /Users/myUser/source/openspin/Utilities.h
sourcemapper: Unable to find original file for ./SymbolEngine.h at /Users/myUser/source/openspin/SymbolEngine.h
sourcemapper: Unable to find original file for Utilities.cpp at /Users/myUser/source/openspin/Utilities.cpp
sourcemapper: Unable to find original file for CompileDatBlocks.cpp at /Users/myUser/source/openspin/CompileDatBlocks.cpp
sourcemapper: Unable to find original file for DistillObjects.cpp at /Users/myUser/source/openspin/DistillObjects.cpp
sourcemapper: Unable to find original file for Elementizer.cpp at /Users/myUser/source/openspin/Elementizer.cpp
sourcemapper: Unable to find original file for ExpressionResolver.cpp at /Users/myUser/source/openspin/ExpressionResolver.cpp
sourcemapper: Unable to find original file for InstructionBlockCompiler.cpp at /Users/myUser/source/openspin/InstructionBlockCompiler.cpp
sourcemapper: Unable to find original file for StringConstantRoutines.cpp at /Users/myUser/source/openspin/StringConstantRoutines.cpp
sourcemapper: Unable to find original file for BlockNestStackRoutines.cpp at /Users/myUser/source/openspin/BlockNestStackRoutines.cpp
sourcemapper: Unable to find original file for CompileExpression.cpp at /Users/myUser/source/openspin/CompileExpression.cpp
sourcemapper: Unable to find original file for CompileInstruction.cpp at /Users/myUser/source/openspin/CompileInstruction.cpp
sourcemapper: Unable to find original file for CompileUtilities.cpp at /Users/myUser/source/openspin/CompileUtilities.cpp
...when I try to compile a simple test.spin, I get an error:...
Yep. That is normal.
There is a weird thing going on here. The the compiled JS will take command line parameters but it has no way to access your file system to find test,spin.
It actually uses some kind of internal "virtual" file system which is of course empty.
What you can do is populate that virtual file system with the Spin file you want to compile by embedding it in the generated JS:
Then you can compile the embedded test.spin from node:
$ node openspin.js test.spin
Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax
Semiconductor.
Compiled on Jan 1 2014
Compiling...
test.spin
Warning: Enlarging memory arrays, this is not fast, and ALLOW_MEMORY_GROWTH is
not fully tested with all optimizations on! 41193472,33554432
Done.
Program size is 3068 bytes
Now this is annoying. It's all because JS in the browser cannot access your local file system.
I suspect one can program some hooks into the node build to get from the virtual FS to the real one.
I was just writing about this in part 2 of my instructions....
Attached is a demo of openspin.js working in a web page. Just unpack it somewhere and point your browser at the HTML file.
You should get a text area into which you can type Spin code, it is pre-populated with a fibo program. Then hit compile and you should see the compiler output followed by a hex dump of the resulting binary.
It sort of works, there are some issues to sort out which I'm sure you will discover
I'll be updating the emscripten build instructions to match this.
Attached is a demo of openspin.js working in a web page. Just unpack it somewhere and point your browser at the HTML file.
You should get a text area into which you can type Spin code, it is pre-populated with a fibo program. Then hit compile and you should see the compiler output followed by a hex dump of the resulting binary.
It sort of works, there are some issues to sort out which I'm sure you will discover
I'll be updating the emscripten build instructions to match this.
Congratulations! It works for me on my MacBook Pro under Safari. Now we just need a way to download to the Propeller.
OK that's good. Hope you like the retro green screens.
My plan for loading the Propeller is to make a simple server in node.js that accepts the binary via a websocket connection and passes it to a loader.
Of course with that in place we may as well do the compilation of the server but hey, where is the fun in that?
Just now I've been playing with the ACE WEB editor component. Should be a simple drop in for that text area. Configuring it's syntax highlighting for Spin looks like a challenge.
Then we need to support multiple Spin files in a program etc etc etc.
You will find that if you hit compile a bunch of times this thing uses up more and more memory and eventually jams up.
Now I'm not sure but I think this is because programs tend not to clean everything up when they exit. Open spin has a bunch of global stuff which is not reinitialized when you run main again as we do.
Reading around there are two solutions to this:
1) Get the JS to reinitialize its state before running main again. I tried this but could not get it to work.
2) Modify the original C++ code to clean up after itself.
You will find that if you hit compile a bunch of times this thing uses up more and more memory and eventually jams up.
Now I'm not sure but I think this is because programs tend not to clean everything up when they exit. Open spin has a bunch of global stuff which is not reinitialized when you run main again as we do.
Reading around there are two solutions to this:
1) Get the JS to reinitialize its state before running main again. I tried this but could not get it to work.
2) Modify the original C++ code to clean up after itself.
I have to look into this more.
Isn't there any way to cause the memory to be freed on a call to exit()? I think many C programs assume that exiting is sufficient to clean up resources.
Googling around it seems others have run into this issue.
Yes, normally one might not bother freeing all memory or closing all files, ports sockets etc because the OS will do that on exit.
Turns out it's not so easy to get that JS back to it's initial state like that,
I did find a solution somewhere that involved wrapping the entire generated code in function in such a way that it all got reevaluated from scratch on demand. I didn't exactly understand it, I tried it and it did not work and now I can't find it again!
Example: Openspin keeps track of the level of nesting of Spin files as it goes. That level is global and initialized to zero. If a compilation errors out and you run it again then the level may not be zero.
OK that's good. Hope you like the retro green screens.
My plan for loading the Propeller is to make a simple server in node.js that accepts the binary via a websocket connection and passes it to a loader.
Of course with that in place we may as well do the compilation of the server but hey, where is the fun in that?
Just now I've been playing with the ACE WEB editor component. Should be a simple drop in for that text area. Configuring it's syntax highlighting for Spin looks like a challenge.
Then we need to support multiple Spin files in a program etc etc etc.
Do you plan to use propeller-load? You'll need that if you want to load programs that use XMM. i know that OpenSpin doesn't support XMM but I assume that the plan is to eventually support C as well as Spin.
I have no plan to tackle a browser based C compiler.
When it comes to C we have things like the Cloud9 IDE, as used on the Beagle boards, that could be used to compile on a server. I guess that could be adapted to use propgcc and do the loading. That might be a job for someone else though.
I have no plan to tackle a browser based C compiler.
When it comes to C we have things like the Cloud9 IDE, as used on the Beagle boards, that could be used to compile on a server. I guess that could be adapted to use propgcc and do the loading. That might be a job for someone else though.
Really? You recently showed me that Linux could be booted in a browser. I figured you were getting ready to port propgcc! :-)
Could you guys check out openspin_web_demo2 attached on some different browsers?
The issue I'm trying to fix here is that every time you hit the compile button a huge lot of memory was being leaked.
I found a solution that suggested wrapping the entire emscripten generated javascript in a function such that everything it creates in memory is destroyed when the function exits.
Having wrapped the compiler up like that it seems to run without leaks on my FireFox but still has the same problem in Chrome (On Debian).
It's also a bit slower because it recreates and tears down the entire run time of the compiler every time. Perhaps not to bad though.
Has anyone tried this on a tablet browser? Do tablets have enough memory to run the emscripten generated version of OpenSpin? What is the performance like?
Currently running under firefox the thing works in about 256MB of space and compiles the little demo in the blink of an eye. So we might be in with a chance on tablets.
P.S. That memory leak still seems to be there in FF but a lot less severe.
Currently running under firefox the thing works in about 256MB of space and compiles the little demo in the blink of an eye. So we might be in with a chance on tablets.
P.S. That memory leak still seems to be there in FF but a lot less severe.
Just so you don't think I'm completely Apple-centric, I tried this on my Nook HD under Chrome. :-)
When I first pressed the "Compile" button it seemed that nothing was happening. I waited a minute or two and then pressed it again and got a response. I'm not sure if it really took that long or if I hadn't actually pressed the button the first time. In any case, it worked! If I press the compile button again I get a response almost immediately.
Comments
-Phil
Will this work on any linux? I'd could give it a try and give comments, if it at the review stage.
I have ubuntu 13.10 with Mint 16 Petra, this is the only arrangement that is useable and runs Left4Dead2 properly.
I've been running virtualbox sessions for configurations that require installs that could screw up the rest of the system, for example anything windows. I was thinking of trying to build open spin on a virtual machinge. But I found that the USB virtual comports get weird, Virtualbox must be run as superuser to use the USB. The windows virtual machine running Go has had trouble talking to the prop, either the USB port, the prop, or the go interface program lock up intermittently.
I'd like to give it a try when we get this sorted out.
What you need is a node.js based web server on the Pi tweaking those GPIO via a web interface:) Yes, see my shiny new blog for a little benchmarking. a.linuxsecured.net/openspin-js-performance You can't?
Check this out: http://bellard.org/jslinux/ Yep, run a PC emulation in your browser, which boots linux. From there you can use GCC !
Realistically I don't see GCC working via Emscripten very soon. However the Emscripten guys have built some huge programs with it.
It should work on any recent Linux. There are instructions for getting Emscripten working on Ubuntu here: https://github.com/kripken/emscripten/wiki/Getting-Started-on-Ubuntu-12.10
I didn't want to get into the details of that installation in my document. These things are well documented elsewhere.
It would be great if you could follow along and see that everything makes sense.
/var/root # time cc hello.c real 0m 7.01s user 0m 6.26s sys 0m 0.76s /var/root # cat hello.c /* This C source can be compiled with: tcc -o hello hello.c or if you have more time: gcc -o hello hello.c */ #include <stdlib.h> #include <stdio.h> int main(int argc, char **argv) { printf("Hello World\n"); return 0; }In fact, the first time I tried this it took considerably longer.Yep, slow. Amazing it works at all. tcc is faster here under firefox.
gcc however crashes it !
I'm working through the Part 1 instructions and came to:
Should this show a change to:
dgately
I do get the usage instructions, but when I try to compile a simple test.spin, I get an error:
$ ~/source/openspin]$ node openspin.js test.spin Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor. Compiled on Jan 1 2014 Compiling... test.spin test.spin : error : Can not find/open file. $ ~/source/openspin]$ ls Makefile PropellerCompiler.sln openspin openspin.dSYM openspin.js.map test.spin PropellerCompiler SpinSource openspin.bc openspin.js openspin.sln wiki $ ~/source/openspin]$ cat test.spin ''This code example is from Propeller Education Kit Labs: Fundamentals, v1.1. ''A .pdf copy of the book is available from www.parallax.com, and also through ''the Propeller Tool software's Help menu (v1.2.6 or newer). '' '' File: LedOnOffP26.spin PUB LedOnOff dira[1] := 1 repeat outa[1] := 1 waitcnt(clkfreq/4 + cnt) outa[1] := 0 waitcnt(clkfreq/4*3 + cnt)Looking back in the log, I see that the emcc exec had some issues finding sources that are inside /openspin/PropellerCompiler/... I'm assuming this may be the problem, but not sure how it could be fixed.
And, Part 1 lists the following command:
should be:
Thanks,
dgately
There is a weird thing going on here. The the compiled JS will take command line parameters but it has no way to access your file system to find test,spin.
It actually uses some kind of internal "virtual" file system which is of course empty.
What you can do is populate that virtual file system with the Spin file you want to compile by embedding it in the generated JS: Then you can compile the embedded test.spin from node: Now this is annoying. It's all because JS in the browser cannot access your local file system.
I suspect one can program some hooks into the node build to get from the virtual FS to the real one.
I was just writing about this in part 2 of my instructions....
Yep, I get those "Unable to find original file for..." errors as well.
If you look in the generated openspin.js you will see lines like: Where clearly it is relating generated JS with the original C++ source file statements:
But you will also find a lot of generated code where there is no C++ reference.
Seems to work anyway, Not sure how to get rid of those errors. Is fixed. Thanks for looking at this.
Had to install a new linux vm ... chose Mint 16 Cinnamon i686 this time.
Also, I had to comment out the CC=gcc and CXX=g++ in the openspin Makefile.
Will do more later.
Thanks! I get it now... As long as the binary is eventually able to get loaded onto a prop, it will work.
dgately
Attached is a demo of openspin.js working in a web page. Just unpack it somewhere and point your browser at the HTML file.
You should get a text area into which you can type Spin code, it is pre-populated with a fibo program. Then hit compile and you should see the compiler output followed by a hex dump of the resulting binary.
It sort of works, there are some issues to sort out which I'm sure you will discover
I'll be updating the emscripten build instructions to match this.
dgately
My plan for loading the Propeller is to make a simple server in node.js that accepts the binary via a websocket connection and passes it to a loader.
Of course with that in place we may as well do the compilation of the server but hey, where is the fun in that?
Just now I've been playing with the ACE WEB editor component. Should be a simple drop in for that text area. Configuring it's syntax highlighting for Spin looks like a challenge.
Then we need to support multiple Spin files in a program etc etc etc.
You will find that if you hit compile a bunch of times this thing uses up more and more memory and eventually jams up.
Now I'm not sure but I think this is because programs tend not to clean everything up when they exit. Open spin has a bunch of global stuff which is not reinitialized when you run main again as we do.
Reading around there are two solutions to this:
1) Get the JS to reinitialize its state before running main again. I tried this but could not get it to work.
2) Modify the original C++ code to clean up after itself.
I have to look into this more.
Yes, normally one might not bother freeing all memory or closing all files, ports sockets etc because the OS will do that on exit.
Turns out it's not so easy to get that JS back to it's initial state like that,
I did find a solution somewhere that involved wrapping the entire generated code in function in such a way that it all got reevaluated from scratch on demand. I didn't exactly understand it, I tried it and it did not work and now I can't find it again!
Example: Openspin keeps track of the level of nesting of Spin files as it goes. That level is global and initialized to zero. If a compilation errors out and you run it again then the level may not be zero.
I have no plan to tackle a browser based C compiler.
When it comes to C we have things like the Cloud9 IDE, as used on the Beagle boards, that could be used to compile on a server. I guess that could be adapted to use propgcc and do the loading. That might be a job for someone else though.
The issue I'm trying to fix here is that every time you hit the compile button a huge lot of memory was being leaked.
I found a solution that suggested wrapping the entire emscripten generated javascript in a function such that everything it creates in memory is destroyed when the function exits.
Having wrapped the compiler up like that it seems to run without leaks on my FireFox but still has the same problem in Chrome (On Debian).
It's also a bit slower because it recreates and tears down the entire run time of the compiler every time. Perhaps not to bad though.
If you have one try this link http://a.linuxsecured.net/openspin_web_demo2.html
Currently running under firefox the thing works in about 256MB of space and compiles the little demo in the blink of an eye. So we might be in with a chance on tablets.
P.S. That memory leak still seems to be there in FF but a lot less severe.
When I first pressed the "Compile" button it seemed that nothing was happening. I waited a minute or two and then pressed it again and got a response. I'm not sure if it really took that long or if I hadn't actually pressed the button the first time. In any case, it worked! If I press the compile button again I get a response almost immediately.