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
