Espruino -- a JavaScript Arduino(kickstarter.com)
kickstarter.com
Espruino -- a JavaScript Arduino
http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things?ref=live
8 comments
Hi, I'm the guy behind it... Just wanted to stand up for it a bit - the -uino postfix is really because of the hobby electronics association. I wanted to do something a bit different by adding the prototype area, and I found the Arduino form factor was too big for any sensible hand-held projects. The board is still small enough that it can sit on a simple adaptor PCB for Arduino shields though. I'll try and put one online when the campaign ends.
Also port initialisation is automatic so pinMode is not required - it's a huge potential gotcha for learners, and it seemed wise to remove the need for it. You can still use it if you want to though.
Also port initialisation is automatic so pinMode is not required - it's a huge potential gotcha for learners, and it seemed wise to remove the need for it. You can still use it if you want to though.
The "-uino" suffix is pretty blatantly associated with the arduino platform. To go out there and claim you're using it for the "hobby electronics association" is pretty disingenuous.
Agreed, and it's worth pointing out that this is what Arduino has to say on the matter:
"Note that while we don't attempt to restrict uses of the "duino" suffix, its use causes the Italians on the team to cringe (apparently it sounds terrible); you might want to avoid it. (It's also trademarked by a Hungarian company.)"
http://arduino.cc/en/Main/FAQ
"Note that while we don't attempt to restrict uses of the "duino" suffix, its use causes the Italians on the team to cringe (apparently it sounds terrible); you might want to avoid it. (It's also trademarked by a Hungarian company.)"
http://arduino.cc/en/Main/FAQ
How does this compare to Tessel? http://technical.io/ Can you merge your efforts?
Good luck!
Good luck!
Thanks! As I understand it, Tessel uses a version of node.js (and probably Linux underneath) so it needs around 32mb of RAM (and quite a lot of Flash too).
I've worked pretty hard to get Espruino running in 8kb (with space for variables) so that it can run on a single cheap IC (without external RAM).
I think they probably serve quite different markets. I figure Tessel are aiming to provide more of an ecosystem? If I'm honest I think they've got a bit of a fight on their hands against Raspberry Pi/Beaglebone with node.js installed, so I'd guess they're going for some kind of added value.
On the other hand, Espruino's aiming more where the Arduino is. Low power, where you want to play with LEDs or automate a project you've made, and you want the instant gratification of using an interpreter.
I've worked pretty hard to get Espruino running in 8kb (with space for variables) so that it can run on a single cheap IC (without external RAM).
I think they probably serve quite different markets. I figure Tessel are aiming to provide more of an ecosystem? If I'm honest I think they've got a bit of a fight on their hands against Raspberry Pi/Beaglebone with node.js installed, so I'd guess they're going for some kind of added value.
On the other hand, Espruino's aiming more where the Arduino is. Low power, where you want to play with LEDs or automate a project you've made, and you want the instant gratification of using an interpreter.
While this looks really cool, I also agree that you should lose the -uino
Seems like the project started on Olimexino board, which has the Arduino layout, and that's where the name probably comes from. Why they didn't keep the layout is beyond me.
http://www.youtube.com/watch?v=WP2Wo2_RVgo
https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/
http://www.youtube.com/watch?v=WP2Wo2_RVgo
https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/
> Unfortunate that they used a name ending in 'uino' since this is in no way an Arduino and not compatible with Arduino in terms of code or pin out.
I agree with you about the name.
This pinout, however, is very different from the Arduino because this thing has a lot more pins than the Arduino has. And the pinout of the normal Arduino is really annoying, because there's a non-standard half-pin width gap between two of the headers on the Arduino.
But prefabricated Arduino shields are really popular and supporting them would be a really good idea.
I agree with you about the name.
This pinout, however, is very different from the Arduino because this thing has a lot more pins than the Arduino has. And the pinout of the normal Arduino is really annoying, because there's a non-standard half-pin width gap between two of the headers on the Arduino.
But prefabricated Arduino shields are really popular and supporting them would be a really good idea.
Is this really a good idea? Yes, JavaScript is popular but if you're running on a microcontroller and already short of resources, is it really worth it to spend a lot of your cycles interpreting JavaScript?
A lot of microcontroller code has some real time requirements. Even some of the simplest Arduino code out there. Even in beginner projects, it is rather common to do something like software debouncing for pushbuttons or multiplexing for led matrices, both of which require millisecond resolution timing precision. A garbage collector pause in the middle of it would ruin everything. And a noob wouldn't understand why.
Also, isn't JavaScript already running on the new ARM Cortex M3 -based Arduino board?
To say something positive, I think the Google Blockly visual programming language is a very good idea for something like this, especially if targeted at noobs and/or kids. If you're unfamiliar with it, the picture with the puzzle pieces tells it all. There are puzzle pieces of different shapes for different syntactic structures (you can see expression and statement pieces), and the colors of the pieces are different types (in the picture, green is a boolean, I think).
A lot of microcontroller code has some real time requirements. Even some of the simplest Arduino code out there. Even in beginner projects, it is rather common to do something like software debouncing for pushbuttons or multiplexing for led matrices, both of which require millisecond resolution timing precision. A garbage collector pause in the middle of it would ruin everything. And a noob wouldn't understand why.
Also, isn't JavaScript already running on the new ARM Cortex M3 -based Arduino board?
To say something positive, I think the Google Blockly visual programming language is a very good idea for something like this, especially if targeted at noobs and/or kids. If you're unfamiliar with it, the picture with the puzzle pieces tells it all. There are puzzle pieces of different shapes for different syntactic structures (you can see expression and statement pieces), and the colors of the pieces are different types (in the picture, green is a boolean, I think).
some of the JavaScript engines, most notably MicroSoft's JavaScript Engine, use reference counting for determining when memory can be freed.[1]. Some implementations of reference counting work well in hard real time systems[2].
So it's too early to tell if espruino would fit real time systems.
And regarding wasted cycles: for this project, it doesn't matter much. Unless you make stuff in volume ,micro controllers are cheap.
[1]http://www.fasterj.com/articles/javascript.shtml
[2]http://liu.diva-portal.org/smash/record.jsf?pid=diva2:20899
So it's too early to tell if espruino would fit real time systems.
And regarding wasted cycles: for this project, it doesn't matter much. Unless you make stuff in volume ,micro controllers are cheap.
[1]http://www.fasterj.com/articles/javascript.shtml
[2]http://liu.diva-portal.org/smash/record.jsf?pid=diva2:20899
Espruino does use reference counting, and currently falls back to proper Garbage Collection if available memory gets filled with cyclic datastructures.
Responding to IO is handled and timestamped using interrupts, so if you write your code such that you use the timestamp, you can actually do some very accurate timing.
One other good point is (strangely) power usage. As there's an interpreter, it can very easily detect when it isn't doing anything and can go into low power sleep modes - it's something that you can do with another MCU and a lot of effort, but that you get for free with Espruino.
There are things it's good for and things it isn't - but for the majority of projects people do with Arduino I think it really does provide value.
Responding to IO is handled and timestamped using interrupts, so if you write your code such that you use the timestamp, you can actually do some very accurate timing.
One other good point is (strangely) power usage. As there's an interpreter, it can very easily detect when it isn't doing anything and can go into low power sleep modes - it's something that you can do with another MCU and a lot of effort, but that you get for free with Espruino.
There are things it's good for and things it isn't - but for the majority of projects people do with Arduino I think it really does provide value.
> some of the JavaScript engines, most notably MicroSoft's JavaScript Engine, use reference counting for determining when memory can be freed.[1]
Interesting, I was unaware of this. How does Microsoft's JavaScript engine deal with cyclic data structures, which reference counting can't deal with? The best I understood from your link is that it just leaks cyclic structures? Does the JS spec really allow this?
> So it's too early to tell if espruino would fit real time systems.
It's too early to tell but IMO it's a critical aspect of microcontrollers. Many if not most microcontroller applications have some degree of real time requirements, which limits your choices for software runtime systems.
Interesting, I was unaware of this. How does Microsoft's JavaScript engine deal with cyclic data structures, which reference counting can't deal with? The best I understood from your link is that it just leaks cyclic structures? Does the JS spec really allow this?
> So it's too early to tell if espruino would fit real time systems.
It's too early to tell but IMO it's a critical aspect of microcontrollers. Many if not most microcontroller applications have some degree of real time requirements, which limits your choices for software runtime systems.
I don't know how MS does solve the cycle problem.
Many data structures don't have cycles. I believe it's pretty true for many embedded systems.
Many data structures don't have cycles. I believe it's pretty true for many embedded systems.
Most JavaScript runtimes no longer interpret JavaScript. It is compiled to bitcode and some subsets(see asm.js) can run within reach of native code.
> Most JavaScript runtimes no longer interpret JavaScript.
Yes, JavaScript implementations have been more or less JIT-compiler based for quite some time now. But they are still quite far behind in performance and this does not address the real time requirements at all (in fact, it makes it worse). There's also a significant memory hit from having the JIT compiler around.
Asm.js is cool because it can be compiled to native code ahead of time (addresses the performance gap at the expense of startup time), but this project isn't talking about Asm.js at all. It's about running human-written JavaScript as opposed to Asm.js which is intended to be emitted by compilers.
Yes, JavaScript implementations have been more or less JIT-compiler based for quite some time now. But they are still quite far behind in performance and this does not address the real time requirements at all (in fact, it makes it worse). There's also a significant memory hit from having the JIT compiler around.
Asm.js is cool because it can be compiled to native code ahead of time (addresses the performance gap at the expense of startup time), but this project isn't talking about Asm.js at all. It's about running human-written JavaScript as opposed to Asm.js which is intended to be emitted by compilers.
I would personally have preferred Lua via eLua or LuaJIT over Javascript.
And I don't know where he got his stat about "Most JavaScript runtimes no longer interpret JavaScript". And I don't see a single thing backing that up.
And I don't know where he got his stat about "Most JavaScript runtimes no longer interpret JavaScript". And I don't see a single thing backing that up.
This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast.
Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system.
Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms."
A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities.
Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure).
Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4].
[1] http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts [4]This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast.
Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system.
Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms."
A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities.
Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native code for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure).
Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4].
[1] http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts [4]https://code.google.com/p/tiny-js/
Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system.
Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms."
A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities.
Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure).
Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4].
[1] http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts [4]This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast.
Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system.
Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms."
A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities.
Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native code for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure).
Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4].
[1] http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts [4]https://code.google.com/p/tiny-js/
> This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast.
Yes, this is exactly why I mentioned real time and questioned the suitability of garbage collection for this use. Overall performance is a secondary issue, many use cases can work with slightly lower perf but in microcontrollers you want predicatable performance.
Yes, this is exactly why I mentioned real time and questioned the suitability of garbage collection for this use. Overall performance is a secondary issue, many use cases can work with slightly lower perf but in microcontrollers you want predicatable performance.
Maybe I'm missing something, but why does Javascript require new hardware? Can you not run whatever software this is running on another µC... say the one on an Arduino board? Obviously the drivers are different but you have to write them for this hardware anyway.
This should work on the larger Arduino boards (the Due and 2560) and it already works on a bunch of other hardware too.
To be honest the new board is just to do something a bit different - and to give backers of the KickStarter something fun that they couldn't just go out and buy.
To be honest the new board is just to do something a bit different - and to give backers of the KickStarter something fun that they couldn't just go out and buy.
I think this is a little bit off. What I want is an embedded device that runs node.js and npm, not just JavaScript. That enables you to use JavaScript and C (using a native npm module) and get the best of both worlds.
There's Beaglebone, Raspberry Pi, and also now Tessel that do that. The previous two have had node.js support for ages but I think have been lacking any kind of real advertising because they're more general purpose.
All of those appear to be fully-fledged computers though, and Espruino's not really aiming to compete with them.
Instead, you get to use JavaScript on a very small, low-power microcontroller than will sensibly run off a small battery for days on end.
Some people will want one thing, some will want another - and hopefully they can both coexist. If we get it right they'll both help each other and we can end up with a large library of JavaScript code for embedded devices :)
All of those appear to be fully-fledged computers though, and Espruino's not really aiming to compete with them.
Instead, you get to use JavaScript on a very small, low-power microcontroller than will sensibly run off a small battery for days on end.
Some people will want one thing, some will want another - and hopefully they can both coexist. If we get it right they'll both help each other and we can end up with a large library of JavaScript code for embedded devices :)
>> sensibly run off a small battery for days on end.
Could you please offer more details? what kind of application, what kind of battery and estimated power consumption ?
Could you please offer more details? what kind of application, what kind of battery and estimated power consumption ?
Quick back of the envelope calculation shows about two days (~50 hours) on 2xAA alkaline batteries when running the micro-controller on full power (~50mA current consumption according to the datasheet).
Of course aggressive power management (ie putting the mcu to sleep) could significantly extend the battery life. According to the datasheet the current consumption at sleep can be as low as 0.5mA, full two orders of magnitude difference. The standby current is in microampere range.
In comparison BBB consumes "210-460mA @5V", which would correspond to 1-3 hours on 2xAA alkalines (assuming ideal voltage converter).
Of course aggressive power management (ie putting the mcu to sleep) could significantly extend the battery life. According to the datasheet the current consumption at sleep can be as low as 0.5mA, full two orders of magnitude difference. The standby current is in microampere range.
In comparison BBB consumes "210-460mA @5V", which would correspond to 1-3 hours on 2xAA alkalines (assuming ideal voltage converter).
Sorry for the late reply....
At the moment I've got the KickStarter board down to 4mA when idle (as it can sleep) - when executing code I think it's around 40mA. Hopefully by release time I'll have sorted out a few glitches and got it down to under 1mA idle (in the range zokier noted).
Note that with something like 'setInterval(doStuff, 1000)' the processor will be idle for 99% of the time.
Running off a li-ion battery from an old Nokia phone (700mAh) you could then expect Espruino to run for almost a month. Using the battery out of my Galaxy S3 (2100mAh) it'd run for almost 3 months.
At the moment I've got the KickStarter board down to 4mA when idle (as it can sleep) - when executing code I think it's around 40mA. Hopefully by release time I'll have sorted out a few glitches and got it down to under 1mA idle (in the range zokier noted).
Note that with something like 'setInterval(doStuff, 1000)' the processor will be idle for 99% of the time.
Running off a li-ion battery from an old Nokia phone (700mAh) you could then expect Espruino to run for almost a month. Using the battery out of my Galaxy S3 (2100mAh) it'd run for almost 3 months.
I think Beaglebone Black already does that. Please correct me if I'm wrong? Also, it has an embedded micro-controller inside making it a fantastic piece of hardware.
Perhaps you're looking for something like this? http://technical.io/
[deleted]
Ecmaboard, or CallbackCard would've been more fitting.
Maybe $Board.
Maybe $Board.
How is this any different from running Johnny-Five (https://github.com/rwaldron/johnny-five) on an Arduino? Do we really need a board dedicated to JavaScript? There are SO many Arduino compatible boards out there already...
Johnny-Five requires a PC (it runs JavaScript on the host computer). On Espruino you can program it, then unplug the PC and it keeps working.
One of the big benefits (apart from running on its own) is that you don't have the latency of USB, so can respond to things far more quickly.
One of the big benefits (apart from running on its own) is that you don't have the latency of USB, so can respond to things far more quickly.
You're right, I had completely forgotten about that part. Currently Node.js can be used to control an Arduino, but it cannot run on it directly (like it can on a Raspberry Pi).
Should've called it Ecmuino.
Pledged to get a board. Looks like it would be fun to play with.
Also, I think their code examples are disingenuous: their Arduino code could be greatly simplified. (e.g. why does the JavaScript code not include any port initialization but the Arduino code does; why have two digitalWrites in the Arduino code, but one in the JavaScript)?