Hi David,
On 8 Jun 2016, at 11:17, David Moshal wrote:
Thanks Wayne, that's very interesting, I think it helps explain the
disconnect here.
I understood David Simmons to be suggesting that Makers (like me) are
the target end-users,
i.e: that MyNewt would be an alternative to, say, Arduino (and why
not).
However, in your use-case, you are the end-user of MyNext, and Makers
are your end-users, no?
i.e: a layer lower in the stack. So, in that case MyNewt would be
positioned as an alternative to an RTOS (or no RTOS) for embedded C
programmers building devices for Makers.
So, if I may, I'd suggest that we step back and ask Sterling who
exactly he envisages as the end user of this project:
Makers, or embedded C developers building devices for Makers?
I’ll give my 2c here, but I do want to point out: this is up to all of
us, I’m just one vote.
I think Mynewt can have a broad set of users, which include:
- Makers who are embedded C developers
- Embedded C developers who are building devices for Makers
- Scripting language OS support
- Embedded product developers
- Microcontroller and sensor vendors who want to provide reference
support for their platforms
And actually, having the project support a broader set of these
use-cases should reinforce itself.
As an example, I’m a maker who is an embedded C developer. I would
_never_ use Wiring or Javascript to develop a project unless forced to.
I enjoy writing things in C, and don’t mind typing a little extra or
managing memory in order to have direct access to the underlying
hardware. Mynewt needs to be easy to use, and efficient for people like
me, that’s why we’ve bundled toolchains with Docker, and have built
a build & package management tool.
As you point out, there are plenty of cases where Wiring, Python and
Javascript are better choices, and reach a broader set of people. If
you look at the popular languages in embedded IoT, almost all of them
re-invent the HAL, BSP, and many facets of the OS. If we can provide an
engine, and they can hook into that, we can gain re-use on the
non-language specific elements across all of the scripting languages. I
look at this very similar to how PHP and Perl relied on Apache as the
web-server. There is no reason that Micropython and Espruino
shouldn’t be sharing HAL and BSP work, and the best way to do that
(IMO) is to share efforts on a OS that they both plug into.
And the OS itself should be low-level and architected well enough that
product developers can actually put it into real products and
manufacture at scale. At Runtime, we’re building the system we always
wished we had, and have had to reinvent at every company we’ve been
at. While it’s an additional effort to support Makers and Maker
platforms, there are real benefits to product developers in using an OS
supported by Makers:
- Testing: If 100’s of thousands of Makers use Mynewt’s BLE stack,
they are going to find bugs in it very quickly, and motivate Apple,
Google and everyone else to be interoperable with it. With enough eyes
all bugs are shallow.
- Ease-of-use: You see this in devkits as well. Take the NRF51/NRF52.
They are not only widely used in products, but are beginning to be very
popular in maker platforms. The more support for sensors, peripherals
and cheap hardware you have around this platform, the easier it is to
develop prototypes and move it into products.
- Innovation: Products aren’t always going to be built around things
like LORA, or Sigfox right away. But if Makers support these platforms,
it becomes easier for product companies to play with them, and then
start adding them to things.
So. I do think Mynewt itself will always be a low-level C operating
system. That said, I don’t think we should be tied to a use-case, but
rather just go where it makes sense. I think for Makers that like C, we
should make it as easy to use and robust as possible, and we should have
it work with as many scripting engines as possible (Wiring, Python,
Javascript, Lua, etc.)
Sterling
