This is fantastic! Glad to see so much enthusiasm for JavaScript on an IoT device.
Here’s the thinking I have had on the subject, and why I have turned to MyNewt to try to make it a reality. JavaScript is hugely popular, and resents a fairly low-bar for entry into IoT development. JavaScript — when done right — can be extremely efficient and fast I have been focussing on Node.js for a few reasons. Some of the server-side stuff is incredibly useful for IoT — enabling REST APIs on-device is a big win, etc. But Node is far too large. It just won’t fit on any reasonable IoT device, and the processing power to run it quickly and efficiently is too much for a truly IoT device. So what to do about these things? In a galaxy far far a way, at a different time in IoT history (before there really was an IoT) I worked on a project where we implemented Java on IoT. Java on the metal. And it was basically the full Java SE, minus all the UI stuff. We did some interesting things that I was thinking of applying to this project. We did compile and build on the host machine pre-deployment to the device (we had an ARM9), and in that compile and deploy stage we basically pulled out anything that wasn’t used explicitly. We created stripped-down bytecode that ONLY contained what was used in the application. The underlying OS — also Java — handled strictly OS-related tasks and took care of networking, storage, power management, etc. and executed the byte codes sent as apps. We had a set of sensor libraries that handled the SPI, I2C, PWM, ADC, etc. and abstracted out a bunch of stuff like servos, stepper motors, etc. so developers didn’t have to do the dirty work on a lot of those things. So I was thinking of a similar architecture for Node. A basic runtime that handled OS-integration functions, with MyNewt handling the HAL, BSP, Drivers, etc. as Sterling noted below. Developers could use pretty much any npm modules they need, and these would be stripped of any methods/functions not used, combined with Node (similarly stripped of any functionality not explicitly used) and then deployed on-device to be executed. There is a vast amount of work to be done in making this system smart enough to be able to do the above-mentioned magic of stripping down everything and effectively and efficiently compiling it, but it could make for a very small, efficient, and almost infinitely extensible and flexible developer experience. Anyway, that’s my stream-of-conciousness brain-barf on the subject, and where my thinking has been headed on this, and why I’m doing it. I’ve been targeting some (soon-to-come) *extremely* low power IoT SoCs — these are 2-3 orders of magnitude lower power than anything available today that operate in the 10-20𝜇W range at full power, in the nano-watt range for idle (including radios). These are going to be based on Cortex M-0 architecture (maybe M-3) as well. I’ll take a look at JerryScript and see what the effort there might be. dg > On May 26, 2016, at 3:19 AM, Sterling Hughes <[email protected]> wrote: > > I'd like to echo the sentiments here: I think this would be great. > > I think good scripting language support is very important for Mynewt. Most of > the newer chipsets (like the NRF52), have enough RAM and Flash, that you can > run the OS, Bluetooth stack, and still have 256KB or more left over for a > fairly complex application. Also, you could imagine the Mynewt OS being > preloaded on boards, and then someone uploading code to them using firmata -- > whether it be Javascript, Python or Wiring code. This would provide a simple > programming model, but enable full OS support -- and I think this could be > easily integrated into PlatformIO or the Arduino IDE. > > Additionally, if you look at a lot of the popular scripting languages > (Espruino, Micropython, Wiring) -- they end up having to implement a whole > bunch of things better left to the operating system (HAL, BSP, Network > stacks, Drivers.) If they can plug in to Mynewt, they don't have to worry > about any of that. > > I don't know how much time I have in the next couple of months to devote to > this, but count me in on joining in the development/helping to support as > much as possible. I'll definitely test things :-) > > Some thoughts on the various options for Javascript. This is meant as more > of a dump of what I've looked at / been thinking about in case you find it > useful: > > - Jerryscript: Apache 2 license, which is critical should we want to bundle > it with Apache Mynewt. It looks like a good Javascript interpreter, my only > concern is that it separates the compile & run stages, and I'm not sure how > memory efficient the compiler is. > > What's very nice is that Jerryscript is just the Javascript engine, and it > looks fairly easy to write custom extensions for it. If somebody could > evaluate the memory usage when parsing, it would be great. > > - Espruino: Espruino's popularity is, I think, due to the fact that it > provides a full operating environment, not just the Javascript engine itself. > It looks pretty solid, and both the parser and engine have been shown to run > on exactly the microcontrollers we've been targeting. > > Espruino uses the MPL, and has a copy-left license, which is somewhat more > restrictive then the Apache license. It is also less complete than > Jerryscript, from what I can see. > > - v7 is GPL. > > - Javascript to Lua compilation: We already support Lua, and it's an > incredibly efficient virtual machine for these small environments. Since > Javascript is made to be compiled, and recompiled -- we could support > Javascript today through a JS->Lua compiler. This would also mean we only > needed to do the language bindings once, and could run both options. > > The downside is, what actually runs is Lua, not Javascript. There wouldn't > be a Javascript console on the device. > > (compilers: https://github.com/PaulBernier/castl, > https://www.npmjs.com/package/lua-colony) > > I personally like the Jerryscript option the best (thus far), due to the > license, and the fact that it's just a JS engine. Followed probably by the > JS->Lua compiler (which, with one effort gets us both Lua & JS support.) > > I don't imagine getting Jerryscript ported will be a whole bunch of work, > it's just importing it into our build system. I think the big effort will be > around making sure we choose the right OS APIs. I think it will be good to > look at a few things on the OS side, to make it easier for the Javascript > integration: > > - Ensuring our BLE APIs are designed to map easily to the JS interpreter > > - Adding some form of sensor API, to abstract access to common sensors > > - Adding a bunch of higher level drivers (above the HAL), that provide > simpler APIs to access hardware functions -- that we then map into JS. > > But first things first, just getting the interpreter up & running & talking > to the OS would be awesome! > > Sterling > > > > On 5/25/16 7:57 PM, David Moshal wrote: >> Ok David, I'm game. >> >> I'm familiar with NodeJs, have mission critical NodeJs software in >> production, with no downtime, since 2011. >> >> I don't know what platforms MyNewt runs on, but you're going to need >> significant horse power to run the NodeJs V8 engine. I've run NodeJs on >> the Arduino YUN (400Mhz, 64Mb ram), using Linux, so that's probably the >> ballpark, spec-wise. >> >> On the other hand, if what you want is a Javascript engine in general, then >> there are at least half a dozen alternatives. I've used Espruino, on its >> own Pico board (STM32f401), and on ESP-8266 (32bit Tensilca core). There >> are others, V7, TinyJS, JerryScript, etc. >> >> So, what are the next steps? What's the best IDE environment to use (I'm on >> OSX). >> Can Platform.IO be used, or is that a competitor? >> >> Dave >> >> >> >> >> >> >> On Wed, May 25, 2016 at 4:56 PM, David G. Simmons <[email protected]> wrote: >> >>> Maybe we should work together! My goal is to get Javascript (actually >>> Node.js) running on MyNewt. I have C experience, but there is lots to do in >>> order to make this work the way I need it to. >>> >>> Best regards, >>> dg >>> >>>> On May 25, 2016, at 6:49 PM, David Moshal <[email protected]> wrote: >>>> >>>> Thanks, actually I've been using both lua and JavaScript (espruino) on >>>> esp8266-12e for a couple months. >>>> >>>> As mentioned to Sterling at the maker faire last weekemd, my interest in >>>> mynewt is actually to try and embedded js on the emw3165, which has the >>>> stm32f411 plus wifi. >>>> >>>> However I have zero experience with c, and specifically with the tool >>> chain >>>> and use setup. >>>> >>>> That's the part of really like help with. >>> >>> -- >>> David G. Simmons >>> (919) 534-5099 >>> Web • Blog • Linkedin • Twitter • GitHub >>> /** Message digitally signed for security and authenticity. >>> * If you cannot read the PGP.sig attachment, please go to >>> * http://www.gnupg.com/ Secure your email!!! >>> * Public key available at keyserver.pgp.com >>> **/ >>> ♺ This email uses 100% recycled electrons. Don't blow it by printing! >>> >>> There are only 2 hard things in computer science: Cache invalidation, >>> naming things, and off-by-one errors. >>> >>> >>> >> -- David G. Simmons (919) 534-5099 Web • Blog • Linkedin • Twitter • GitHub /** Message digitally signed for security and authenticity. * If you cannot read the PGP.sig attachment, please go to * http://www.gnupg.com/ Secure your email!!! * Public key available at keyserver.pgp.com **/ ♺ This email uses 100% recycled electrons. Don't blow it by printing! There are only 2 hard things in computer science: Cache invalidation, naming things, and off-by-one errors.
signature.asc
Description: Message signed with OpenPGP using GPGMail
