JerryScript – A JavaScript Engine for Internet of Things(samsung.github.io)
samsung.github.io
JerryScript – A JavaScript Engine for Internet of Things
http://samsung.github.io/jerryscript/
73 comments
One more:
https://cesanta.com/smartjs.shtml
Opinion: Lua is a better choice for IoT but alas the programming "market" has (again) chosen the worse alternative.
Opinion: Lua is a better choice for IoT but alas the programming "market" has (again) chosen the worse alternative.
Lua has a significant strike against it in being 1-based when everything embedded you'd want to put Lua on is 0-based.
In addition, the point of having Javascript is so that I can get my junior software folks (proxy for any inexperienced programmer) to write things for my embedded hardware instead of having to haul out my senior staff engineers who have 20 years of experience writing C for embedded devices.
Look at Arduino vs. Raspberry Pi/BeagleBone. Arduino has way more developers because it was orders of magnitude easier to program. Ecosystem is important.
In addition, the point of having Javascript is so that I can get my junior software folks (proxy for any inexperienced programmer) to write things for my embedded hardware instead of having to haul out my senior staff engineers who have 20 years of experience writing C for embedded devices.
Look at Arduino vs. Raspberry Pi/BeagleBone. Arduino has way more developers because it was orders of magnitude easier to program. Ecosystem is important.
>Lua has a significant strike against it in being 1-based when everything embedded you'd want to put Lua on is 0-based.
Why is being 0-based more important on embedded compared to other contexts?
Why is being 0-based more important on embedded compared to other contexts?
[deleted]
Don't forget Picobit which is Scheme:
https://github.com/stamourv/picobit
I was listing Javascript interpreters with a small resource footprint; how does Picobit fit in?
Coming soon: GeorgeScript, a little language that compiles into JerryScript.
Everybody knows: you have got to keep your worlds apart!
You have slipped up.
You have slipped up.
I'm struggling to understand - what's the point of using JavaScript for anything embedded?
Because 'scripting' hardware (coding in a fairly high-level language) is a lot of fun and coding the same sorts of things in C is pretty painful & requires up-front knowledge of a lot of stuff you don't really need to know til later (memory management, types etc).
Sure there's Lua et al but JS is just a more relevant language nowadays.
Sure there's Lua et al but JS is just a more relevant language nowadays.
> coding in a fairly high-level language
JavaScript is not that high-level anyway, and there are many high-level languages that are much more embedded- and realtime-friendly. Why choosing JavaScript over the much more suitable ones?
JavaScript is not that high-level anyway, and there are many high-level languages that are much more embedded- and realtime-friendly. Why choosing JavaScript over the much more suitable ones?
Because people know it. That's the only reason, but it's a huge reason.
...though I'm not sure what languages you think are more high-level that are not thereby made somewhat more difficult to use by beginners and/or on small projects, which would rather defeat the purpose, since the actual code running on these cheap microcontrollers is usually relatively small.
...though I'm not sure what languages you think are more high-level that are not thereby made somewhat more difficult to use by beginners and/or on small projects, which would rather defeat the purpose, since the actual code running on these cheap microcontrollers is usually relatively small.
> That's the only reason, but it's a huge reason.
Kinda stupid reason.
> more high-level that are not thereby made somewhat more difficult
Usually, the higher the level of the language, the easier it is to use. I would never call JS an easy language.
Kinda stupid reason.
> more high-level that are not thereby made somewhat more difficult
Usually, the higher the level of the language, the easier it is to use. I would never call JS an easy language.
JavaScript is weird and stupid to begin with. Until it becomes the most widely used, fastest dynamically typed language.
Won't ever be "fastest" in embedded, no way you can run your v8 on such devices.
> Won't ever be "fastest" in embedded, no way you can run your v8 on such devices.
V8 won't always be required for fast Javascript. If Web Assembly[1] pans out as planned, I can foresee embedded devices that can execute wasm code natively (or at least fast)
1. https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
V8 won't always be required for fast Javascript. If Web Assembly[1] pans out as planned, I can foresee embedded devices that can execute wasm code natively (or at least fast)
1. https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
Web assembly, as well as asm.js, is never meant to be manually written. It's a target for compilers. And even the most efficient ever implementation of web assembly won't make your plain old javascript any faster.
Examples? I gave a hat-tip to Lua and suggested why JS wins in this case (same argument for langs like Nim). Ruby and Python are too slow (currently). Go and Rust are fast but relatively low-level, tough-going for newbies.
Both Lua and JS are dynamically typed, which is not a very good idea for the low power, limited resources devices. There is a number of relatively high level, statically typed, compilable languages: Ada, Oberon, even the good old Pascal would be ok for the beginners. Not ideal, but at least much better than JS.
In practice with Lua, being dynamically typed isn't really the metric we're concerned about for power consumption. Typically Lua is used as a scripting interface to native APIs and hardware (via C). This is where most of your power consumption is going to live. Powering up a wi-fi antenna? That's going to cost way more than anything you can measure in Lua. Writing a video game? Your GPU is consuming most of the power.
And Lua has proven itself in limited/constrained resource environments for over 20 years. In practice, it is really good in this space.
And a further interesting point about Lua somebody pointed out to me...now that most modern architectures are cache oriented and memory buses are often the bottleneck, it is amazing that Lua is small enough to fit in the L2 cache. Think about this...it is almost like having Lua in hardware on the chip.
Note: Canonical PUC-Rio Lua does not have JIT. You aren't burning all the cycles you think you are if you are applying typical arguments about the JVM or JavaScript JITs.
Edit: typo
And Lua has proven itself in limited/constrained resource environments for over 20 years. In practice, it is really good in this space.
And a further interesting point about Lua somebody pointed out to me...now that most modern architectures are cache oriented and memory buses are often the bottleneck, it is amazing that Lua is small enough to fit in the L2 cache. Think about this...it is almost like having Lua in hardware on the chip.
Note: Canonical PUC-Rio Lua does not have JIT. You aren't burning all the cycles you think you are if you are applying typical arguments about the JVM or JavaScript JITs.
Edit: typo
Of course interpreter always eats up more cycles (so, more power) than a native code. Does not affect much peak consumption, but drains battery integrally.
Anyway, there is no point at all (zero, full stop) in using a dynamic language in embedded, where all your code is fixed and rarely updated, with no runtime metaprogramming (eval and such).
And, sorry, but there are far better uses for the L2 cache than keeping any fat interpreter there. I would have accepted a cache locality argument for a direct threaded code (and that's the reason why Forth rocks more than C in embedded), but not the Lua kind of interpreter.
Anyway, there is no point at all (zero, full stop) in using a dynamic language in embedded, where all your code is fixed and rarely updated, with no runtime metaprogramming (eval and such).
And, sorry, but there are far better uses for the L2 cache than keeping any fat interpreter there. I would have accepted a cache locality argument for a direct threaded code (and that's the reason why Forth rocks more than C in embedded), but not the Lua kind of interpreter.
Ada is a good language for many things, but isn't very easy to use. It failed that test versus C.
Lua on the other hand, won that test plenty of times.
Lua on the other hand, won that test plenty of times.
JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in. It may not be the best option for any given environment, but that is besides the point. From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
> JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in.
That argument is incorrect. According to TIOBE[1], JavaScript ranks as the 9th most popular programming language with a "Ratings" of %2.194. Behind Visual Basic.NET and PHP.
> It may not be the best option for any given environment, but that is besides the point.
No... that is the precise point "sklogic" is making.
> From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
Or, ignoring people with embedded systems experience, put PHP on a chip and hire people who know it.
1 - http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
EDIT: Added the TIOBE link referenced.
That argument is incorrect. According to TIOBE[1], JavaScript ranks as the 9th most popular programming language with a "Ratings" of %2.194. Behind Visual Basic.NET and PHP.
> It may not be the best option for any given environment, but that is besides the point.
No... that is the precise point "sklogic" is making.
> From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
Or, ignoring people with embedded systems experience, put PHP on a chip and hire people who know it.
1 - http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
EDIT: Added the TIOBE link referenced.
So, in your using TIOBE as a baseline, are you suggesting that Java should be the language of choice for embedded platforms?
From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
MOST software development these days has a web component... not all, but most... that means JavaScript... I would posit that more developers have used JavaScript to some degree than any other language... not their only or primary language.
My argument was to the number of developers who know/use JS... not the language with the most deployed instances. Also, calling out JS for being bad, and suggesting PHP as a language to use is a pretty bad alternative... especially given that everyone who's written PHP has also, most likely written JS.
Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries. I can see the argument for Lua...
From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
MOST software development these days has a web component... not all, but most... that means JavaScript... I would posit that more developers have used JavaScript to some degree than any other language... not their only or primary language.
My argument was to the number of developers who know/use JS... not the language with the most deployed instances. Also, calling out JS for being bad, and suggesting PHP as a language to use is a pretty bad alternative... especially given that everyone who's written PHP has also, most likely written JS.
Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries. I can see the argument for Lua...
> So, in your using TIOBE as a baseline, are you suggesting that Java should be the language of choice for embedded platforms?
Many do by way of Java ME[1], though that would not be my first choice. As I said regarding your premise of a business case:
> > From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
> By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
The vast, vast, majority of embedded systems are written in one of the aforementioned four languages (with a nod to Java ME since I do not have metrics regarding its production use in embedded systems). There exists a huge software world outside of the browser.
> From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
Reviewing my earlier comment revealed that I forgot to include the referenced link. It has been updated to help disambiguate that post.
From it, there is a definition[2] of the "Ratings" I quoted:
> MOST software development these days has a web component... not all, but most... that means JavaScript...
Giving the largest room for expression, I'll interpret "a web component" as software having some form of networking capacity. With that caveat, sure, network communication is very prevalent.
However, assuming this implies JavaScript is a straw man argument[3]. Much network communication exists outside the browser as well.
> Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries.
I disagree with this, but respect your right to have that (and any other) opinion. In an attempt to keep from going completely off topic, I won't go into this anymore in this thread :-).
1 - http://www.oracle.com/technetwork/java/embedded/javame/index...
2 - http://www.tiobe.com/index.php/content/paperinfo/tpci/progra...
3 - https://en.wikipedia.org/wiki/Straw_man
Many do by way of Java ME[1], though that would not be my first choice. As I said regarding your premise of a business case:
> > From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
> By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
The vast, vast, majority of embedded systems are written in one of the aforementioned four languages (with a nod to Java ME since I do not have metrics regarding its production use in embedded systems). There exists a huge software world outside of the browser.
> From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
Reviewing my earlier comment revealed that I forgot to include the referenced link. It has been updated to help disambiguate that post.
From it, there is a definition[2] of the "Ratings" I quoted:
The ratings are calculated by counting hits of
the most popular search engines. The search query
that is used is
+"<language> programming"
The number of hits determines the ratings of a
language.
...
The ratings are calculated with the following formula:
((hits(PL,SE1)/hits(SE1) + ... + hits(PL,SEn)/hits(SEn))/n
where n is the number of search engines used.
> MOST software development these days has a web component... not all, but most... that means JavaScript...
Giving the largest room for expression, I'll interpret "a web component" as software having some form of networking capacity. With that caveat, sure, network communication is very prevalent.
However, assuming this implies JavaScript is a straw man argument[3]. Much network communication exists outside the browser as well.
> Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries.
I disagree with this, but respect your right to have that (and any other) opinion. In an attempt to keep from going completely off topic, I won't go into this anymore in this thread :-).
1 - http://www.oracle.com/technetwork/java/embedded/javame/index...
2 - http://www.tiobe.com/index.php/content/paperinfo/tpci/progra...
3 - https://en.wikipedia.org/wiki/Straw_man
I was actually referring to a web based user interface...
I did a couple of searches on indeed for phoenix, and san francisco, and JavaScript seems to outnumber C++ and C# by a bit, and be fewer than Java.
For interpreted languages, Python was similar in SF, but less in Phx... and ruby was less in both. And there's also the most popular languages on github (#1 being JS).
I did a couple of searches on indeed for phoenix, and san francisco, and JavaScript seems to outnumber C++ and C# by a bit, and be fewer than Java.
For interpreted languages, Python was similar in SF, but less in Phx... and ruby was less in both. And there's also the most popular languages on github (#1 being JS).
> Java
You'd be surprised - see JavaCard.
You'd be surprised - see JavaCard.
Because millions of web developers know it, and if you make IOT type products you'd like to peel off a few of those people to work on your emerging platform.
Who need "developers" of this kind, who are unwilling to learn something as small as a language? And they won't be able to transfer any other knowledge from their realm of web browsers into embedded, besides this thin language layer. So, what's the point, again? I cannot see a single rational reason.
That's a very important point. As an unexperienced developer, you can learn C in a few weeks. Then spend another few weeks on learning how to write clean, maintainable code. I wouldn't want to work with people who don't even want to do that. You already named the most appropriate tools (Assembler, C, C++, and Forth), and learning at least one of them is very easy.
Pick the right tool for the right job. That's what I read all the time. The current approach of 'the industry' is porting JavaScript to just about everything, which is insane. But, you know, learning JavaScript is simple and that's what matters! Well, JavaScript isn't that simple. But writing insane, ugly code and making it run by accident is easier in JavaScript, for example, than in one of the more complex languages.
I've seen things. Things I couldn't imagine in many other (static) languages, because it wouldn't even compile. Things that let me ask 'how did you even get this job?' over and over again.
Pick the right tool for the right job. That's what I read all the time. The current approach of 'the industry' is porting JavaScript to just about everything, which is insane. But, you know, learning JavaScript is simple and that's what matters! Well, JavaScript isn't that simple. But writing insane, ugly code and making it run by accident is easier in JavaScript, for example, than in one of the more complex languages.
I've seen things. Things I couldn't imagine in many other (static) languages, because it wouldn't even compile. Things that let me ask 'how did you even get this job?' over and over again.
> I'm struggling to understand - what's the point of using JavaScript for anything embedded?
The point, I would suspect, is lots of people already know JavaScript, so it lowers the barrier to entry to embedded programming.
The point, I would suspect, is lots of people already know JavaScript, so it lowers the barrier to entry to embedded programming.
lowers the barrier to entry to embedded programming.
Embedded systems often have very different characteristics than e.g. a web app, and just because someone has been doing JS web apps does not mean they'll be any good at using JS with an embedded system (and vice-versa, but maybe less so.) IMHO lowering the barrier to entry is just going to result in many more buggy/insecure IoT devices... (JS does eliminate certain classes of bugs associated with traditional embedded languages like C, but there are plenty other bugs you can find in web apps that are not buffer overflows.)
Embedded systems often have very different characteristics than e.g. a web app, and just because someone has been doing JS web apps does not mean they'll be any good at using JS with an embedded system (and vice-versa, but maybe less so.) IMHO lowering the barrier to entry is just going to result in many more buggy/insecure IoT devices... (JS does eliminate certain classes of bugs associated with traditional embedded languages like C, but there are plenty other bugs you can find in web apps that are not buffer overflows.)
Be careful not to conflate web programming with plain-old JavaScript the language. A lot of the horrible bugs in web programming come from the massive complexity and size related to web browsers, the DOM, and over-engineered frameworks.
If we're talking about streamlined, embeddable JavaScript, we're not bringing the web and all those bloated frameworks.
You are right that those writing web apps won't necessarily be good at embedded systems, especially since (for now), they will have to also separate web APIs from JS-the-language and will not have the APIs they are used to.
But those who survive the transition process will likely pick up better habits. I suspect the APIs and usage will end up looking a lot like the Lua sphere, though perhaps more fragmented since none of JavaScript engines have anything remotely resembling compatible C API interfaces.
If we're talking about streamlined, embeddable JavaScript, we're not bringing the web and all those bloated frameworks.
You are right that those writing web apps won't necessarily be good at embedded systems, especially since (for now), they will have to also separate web APIs from JS-the-language and will not have the APIs they are used to.
But those who survive the transition process will likely pick up better habits. I suspect the APIs and usage will end up looking a lot like the Lua sphere, though perhaps more fragmented since none of JavaScript engines have anything remotely resembling compatible C API interfaces.
> Embedded systems often have very different characteristics than e.g. a web app, and just because someone has been doing JS web apps does not mean they'll be any good at using JS with an embedded system
Indisputably. Lowering a barrier to entry isn't the same thing as guaranteeing success for every entrant.
Indisputably. Lowering a barrier to entry isn't the same thing as guaranteeing success for every entrant.
Language is the least important barrier to entry to any field. Domain knowledge is much more important.
Depends on the age of the field. When fields are young, nobody has any domain knowledge anyway, because the "domain" just got started. At this point, things like technical knowledge, familiar programming languages, and common data protocols are crucial, because that's all the knowledge that exists.
As a field ages and accumulates best practices and social patterns, domain knowledge becomes relatively more important and technology choices become relatively less important.
Many of the biggest profit opportunities in a field come from owning the platform it's built upon, which is why it's logical to try and attract developers early with technologies they're familiar with. Eventually domain knowledge will matter more - but that depends upon the platform becoming big enough that it's a domain.
As a field ages and accumulates best practices and social patterns, domain knowledge becomes relatively more important and technology choices become relatively less important.
Many of the biggest profit opportunities in a field come from owning the platform it's built upon, which is why it's logical to try and attract developers early with technologies they're familiar with. Eventually domain knowledge will matter more - but that depends upon the platform becoming big enough that it's a domain.
This particular field is ages old, with tons of accumulated domain lore.
Domain knowledge of the type relevant to programmers in many fields is gained through experience programming in that field, not non-programming experience in that field.
Unfamiliar programming language is an impediment, for many, to that learning process. If the tradeoff for that is a much clearer mapping to the domain than a more familiar alternative, the unfamiliar language may be, pedagogically, a net win, but -- especially for self-study -- people are more likely to learn enough to look deeply into the domain (including through unfamiliar languages) if the initial entry path is easy from where they currently are.
Unfamiliar programming language is an impediment, for many, to that learning process. If the tradeoff for that is a much clearer mapping to the domain than a more familiar alternative, the unfamiliar language may be, pedagogically, a net win, but -- especially for self-study -- people are more likely to learn enough to look deeply into the domain (including through unfamiliar languages) if the initial entry path is easy from where they currently are.
The problem in this particular case is that the concerns of embedded systems are orthogonal to what anyone who knows _only_ JavaScript has ever dealt with. Those worlds are simply too far apart.
Your case is entirely valid when, say, a person is hired to work in a retail system and who had previously worked in some form of a decision support system.
Your case is entirely valid when, say, a person is hired to work in a retail system and who had previously worked in some form of a decision support system.
Internet Of Things is a rather meaningless term. It was fuzzy at first, and remains so a few years on.
Here, just say "resource-constrained devices" or something with ANY amount of meaning.
Here, just say "resource-constrained devices" or something with ANY amount of meaning.
The authors of this engine are Samsung, who are currently leading the world in promoting the "Internet of Things" buzzword.
AKA how to not to make a landing page. "For more info check the Github" -> "View the wiki for more info" -> repeat.
Isn't this basically the same as the Espruino [1]?
Has anyone compared the two in terms of performance and handling?
[1]: https://github.com/espruino/Espruino
[1]: https://github.com/espruino/Espruino
JerryScript - A scripting language about nothing.
For anyone interested in IoT, look at the esp8266.
It is a tiny chip with included wifi. It was 2 digital IO ports, and also a serial connection if you want to connect it to an arduino.
And at the moment it costs 2.6 USD on ebay!!!
And someone made a plugin so you can program it from the Arduino IDE: https://github.com/esp8266/Arduino
It is a tiny chip with included wifi. It was 2 digital IO ports, and also a serial connection if you want to connect it to an arduino.
And at the moment it costs 2.6 USD on ebay!!!
And someone made a plugin so you can program it from the Arduino IDE: https://github.com/esp8266/Arduino
This is something Tessel does well, I believe they do all kinds of transpilation to Lua. This could be really useful for them.
IIRC, I believe the Tessel guys are abandoning the transpiler approach in favor of slightly more powerful hardware for the next generation that can just run node directly... We're really at a point where for the types of projects people want to run for under $100 of hardware, it's fast enough to do a lot more.
Power is a bit of a concern, and it all depends on the environment... being able to get every web monkey coding in more environments is a big win for enthusiasts and commercial applications for limited scope projects... Hell, without a screen or antenna powered on all the time, you can get a lot of processing done on even a smart phone from two generations ago.
Power is a bit of a concern, and it all depends on the environment... being able to get every web monkey coding in more environments is a big win for enthusiasts and commercial applications for limited scope projects... Hell, without a screen or antenna powered on all the time, you can get a lot of processing done on even a smart phone from two generations ago.
http://www.espruino.com/
This has been around for a lot longer than Samsung's (as far as I know) and has a lot of great support. If you're looking for a small, embedded JS processor built specifically for this kind of thing, I'd recommend Espruino.
This has been around for a lot longer than Samsung's (as far as I know) and has a lot of great support. If you're looking for a small, embedded JS processor built specifically for this kind of thing, I'd recommend Espruino.
Am i the only one who doesn't get the reference? Where does the name Jerry come from?
My first thought was "jerry-rigged". Rather than starting the almost inevitable conversation here ("jerry" vs. "jury"), I'll point out the following SE answer[1]...
[1] http://english.stackexchange.com/questions/132868/jury-rigge...
[1] http://english.stackexchange.com/questions/132868/jury-rigge...
It comes from "Tom and Jerry". Source: I was there when the name was decided.
Very interresting.
But I just hate this "Internet of Things" name... There must be a better suited name for it.
But I just hate this "Internet of Things" name... There must be a better suited name for it.
I like the name :)
Wait, so Samsung wrote their own new JavaScript engine for embedded devices? This is actually very cool.
It looks very constrained in what it supports so far though.
Update: They're at ECMAScript 5.1 https://github.com/Samsung/jerryscript/issues/205 but not all tests are running https://github.com/Samsung/jerryscript/issues/158
Ok, it doesn't yet JSON.stringify https://github.com/Samsung/jerryscript/issues/432 so not sure if ready yet.
It looks very constrained in what it supports so far though.
Update: They're at ECMAScript 5.1 https://github.com/Samsung/jerryscript/issues/205 but not all tests are running https://github.com/Samsung/jerryscript/issues/158
Ok, it doesn't yet JSON.stringify https://github.com/Samsung/jerryscript/issues/432 so not sure if ready yet.
a few days ago Cesanta brought their v7 JS engine to the esp8266 and now samsung is showing JerryScript. Pretty interesting times for embedded JS
Nice. JavaScript allocates a lot of memory dynamically, and sometimes implicitly, though. In very tiny RAM environments, that's going to be a problem.
It would probably be OK if all programs have a simple, predictable sequence of malloc and free that they call in a loop, with similar-ish sizes each time.
It's extremely unpleasant to program something with just a few KB of RAM and not know exactly what memory goes where. However, a lot of IoT-related gadgets just gather a buffer of data from an ADC or something, average it and send it over some wireless protocol every 1 minute. The allocation pattern is predictable enough that you don't run into strange cornercases.
I see no reason why anyone would want to use this commercially, but for the enthusiast market (and maybe even for some rapid prototyping) this looks interesting enough.
It's extremely unpleasant to program something with just a few KB of RAM and not know exactly what memory goes where. However, a lot of IoT-related gadgets just gather a buffer of data from an ADC or something, average it and send it over some wireless protocol every 1 minute. The allocation pattern is predictable enough that you don't run into strange cornercases.
I see no reason why anyone would want to use this commercially, but for the enthusiast market (and maybe even for some rapid prototyping) this looks interesting enough.
It seems to me that consistent allocation patterns would help more if JerryScript used reference counting for memory management, perhaps with mark-and-sweep GC as a backup to handle cycles. As it stands now, each object has a reference count to keep it alive while it's being used by C code via the API, but actual deallocation is done via mark-and-sweep GC.
had the same thought, why do I have to do everything with JS, sometimes I think it's only to satisfy "Atwoods Law" again and again :) would do it in Go lang, not as raw as C but good and up to date enough for this purpose.
JerryScript needs 64 KB RAM, 200KB ROM. So what can it run on?
So the target for JerryScript is machines in the Due range. Rust has been crammed into the Arduino Due, which may become a good approach for embedded work. Go probably won't fit; too much runtime.
They're all in the $25-$45 price range. The Due, surprisingly, is the most expensive.
Ardunino Uno (ATmega CPU): 2KB RAM, 32KB ROM - Too small.
Arduino DUE (ARM CPU): 96KB RAM, 512KB ROM - Yes.
Raspberry Pi (ARM CPU): 256MB RAM, 1GB+ ROM - Yes, but why?
So the target for JerryScript is machines in the Due range. Rust has been crammed into the Arduino Due, which may become a good approach for embedded work. Go probably won't fit; too much runtime.
They're all in the $25-$45 price range. The Due, surprisingly, is the most expensive.
The ESP8266 may be a good candidate. tmrmr already said in these comments that some other company had ported another JS engine to the thing. And the world isn't just Arduinos, Raspberry Pis and other nicely-packaged "hacking" solutions.
Yep, I've been running Node.js on a Raspberry Pi with Arch Linux ARM embedded project for a couple months now. It works great, other than the startup time for Node being pretty rough.
> Ardunino Uno (ATmega CPU): 2KB RAM, 32KB ROM - Too small.
To be fair, that system really doesn't run anything dynamic well.
However, your point stands. Requiring 64K of RAM puts this above most ARM Cortex M0 chips.
Picobit (https://github.com/stamourv/picobit) sits comfortably in 16K ROM/4K RAM. There's no good reason why Javascript vouldn't do the same.
To be fair, that system really doesn't run anything dynamic well.
However, your point stands. Requiring 64K of RAM puts this above most ARM Cortex M0 chips.
Picobit (https://github.com/stamourv/picobit) sits comfortably in 16K ROM/4K RAM. There's no good reason why Javascript vouldn't do the same.
Probably this https://www.artik.io/hardware/artik-1
Raspbian, the default OS for Raspberry Pi, actually includes JavaScriptCore as a standard, pre-installed component.
How does this compare to duktape (http://duktape.org)? I really like duktape's API and documentation (stack-based interface similar to Lua and the doc perfectly describes how each function call affects the stack state).
The API isn't stack-based. It's more like the Python C API, complete with reference counting (but note that actual memory reclamation is done through mark-and-sweep GC), except that instead of everything being a pointer to an object, numbers and booleans are represented directly, so a union is used to represent values.
[deleted]
Fun alternative: Compile JS to Lua and run that instead (e.g. as done by https://tessel.io/)