David, Sterling, let me throw in my 2 cents. Firstly, Thank you David Simmons, it's really interesting to look at it from the perspective of the original embedded Java efforts. I recall following that project closely in the late 1990s.
In the case of Javascript though, I think the problem may be simpler than you think, especially when it comes to NodeJS compatibility. NodeJS has hundreds of thousands of community-created libraries, some written in different flavors of javascript (e.g. Coffeescript, Typescript, ES-6, etc), and written using several different dependency management standards (CommonJS, RequireJS, etc.), so entire ecosystems have been developed to manage this interoperability already. Basically these ecosystems work by: a) using 'transpilers' to convert various flavors of Javascript (coffeescript, typescript, es6, et7), to a lowest-common-denominator ES5 format, together with a mapping file so that you can debug against the original code! An example of such a transpiler is Babel. b) using 'package managers' to manage dependencies between these various components, both at development time and runtime. An example of such a packager is Webpack. Basically these ecosystems treat ES5 Javascript like the 'byte code' of the Java world!! (btw, Espruino team found that ES5 source code is more compact than the byte-code created by any Javascript engine, so there are surprising tradeoffs in memory constrained devices!). To play in that ecosystem, you basically need: 1) to emit and consume ES5 compliant Javascript. 2) implement perfect JSON parsing and stringification. 3) support http and websocket protocols. 4) support the CommonJS module standard which NodeJS uses. Optionally: 6) a babel plugin to support real-time transpilation to other js flavors (e.g. ES-6, or Typescript). 7) a webpack plugin to support 'hot redeploy', remote debugging, and other niceties of that platform. David On Sat, May 28, 2016 at 10:38 AM, Sterling Hughes <[email protected]> wrote: > Hi David, > > On 26 May 2016, at 8:36, David G. Simmons wrote: > >> 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. >> > > +1 — I think this is perfect. What’s great is that early on, this will be > very suitable for makers, but eventually also product developers. > Fundamentally, what you’d like is a set of expertise that is “kernel” — new > networking stacks, board support packages, drivers, and then an interface > that is Javascript. That way, even product companies, can just pay > consultants to port the kernel, and develop the majority of the application > in JS. > > We have Lua ported, but I think we’d look to have Javascript be the go > forward option, if it was working with the system. > >> 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. >> > > Awesome— I think I have an idea of who you’re talking about :) > >> I’ll take a look at JerryScript and see what the effort there might be. >> > > Cool. I’d be interested in your thoughts as you dig in. If they are > unsuitable for a public mailing list, I’d be interested unicast as well. :-) > > Sterling >
