also: as you look at this, if you need changes to newt (tool) or can
think of ways to have newt make bringing in 3rd party libraries easier,
feel free to ping dev@ (ideal) or me directly.
we enforce a directory structure on packages with newt, but that
doesn’t always need to be the case — we control our destiny with the
tool. i’ve been toying around with a few things, including having
newt call a pre-build script which can take a 3rd party library, and
layout it so that newt can build it/or can call it to build the library,
and then just link in the sources.
anyhow, as you dig in: i’d be interested in thoughts, and if you have
ideas on how to change it, i’d be happy to put in the work to make it
easier.
sterling
On 28 May 2016, at 10:38, Sterling Hughes 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
