Do not worry, at this point there is no need for you, or anyone, to make an investment. (Investing in the wife is probably a much better idea:))
Thing is: Gordon Williams has created a great little JS system for small embedded ARM systems. Only problem (for us) is that he did not publish it as open source.
Gordon has put together the Espruino board design to run that JS with the promise that if he got enough pledges to build a good quantity of boards running Espruino he would open source all the software.
If you like, he was holding the source code to ransom in the hope of making a little money out of it. Which sounds fair to me. A little return for his efforts is in order if it's good and useful stuff.
Anyway, he has his original 20K in pledges so we can be expecting the JS interpreter and all to be released. If not there will be a lot of angry people burning his house down:)
For my part, I hope I can make some progress towards getting that Espruino code running on the PII at some point.
I'm talking to myself here but the Espruino project has just hit £63000 worth of pledges.
1300 lunatics really want JS on embedded systems and the Prop (II) should have it to.
Nope, I'll second that you're not talking to yourself. Not at all. I'm very interested in Espurino (and related projects).
I'm talking to myself here but the Espruino project has just hit £63000 worth of pledges.
1300 lunatics really want JS on embedded systems and the Prop (II) should have it to.
Are you one of the lunatics? :-)
I'm thinking of joining the crowd.
Edit: I did it! I joined! In fact, I'm a super lunatic because I pledged at the level that gets me TWO boards and some wireless stuff.
Darn you guys! I just went back and revisited the Kickstarter project, read the details, looked over the the pictures....I felt like when I was a kid with a catalog from a hobby shop. Let's see, 38 pounds converts to....oh, wow! That's not as much as I thought it was going to be.....5 more days to pulls the trigger then 4 months of waiting and brushing up on my Javascript.......
Didn't you get the current Espurino software running on P1 using PropGCC? What is involved with getting it running on P2 other than recompiling with -mp2? Is there assembly code that has to be rewritten?
Didn't you get the current Espurino software running on P1 using PropGCC?
Not exactly. The Espruino code is not open sourced. Gordon Williams has promised to open source it when the Kickstarter project is off the ground.
What I got running on the Prop was tiny-js also by Gordon which he did release as open source a while back. tiny-js seems to be some original version of the Espruino idea. It lacks any hardware interfacing and so on.
There was no assmbler code in there. Just regular C++. Should compile for the P2 just fine.
Not exactly. The Espruino code is not open sourced. Gordon Williams has promised to open source it when the Kickstarter project is off the ground.
What I got running on the Prop was tiny-js also by Gordon which he did release as open source a while back. tiny-js seems to be some original version of the Espruino idea. It lacks any hardware interfacing and so on.
There was no assmbler code in there. Just regular C++. Should compile for the P2 just fine.
The Espruino "JavaScript for things" Kickstarter project just made it to 80000 dollars worth of pledges. That's four times the original goal! And one and a half thousand backers.
It's amazing that there is such a big interest in JS on an MCU out there any seemingly not much in here.
Sorry to go on about it. I promise to try and keep quite about it until we can get the source and start to try making JS for the Prop II:)
Be sure I'm watching my mail every minute today. There is will be a github fork of it for Propeller porting as soon as it emerges:)
Can't wait to see what is in there. I just hope it's understandable and manageable.
What is that the "PropellerduinoDuo Do" or something?
However I don't think it's any more of a pain than the weird stuff that goes on in languages like C or even Spin. Did you know you can add one to a value which is already the maximum size of a 32 bit signed integer and the compiler will not tell you? Worse still at run time it obediently does that producing a totally wrong result. How crazy is that?
Totaly wrong resault? Last time I checked in modulo 4294967296 arathmitic if you add 1 to 0xFFFFFFFF it equals 0. And since computers deal with modulo 2^n arithmatic, and a 32 bit integer gives 2^32 = 4294967296, that would be done in modulo 4294967296 arithmatic. I often take advantage of this fact to cause intentional wrap arounds.
.
Or do you get something other than 0? If so I would like to know how.
There will be JavaScript on the Propeller II.
That could deffinitely bring more Propeller 2 users.
.
The one problem that I have with current Java Script is that it is not implemented in a consistant way acrossed platforms. This is slowly being resolved, though it will take some time.
.
Unfortunately many of the Java Script implementations are dog slow, this is no fault of Java Script, it is the fault of the implementation. The implementations used in Mozilla, WebKit, Opera, and IE are some of the worste when it comes to speed, and stability, and this gives the language a bad name, because these are the most popular Web Browsers.
.
I am glad to see this progress with the implementation of Java Script on MicroControlers. This may lead to enough effecient implementations to get the coders of the verious Web Browsers to actualy take the time to optimize what they implement. Some times I think that a Faster implementation of Java Script could be done in BBC BASIC than the Web Browsers currently use.
Hope you don't mind but I have to counter pretty much every statement above:)
Totaly wrong resault?
Yes.
Well, I was being a bit tongue in cheek there. Of course adding one to an integer in a modern language is going to roll over from maximum value and give you something that is not "maximum + 1" in normal arithmetic. We all know about that. From the point of view of "normal" people this is nuts, that is why in Python it does not happen, numbers just get bigger and bigger.
We are talking here in the context of JavaScript which is a language with no type checking, where "0.2 + 0.1" is not "0.3" and many other quirks. People often complain about languages like this because there is no compile time checking and errors just silently happen.
I was simply pointing out that languages like C and Pascal have similar situations where incorrect results are produced silently. Yes these are bugs in my code but using a compiled language with loads of checking for everything does not protect me from such mistakes.
Or do you get something other than 0? If so I would like to know how.
Yes I do.
Firstly I said "signed integer". If you add one to the maximum value of a signed integer you get the minimum value. e.g. For 32 bit integers that is 2147483647 + 1 becomes -2147483648.
See how easy it is for these bugs to creep in:)
The one problem that I have with current Java Script is that it is not implemented in a consistant way acrossed platforms.
Actually JavaScript, the actual language, is implemented very consistently accross platforms. When Microsoft implemented JS in IE they did a very good job of reverse engineering all the quirks and bugs of the orginal Nestscape JS. And all thoses "errors" ended up in the ECMA standard!
What I think you mean is the platforms are inconsistent, the browsers, their DOMs and their API's. This is not the fault of the JavaScript language implementations.
Unfortunately many of the Java Script implementations are dog slow,
This is no longer true in browsers and run times that normal people use now a days. In recent years the JS engines in FireFox and Chrome have become amazingly fast. Did you know that you can "compile" C code to JavaScript which then runs in FireFox at a quater the speed of native code! The V8 JS engine in Google Chrome is very good.
On servers I use node.js which uses Googles V8 engine. I have server processes in JS that are about as performant as the C++ equivalents.
BUT JS will be slow on micro-controllers. There just isn't enough room in there to do all the run-time optimization that a browser engine can do.
OOPS: It is released under the Mozilla Public license
What is the problem with that?
And we are off with Java Script soon to be on the Propeller.
I hope so. I don't have a lot of time to look at that but I'm starting now.
Yes I do.Firstly I said "signed integer". If you add one to the maximum value of a signed integer you get the minimum value. e.g. For 32 bit integers that is 2147483647 + 1 becomes -2147483648.
What I think you mean is the platforms are inconsistent, the browsers, their DOMs and their API's. This is not the fault of the JavaScript language implementations.
Yes that is what I mean. And I know that this has nothing to do with Java Script itself.
his is no longer true in browsers and run times that normal people use now a days. In recent years the JS engines in FireFox and Chrome have become amazingly fast. Did you know that you can "compile" C code to JavaScript which then runs in FireFox at a quater the speed of native code! The V8 JS engine in Google Chrome is very good.
I am going to have to dissagree on that one, as I use FireFox on my PC running Linux, it is a 2.4GHz Intel Core2 Duo, and Java Script applications in FireFox run slower than Native applications on my Raspberry Pi runing RISC OS, and some slower than BBC BASIC interpreted on my Raspberry Pi. That is deffinitely more than a 4x slow down from well optimized compiled C. I guess there are probably some things that could run that fast just not most.
Hi
As soon as I saw 'Java' in the title I ignored this item, but in the end curiosity won out and I'm glad it did, because this is very interesting, despite my dislike of all things 'C-like'.
I've been making quite a bit of use or the arduino, and having worked through the pain barrier of the 'C' syntax etc I've interfaced a lot of stuff and find the whole 'arduino experience' quite palatable.
I suppose its the simplicity of writing code - uploading - running - debugging without leaving the one screen and no make this, sudo that etc etc.
When the raspberry pi came on the scene I hoped I could use that in a similar way, but it seems it was designed to run under linux and despite the bare metal enthusiasts doing their best, I find it... awkward.
Now this.
I've looked at the web site and I like what I see and for £20 ish looks worth a shot.
Then it occurred to me it would be nice if the Pi could be used in this way; without linux but with its graphical ability, I could happily use it for all sorts of things. But I suspect it's the use of the Pi's graphics and getting a graphics library would be a problem.
But with the prop2 and its graphics I think I could get quite excited!
I managed to get Espruino to compile with propgcc!
No idea if it works but my changes to the Makefile and platform files are up on github if anyone wants to play with it. https://github.com/ZiCog/Espruino
The resulting elf is 280KBytes. Time to dig out that Gadget Ganster SDRAM card.
I wondering why the .bin file it produces is 3.2 Giga Bytes !!
I managed to get Espruino to compile with propgcc!
No idea if it works but my changes to the Makefile and platform files are up on github if anyone wants to play with it. https://github.com/ZiCog/Espruino
The resulting elf is 280KBytes. Time to dig out that Gadget Ganster SDRAM card.
I wondering why the .bin file it produces is 3.2 Giga Bytes !!
Okay, I guess the problem with the .bin file is that it contains an image starting at 0x00000000 to the highest address used by the program. If you use xmm-single that will include code and data starting at 0x20000000 and if you use xmm or xmm-split (synonyms) there will be data at 0x20000000 and code at 0x30000000. This can result in very large .bin files although 3.1gb seems too big. Send me the .elf file and I'll see if I can figure out why the .bin file ended up so large.
Edit: Actually, I know why the files are so big. We also put the XMM kernel at 0xe0000000 but propeller-load handles that separately. It is never loaded into external memory.
bash scripts/check_size.sh espruino_propeller.bin
FAIL - size of 3221226940 is over 15360 bytes
make: *** [espruino_propeller.elf] Error 1
That last step "check_size.sh" blew my mind!
The "15360 bytes" is a FLASH size put in an auto generated header somehow and scheck_size just comapres the size of the bin file to that.
bash scripts/check_size.sh espruino_propeller.bin
FAIL - size of 3221226940 is over 15360 bytes
make: *** [espruino_propeller.elf] Error 1
That last step "check_size.sh" blew my mind!
The "15360 bytes" is a FLASH size put in an auto generated header somehow and scheck_size just comapres the size of the bin file to that.
It's big because of the XMM memory map. It doesn't really reflect the size of the actual file that will be loaded into external memory on the Propeller. To get that you'll have to look at the load map and check the size of the data that starts at 0x30000000 if you're using either xmmc or xmm-split and 0x20000000 if you're using xmm-single.
Comments
Nice to hear there is some interest.
Do not worry, at this point there is no need for you, or anyone, to make an investment. (Investing in the wife is probably a much better idea:))
Thing is: Gordon Williams has created a great little JS system for small embedded ARM systems. Only problem (for us) is that he did not publish it as open source.
Gordon has put together the Espruino board design to run that JS with the promise that if he got enough pledges to build a good quantity of boards running Espruino he would open source all the software.
If you like, he was holding the source code to ransom in the hope of making a little money out of it. Which sounds fair to me. A little return for his efforts is in order if it's good and useful stuff.
Anyway, he has his original 20K in pledges so we can be expecting the JS interpreter and all to be released. If not there will be a lot of angry people burning his house down:)
For my part, I hope I can make some progress towards getting that Espruino code running on the PII at some point.
Espruino has nearly hit seventy grand!
Crazy stuff.
I'm thinking of joining the crowd.
Edit: I did it! I joined! In fact, I'm a super lunatic because I pledged at the level that gets me TWO boards and some wireless stuff.
Darn you guys!!
Completely loony toons. I was just contemplating upgrading to the WIFI kit.
mindrobots,
Whilst you are waiting, you could install node.js on a PC and get on with the JS study.
http://nodejs.org/
Alternatively download the current Espruino software from here http://www.espruino.com/Download and invest in a cheap ARM board to run it. Boards are listed here: http://www.espruino.com/Other+Boards
Not exactly. The Espruino code is not open sourced. Gordon Williams has promised to open source it when the Kickstarter project is off the ground.
What I got running on the Prop was tiny-js also by Gordon which he did release as open source a while back. tiny-js seems to be some original version of the Espruino idea. It lacks any hardware interfacing and so on.
There was no assmbler code in there. Just regular C++. Should compile for the P2 just fine.
I forked the tiny-js code on github https://github.com/ZiCog/tiny-js-propeller if you want to play with it. I think Jazzed also forked a copy some place.
It's amazing that there is such a big interest in JS on an MCU out there any seemingly not much in here.
Sorry to go on about it. I promise to try and keep quite about it until we can get the source and start to try making JS for the Prop II:)
Who would have guessed this crazy idea would attract such interest?
Atwood's Law states that: "Any application that can be written in JavaScript, will eventually be written in JavaScript."
The Espruino seems to be demonstrating that Atwood's law may even apply to embedded systems. That and Google Coder for the Raspberry Pi.
http://http://www.codinghorror.com/blog/2009/08/all-programming-is-web-programming.html
http://googlecreativelab.github.io/coder/
Be sure I'm watching my mail every minute today. There is will be a github fork of it for Propeller porting as soon as it emerges:)
Can't wait to see what is in there. I just hope it's understandable and manageable.
What is that the "PropellerduinoDuo Do" or something?
https://github.com/espruino
My fork is already here:
https://github.com/ZiCog/Espruino
Gentlemen, start you compilers.
Hope you don't mind but I have to counter pretty much every statement above:) Yes.
Well, I was being a bit tongue in cheek there. Of course adding one to an integer in a modern language is going to roll over from maximum value and give you something that is not "maximum + 1" in normal arithmetic. We all know about that. From the point of view of "normal" people this is nuts, that is why in Python it does not happen, numbers just get bigger and bigger.
We are talking here in the context of JavaScript which is a language with no type checking, where "0.2 + 0.1" is not "0.3" and many other quirks. People often complain about languages like this because there is no compile time checking and errors just silently happen.
I was simply pointing out that languages like C and Pascal have similar situations where incorrect results are produced silently. Yes these are bugs in my code but using a compiled language with loads of checking for everything does not protect me from such mistakes.
Yes I do.
Firstly I said "signed integer". If you add one to the maximum value of a signed integer you get the minimum value. e.g. For 32 bit integers that is 2147483647 + 1 becomes -2147483648.
See how easy it is for these bugs to creep in:)
Actually JavaScript, the actual language, is implemented very consistently accross platforms. When Microsoft implemented JS in IE they did a very good job of reverse engineering all the quirks and bugs of the orginal Nestscape JS. And all thoses "errors" ended up in the ECMA standard!
What I think you mean is the platforms are inconsistent, the browsers, their DOMs and their API's. This is not the fault of the JavaScript language implementations.
This is no longer true in browsers and run times that normal people use now a days. In recent years the JS engines in FireFox and Chrome have become amazingly fast. Did you know that you can "compile" C code to JavaScript which then runs in FireFox at a quater the speed of native code! The V8 JS engine in Google Chrome is very good.
On servers I use node.js which uses Googles V8 engine. I have server processes in JS that are about as performant as the C++ equivalents.
BUT JS will be slow on micro-controllers. There just isn't enough room in there to do all the run-time optimization that a browser engine can do. What is the problem with that? I hope so. I don't have a lot of time to look at that but I'm starting now.
_____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |_____|___| _|_| |___|_|_|_|___| |_| http://www.espruino.com 1v40 Copyright 2013 Gordon Williams ------------------------------------------- KickStarter Version ------------------------------------------- >var a = 1 =1 >var b = 2 =2 >a + b =3 >setInterval (function () {console.log('Hi')}, 1000); =0 Hi Hi Hi Hi HiAt least it builds on Linux with just "make". (Had to "mkdir gen" first though).
As soon as I saw 'Java' in the title I ignored this item, but in the end curiosity won out and I'm glad it did, because this is very interesting, despite my dislike of all things 'C-like'.
I've been making quite a bit of use or the arduino, and having worked through the pain barrier of the 'C' syntax etc I've interfaced a lot of stuff and find the whole 'arduino experience' quite palatable.
I suppose its the simplicity of writing code - uploading - running - debugging without leaving the one screen and no make this, sudo that etc etc.
When the raspberry pi came on the scene I hoped I could use that in a similar way, but it seems it was designed to run under linux and despite the bare metal enthusiasts doing their best, I find it... awkward.
Now this.
I've looked at the web site and I like what I see and for £20 ish looks worth a shot.
Then it occurred to me it would be nice if the Pi could be used in this way; without linux but with its graphical ability, I could happily use it for all sorts of things. But I suspect it's the use of the Pi's graphics and getting a graphics library would be a problem.
But with the prop2 and its graphics I think I could get quite excited!
(mm I MUST get around to trying RISC OS on my Pi)
Dave H
No idea if it works but my changes to the Makefile and platform files are up on github if anyone wants to play with it. https://github.com/ZiCog/Espruino
The resulting elf is 280KBytes. Time to dig out that Gadget Ganster SDRAM card.
I wondering why the .bin file it produces is 3.2 Giga Bytes !!
The Makefile winds up by building a full gamut of output files like so:
$(PROJ_NAME).elf: $(OBJS)$(LD) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
$(OBJDUMP) -x -S $(PROJ_NAME).elf > $(PROJ_NAME).lst
$(OBJCOPY) -O ihex $(PROJ_NAME).elf $(PROJ_NAME).hex
$(OBJCOPY) -O srec $(PROJ_NAME).elf $(PROJ_NAME).srec
$(OBJCOPY) -O binary $(PROJ_NAME).elf $(PROJ_NAME).bin
bash scripts/check_size.sh $(PROJ_NAME).bin
Edit: Actually, I know why the files are so big. We also put the XMM kernel at 0xe0000000 but propeller-load handles that separately. It is never loaded into external memory.
The Makefile winds up by building a full gamut of output files like so:
/opt/parallax/bin/propeller-elf-gcc -mxmm-single -Wl,--gc-sections -o espruino_propeller.elf src/jslex.o src/jsvar.o src/jsutils.o src/jsparse.o src/jsinteractive.o src/jsdevices.o gen/jswrapper.o libs/math/acosh.o libs/math/asin.o libs/math/asinh.o libs/math/atan.o libs/math/atanh.o libs/math/cbrt.o libs/math/chbevl.o libs/math/clog.o libs/math/cmplx.o libs/math/const.o libs/math/cosh.o libs/math/drand.o libs/math/exp10.o libs/math/exp2.o libs/math/exp.o libs/math/fabs.o libs/math/floor.o libs/math/isnan.o libs/math/log10.o libs/math/log2.o libs/math/log.o libs/math/mtherr.o libs/math/polevl.o libs/math/pow.o libs/math/powi.o libs/math/round.o libs/math/setprec.o libs/math/sin.o libs/math/sincos.o libs/math/sindg.o libs/math/sinh.o libs/math/sqrt.o libs/math/tan.o libs/math/tandg.o libs/math/tanh.o libs/math/unity.o targets/propeller/main.o targets/propeller/jshardware.o src/jswrap_pin.o src/jswrap_functions.o src/jswrap_modules.o src/jswrap_interactive.o src/jswrap_json.o src/jswrap_object.o src/jswrap_string.o src/jswrap_array.o src/jswrap_arraybuffer.o src/jswrap_serial.o src/jswrap_spi_i2c.o src/jswrap_onewire.o src/jswrap_io.o libs/jswrap_math.o -lm
/opt/parallax/bin/propeller-elf-objdump -x -S espruino_propeller.elf > espruino_propeller.lst
/opt/parallax/bin/propeller-elf-objcopy -O ihex espruino_propeller.elf espruino_propeller.hex
/opt/parallax/bin/propeller-elf-objcopy -O srec espruino_propeller.elf espruino_propeller.srec
/opt/parallax/bin/propeller-elf-objcopy -O binary espruino_propeller.elf espruino_propeller.bin
bash scripts/check_size.sh espruino_propeller.bin
FAIL - size of 3221226940 is over 15360 bytes
make: *** [espruino_propeller.elf] Error 1
That last step "check_size.sh" blew my mind!
The "15360 bytes" is a FLASH size put in an auto generated header somehow and scheck_size just comapres the size of the bin file to that.
Anyway here is the elf file.
Don't bother trying to load it anywhere it has no console I/O at the moment.
You mean this in the .lst file:
LOAD off 0x00000134 vaddr 0x20000000 paddr 0x20000000 align 2**2
filesz 0x00070780 memsz 0x00070780 flags rwx
Looks like 460KBytes to me.