Ahh - I'd heard about this before. I believe it is Jan Jongboom's thing and I've chatted to him and seen him talk about it at a few events.
@DrAzzy people actually pay MBED very significant amounts of money every year to have their devices supported. I think it's one of those things that gets used in industry quite a bit.
easiness of development C++ <--> Javascript
I believe you still have to wrap your C code in boxing/unboxing code, and I think with mbedOS they use an offline build system so arguably it's probably easier to add an extension to Espruino right now :)
Support on wide range of ARM platforms
They definitely have that one nailed. But just because it's JS on a microcontroller don't expect a similar ease of use to Espruino. To develop useful non-blinky lights with it I believe you'll need to be a C++ developer and a JS developer.
ARM does have a much heavier marketing force than Espruino community.
Yes. And a huge amount of the boards that work with mbed are manufacturer-subsidised too so will be cheaper. Not to mention that folks like ARM, Intel and Samsung have people working full-time on JerryScript I believe.
RAM usage seems to be slightly heavier than Espruino
Have you used it? I think the overhead is huge - 64kB is for a very basic interpreter but as I understand it, pulling in more of the JS APIs uses more RAM. Espruino's had a lot of work in it to avoid doing that.
Having said that, this is obviously less of an issue as larger microcontrollers get cheaper - but for example it's unlikely to run on Puck.js, because while it has 64k of RAM the bluetooth stack takes a bunch of that.
So my additional pros and cons would be:
mbed pro:
Faster JS interpreter than Espruino
JS interpreter is more JS compliant
Lots of developers working on it at the moment
mbed cons:
No 'plug and play' boards in any useful sense.
Very little documentation/tutorials
Will never be available for non-ARM platforms
Very little ES6 support. Espruino doesn't have much but at least there's template strings, arrow functions, etc.
Command-line interface just a hack - realistically it's write JS -> compile -> upload -> run
No debugging
Not too many JS APIs exposed. mbed can do HTTP/etc, but I don't believe those functions are exposed to JS yet in an easy, well-documented way.
Flash usage is far heavier than Espruino's
Pretty sure there's no support for saving JS state, like can be done with Espruino's save()
I don't believe memory fragmentation issues have been addressed in JerryScript
You might think the situation doesn't look great, but after talking to the mbed guys I'm reasonably optimistic.
JerryScript on mbed OS (like mbed OS itself) is pushing heavily for corporate use where someone wants to add JavaScript to a large C/C++ codebase. This has never really been somewhere I've been interested in going with Espruino, since I'd basically just end up turning into a consultancy.
Espruino's really about the ease of use, and being able to develop with just the microcontroller you're running code on. My hope is that ARM's advertising will add real legitimacy to JS on microcontrollers, and that those who want a simple 'just works' solution will end up going with Espruino.
I think in the long term it could end up being a good thing - much like how Tessel actually really helped to get people talking about Espruino, and despite sort of being competitors I think we both got more users because of it.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Ahh - I'd heard about this before. I believe it is Jan Jongboom's thing and I've chatted to him and seen him talk about it at a few events.
@DrAzzy people actually pay MBED very significant amounts of money every year to have their devices supported. I think it's one of those things that gets used in industry quite a bit.
I believe you still have to wrap your C code in boxing/unboxing code, and I think with mbedOS they use an offline build system so arguably it's probably easier to add an extension to Espruino right now :)
They definitely have that one nailed. But just because it's JS on a microcontroller don't expect a similar ease of use to Espruino. To develop useful non-blinky lights with it I believe you'll need to be a C++ developer and a JS developer.
Yes. And a huge amount of the boards that work with mbed are manufacturer-subsidised too so will be cheaper. Not to mention that folks like ARM, Intel and Samsung have people working full-time on JerryScript I believe.
Have you used it? I think the overhead is huge - 64kB is for a very basic interpreter but as I understand it, pulling in more of the JS APIs uses more RAM. Espruino's had a lot of work in it to avoid doing that.
Having said that, this is obviously less of an issue as larger microcontrollers get cheaper - but for example it's unlikely to run on Puck.js, because while it has 64k of RAM the bluetooth stack takes a bunch of that.
So my additional pros and cons would be:
mbed pro:
mbed cons:
save()
You might think the situation doesn't look great, but after talking to the mbed guys I'm reasonably optimistic.
JerryScript on mbed OS (like mbed OS itself) is pushing heavily for corporate use where someone wants to add JavaScript to a large C/C++ codebase. This has never really been somewhere I've been interested in going with Espruino, since I'd basically just end up turning into a consultancy.
Espruino's really about the ease of use, and being able to develop with just the microcontroller you're running code on. My hope is that ARM's advertising will add real legitimacy to JS on microcontrollers, and that those who want a simple 'just works' solution will end up going with Espruino.
I think in the long term it could end up being a good thing - much like how Tessel actually really helped to get people talking about Espruino, and despite sort of being competitors I think we both got more users because of it.