> Prototyping and Scripting Engine

> Micropython Moving to production (C/C++) or factoring out critical pieces to C/C++ is not trivial

VS.

> mJS - JavaScript engine for prototyping and C/C++ for production

I don't know much about it, but from the surface it seems that the problem is exactly the same? What is the benefit of prototyping in JS instead of Python? In the end, either you refactor everything purely in C, or you use both in your production system.

I see mJS does FFI to interface with other C routines. Why introduce a second language to your project? This seems like a huge overhead for no benefit (you're still expected to write C at some point). The language is only a subset of JS, so "not JS", so no ecosystem and new assumptions you have to redefine before getting serious with it?

Is it just me who thinks it's a bad idea? Would someone be able to explain the advantage of going in this direction?

Speaking from experience, using MicroPython is trivial and often "good enough", as are implementing modules for MicroPython in C should they be needed (C isn't my first language by a long shot, but I managed to write a module for MicroPython with little problem).

Also, MicroPython has pretty much all the features of core Python whereas mJS appears to have pretty much all the useful features of JS removed. Why not just use C instead of mJS?

Finally, couching Mongoose in a way that criticises the efforts of others is a bit of a turn off for me. Give me positive reasons for using your product rather than bashing the people you believe are your competitors. The culture and community of a project is important - negativity such as this is a worrying signal.

> Why not just use C instead of mJS?

Perhaps mjs has a repl? Don't really know, but that would be the only real advantage imo.

Indeed, share the vision of the product instead and how does it add value to the existing ecosystem.

The advantage is time. Many (most?) embedded environments are overly difficult (IMHO), and/or proprietary. Also, even in a good environment, C/C++ typically requires more lines of code than dynamic languages like Python or JS.

Therefore, the industry has been looking for ways to combat both the below par developer experience, and the development time. Samsung's Jerryscript [1] is another example.

That said, I think these things are aspiration more than they are practical.

[1] http://jerryscript.net/

Note: Edited to clarify C++ vs. dynamic languages.

Sure, I think I see the reasoning behind: reduce the time to market for embedded products.

But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so. It seems that both are capable of handling this problem, however mJS seems aiming at a compromise between JS and C, and my opinion on this is that it will introduce huge overheads on any projects. This mostly stems from my being wary of multi-language projects.

The process involved in embedded platforms seems heavy enough as it is, no need to blur the lines further.

> But I'm mostly wondering the actualy benefit of choosing mJS instead of micropython to do so

I agree with your concern: to me Micropython seems like a much better choice. On the other hand, it's pretty limited to what hardware it runs on.

mJS allows you to use C/C++ SDK functions directly without writing a glue code - basically, you can prototype things quite fast with the libraries/drivers that do not have any scripting support yet.

But why not make that for micropython instead of making a whole new language?

Ideally you don't want to port the C/C++ over to Python: that's the value proposition of mJS, I think.

> Why introduce a second language to your project? This seems like a huge overhead for no benefit (you're still expected to write C at some point)

If i was having an IoT company or start-up, i would make sure to hire proper engineers; the ones that have no problem with switching between Javascript, C, and Python, or learning them on the fly if needed.

Seriosly, is this really a problem at all?

It is obvious that it is quicker to prototype in Python or JS or whatever scripting language. While for real world usage you would also care about performance and efficiency issues which would better be solved by having more direct control over the bare-metal (C, even assembler.)

> Seriosly, is this really a problem at all?

Yes. I write Python and C everyday. I am highly proficient in both. I would quickly withdraw from a project that mixes both in the same code base.

I'd also be slightly alarmed to see someone claiming to be able to distinguish proper engineers and not being aware of the issue with multi-language projects :-) .

My issue with multi-language project is that you introduce a lot of overhead to the process surrounding the code. The code-review / static analysis, build and test all requires an additional toolchain and associated best practices. It is already an issue with single-language projects to do this right, it quickly becomes a nightmare when you introduce an additional language.

And that's without even considering the need of FFI integration or likewise, with possibly (preferably) framework to handle the generation of the interfaces, and thus the introduction of another dependency, a possible sub-par codebase with the associated bugs, and potentially very subtle bugs due to your objects not playing nice with the intermediate representation.

I did it with a C++ / Java interface, never again. I would never greenlight such a project.

This has nothing to do with the proficiency or the willingness to learn of your engineers.

Fast prototyping is the answer. If you or some others are skilled in C/C++, you don't need JS.

For others, having a simple way to prototype fast on the target hardware is a big benefit.

> GPLv2 license: FREE FOR NON-COMMERCIAL USE

This confuses me, the GPLv2 doesn't say anything about commercial use, it merely says that you need to redistribute the source code to anyone that you distribute your software to.

Have they placed additional restrictions on the GPL (which I believe you are prohibited from doing)? or are they just trying to highlight that they are dual-licensing it under a license that isn't copyleft if you pay them (since lots of companies have no-gpl policies)?

Seems to be the latter, fairly typical "its GPL unless you want to pay us for a different license"

https://github.com/mongoose-os-libs/mqtt/blob/master/LICENSE

It seems that it lacks the "or (at your option) any later version" part. Which is quite sad.

And an odd choice, even if your target market is tyrant devices. Why not encourage corporations to pay for the non-free license by restricting the uses of the free version?

Sounds like they are trying to say you can't opt for the GPL if you plan on commercial use.

Not a lawyer, but I don't see how that flies. They could make their own GPL-like license with that clause added in. But using it as-is means it's open for commercial use, subject of course to the GPL terms. https://www.gnu.org/licenses/gpl-faq.html#GPLCommercially

They might argue that packaging a product with their OS and selling it is the equivalent of white labeling it, which might be technically true, considering the user would have no idea what's powering the thing.

It would be the equivalent of writing a GUI plugin for WordPress and trying to sell it as something like Squarespace.

Not that I agree with this possibility of Mongoose OS's approach. I don't at all, and think it would completely negate their "open source" claim, from a semantical standpoint.

I haven't checked what Mongoose does, but it's fairly common for embedded OS's to link the application and kernel together. IOW, using the GPL may force you to give the source code to your customers if they ask for it.

So I'm a little confused on how licensing works in these types of situations. 'GPL may force you to give the source code', which source code? Presumably whatever code lives on the device that uses Mongoose is just one piece of a much larger puzzle. So does this imply you only need to give the code that lives on the device running Mongoose? Or any of your code that interacts with it?

What he's saying is that embedded devices a lot of the time statically link the kernel, libraries, and application all into on bare metal program. A GPL licence on the kernel and libraries would affect the application.

Right. My question is if the code on the bare metal device talks to, say, a cloud server running an API, does the code running the API also fall under the GPL, and therefore need to be released? I assume not, but assumptions can be dangerous.

Oh gotcha. No, your remote code wouldn't need to be released just because your IoT code is GPLed.

In reality nobody knows, it's very a very complex question that has been barely explored in court.

In practice everybody acts under the assumption that the GPL affects all code that is statically linked together, but nothing else. Some people extend the interpretation to dynamic linking, but consensus is that the GPL does not affect code interoperating over other interfaces like web APIs.

That's an odd phrasing for sure.

I assume what they mean is that you can purchase a special license which allows you to use moongoose without GPL (typically for proprietary use), for example, x264 and x265 (well known GPL licensed encoders for h264 and h265) does exactly this.

GPL does not allow static binaries from both GPLed code and commercial code.

A workaround is a plugin mechanism with dynamic loading of .dll or .so libraries. But that won't fly on a microcontroller.

.dll won't help with GPL, only with LGPL (IANAL)

I think you have it backwards, if I am interpreting your very brief statement fully correctly...

If you are building a library and you want it to be open source but also usable by products that are not open source, you can use LGPL. If you are building a proprietary library and you want to keep it proprietary, but link it into a GPL application, I think there is nothing is stopping you from doing that.

You still have an open-source application, it just won't work without the proprietary library.

(This sounds like it should be against the letter of the GPL, but as a thought experiment, pretend someone else wrote the library. Say, Nvidia, and you are Linus. You have no control over how their library gets licensed, and there is no person or body which can stop you from releasing your own code as GPL, even if it may have branches that depend on proprietary code.)

Doing OSS this way is most certainly against the spirit of the GPL, but I think it is within the letter.

You read the previous statement backwards. OP meant: dynamic linking allows you to use LGPL libraries with proprietary applications; to use GPL libraries in your application you have to make your application free even if you are linking dynamically.

Yes, but neither one prevents you from linking proprietary libraries into your OSS application.

> .dll won't help with GPL, only with LGPL (IANAL)

Was pretty much totally ambiguous about what exactly was meant.

Am I wrong?

Commercial code can be GPL.

> Have they placed additional restrictions on the GPL (which I believe you are prohibited from doing)?

At that point, doesn't the trivial defense just become "It's not GPL. It's my own custom license which happens to have all the requirements of the GPL plus $my_awesome_additions"?

There was a mistake on the site and it is now corrected

Cool, thanks for clearing up the confusion (probably mostly just on my part, but thanks.)

By having complex and/or copyleft licensing, it just opens the door wider for the Apache Mynewt OS with its Apache 2.0 license. http://mynewt.apache.org/

> FEATURED COMMUNITY PROJECTS

> Door bell - ESP32, AWS IoT

> Door sensor - ESP32, MC-38, AWS IoT/MQTT, SNS

> Smart heater on AWS IoT

> IoT doorbell that works via MQTT - generic MQTT server, AWS IoT, Google IoT, etc

Why the hell would I want my door bell be controlled via MQTT on AWS?

It's not on AWS but runs on a local raspberry pi, but my doorbell signals via MQTT that someone ringed. This makes my security camera take a picture and sends a push notification to a custom made iOS app which shows who's in front of the door on my apple watch. If I'm logged in my home wifi, I can even open the door with a button directly from this notification. I would argue that I'm not the only one who finds that useful.

Is "signalizes" a word? Did you mean "signals"?

Thanks, I've corrected it.

To know when someone ring your doorbell but you are not in home so that you can connect through voip to speakerphone near doorbell and speak with someone who stands before your door.

It's probably one of first examples, like "Hello World!". Who in their right mind would write hello world, they are written for all languages already.

Probably to make use of their whole IoT platform, such as https://aws.amazon.com/greengrass/. I still wouldn't use it over a properly architected local solution (being a software architect with focus on security), but if you _really_ don't want to write the non-feature-specific code then I suppose their stuff isn't that bad.

There's actually a very good use case if you have sleeping children:

https://www.alittletothewright.com/index.php/2017/05/doorbel...

Indeed. We just bought a house and I'm excited to actually invest (in terms of electronic projects). Top thing on my list is to make the doorbell send a notification when our little one is sleeping, instead of sounding.

From experience you want to get them used to noise rather then keeping things quiet.

With the first child, I made the mistake of hanging out of the window at 10PM trying to get the attention of the pizza guy so he didn't ring the door bell so we got to eat in peace.

By the third child, you could set a firework off in the living room and she'd stay in bed.

Be noisy! Be free!

So that anything else that is connected to AWS can control your doorbell. Maybe the doorbell could have different sounds depending on what service (pizza, Amazon,friends) is on its way or just pulling up to the driveway right now.

I think a smart doorbell is a great idea for a product.

You had me until the "Pricing" section.

The Old Way - Varies, depends on many factors. Requires ongoing investments, hiring developers or integrators

The New Way - GPLv2 license: FREE FOR NON-COMMERCIAL USE / Commercial License: CONTACT US

So with Mongoose OS, you don't have to invest, or hire developers? Am I being unfair by thinking that, while the other points make life easier, this is scraping the barrel a bit?

Why not just say "and the price which gets you all of these advantages is.." ?

Are you annoyed that they're selling commercial exceptions to the GPL or that they're not listing the price on the page?

The latter. Just give me an idea of the order of magnitude of the price. Is a commercial license closer to $1000 or $100,000?

Bit of a confusing name, when there is already an extremely popular mongodb node.js framework called Mongoose

Also confusing as there is a small mammal that eats snakes called mongoose.

Also confusing when there is a vehicle in the Halo series called Mongoose. Confusing, confusing...

its quite a cool mammal :)

Disagree with the downvote. Never used mongoose, nor am i a node developper, yet my first reaction was to wonder why a js db library evolved in an iot framework.

I think Mongoose was called mongoose before mongo db plugin existed.

https://github.com/cesanta/mongoose - that's the project from which Mongoose OS stems.

Mongoose, not to be confused with Mongoose.

https://metacpan.org/pod/Mongoose

This one is the best named of the 3. It's actually a simple contraction of Mongo + Moose, the two key libraries used in the project.

Also an embeddable http server.

I think developed by same people: Cesanta

Not the first and not the last:

spark(hadoop tool vs java framework), yarn (hadoop tool vs facebook pkg manager), ...

I really fail to see what this brings to the table.

In the section on their main page contrasting with arduino, they bascailly just say that they're more reliable, with nothing to really back that up.

Looking at their documentation, I don't really see how they can make that claim. The issues with Arduino's reliability stems, IMO, from the fact that Arduino code isn't an RTOS. Ie. there's no separation of real time priorities. This also seems to not really be an RTOS either, just a fancy bare metal environment.

What is this structurally bringing to the table beyond Arduino other than "we think we wrote the code better"?

I'm thinking about using Mongoose for a future project (as opposed to Arduino IDE or the ESP SDK directly) I think the advantages are:

Security: TLS 1.2, x509 certificates, ability to stop random people from flashing your board)

Remote management: OTA process doesn't seem that different from other methods, but they have some other nice things. For example they make it really easy to separate your code from your configuration.

> ability to stop random people from flashing your board

That part in particular seems like a really bold assumption.

I haven't read over their encryption code, but even if it's not enough to stop a determined hacker it's still better than nothing.

"The old way: Micropython" <-- what? really? old, already? They're just getting warmed up, baby.

Damn right. Mid level python dev in my team builds Django views on one screen and programs the embedded micropython board that sits on the drill in the pit on the other, all while cajoling with his millennial tribesman in the chat app du jour. Can't beat that.

But why Javascript? Clearly another hype-driven project. Please, use reason not hype when deciding on technology. This is fast food

Is it not reasonable that any Joe Schmo can easily build both front end UI's and servers with one of the most adopted languages?

I'm reminded of earlier efforts using Firefox OS which sought to create a "Web of Things". I'd didn't get around to backing the Runcible project but watching Aubrey's video below, I hope it succeeds.

http://janos.io/ https://www.youtube.com/watch?v=0qgIObR6jGs http://mono.hm/

JS is for prototyping.

C or Javascript is available.

If you're considering embedded OS options, please look at these two (completely free) projects from the Linux Foundation:

Yocto project creates a custom embedded distro based on your needs https://www.yoctoproject.org/

Zephyr supports hardware that can't easily run Linux https://www.zephyrproject.org/

Sure, try to run those on e.g. TI CC3200 microcontroller.

Yocto does not seem to support CC3200.

That's right, cause Linux cannot run on the large class of microcontrollers - particularly, those with less than 4M of RAM. Mongoose OS is targeting that category.

Zephyr is an open source OS that targets smaller microcontrollers.

A recent tweet that I found funny - "Every time a conf organizer accepts a talk about #IoT using JavaScript ... somewhere in the world an IoT/embedded developer ... dies !"[1].

On a serious note though - Does anyone know a mass manufactured product (based on a uController) that actually uses anything other than C/C++?

Rust is a strong contender too, surprised to not see it mentioned here. See an older discussion about Rust on ARM Cortex M[2]

1. https://twitter.com/ppatierno/status/894575063562936321 2. https://news.ycombinator.com/item?id=14071282

"On a serious note though - Does anyone know a mass manufactured product (based on a uController) that actually uses anything other than C/C++?"

None that I know of, but ESP8266 and similar MCUs are so widespread that probably there are lots of products using say nodemcu (ESP+Lua scripting) under the hood. http://nodemcu.com/index_en.html

Wifimcu is a similar product but uses a STM32F4 MCU. http://www.wifimcu.com/

I would personally love to see more use of Nim in this field; it just seem the right tool for the job for being easy to learn, small, fast and powerful.

Does the world need another open source operating system for the internet of things? I wonder if creating a new one was really necessary or if they could have built on top of one that already exists.

While I can't say I know intimately all the problems that need to be solved for IoT to responsibly reach mass consumption, but I'm pretty sure having an operating system wasn't the problem. Maybe this is just an enterprise cash grab?

It's definitely not a cash grab as the project is open source. There are many problems in this space that cannot be served using current solution, especially in environments that are super resource constrained. For example, this is made to run on a very small footprint of RAM, even smaller than what an embedded Linux distro would use.

Written in C so we can continue enjoying IoT devices being exploited by buffer overflows.

If I wanted to make something that (say) reports sensor readings over MQTT to AWS IoT, what firmware options are there? NodeMCU looked great (Lua!) but doesn't seem to support X509 client certificates (which AWS needs). There's Arduino, Mongoose, Micropython - any others? What's the best way to go?

It's sad that security isn't one of the homepage sell points of this OS. It feels like IoT is severly in need of serious "security by design". OS level would be a good start.

Security is actually one of the most important pieces of this puzzle and the team is one of the team's top priorities. Agreed it would be good to talk more about that on the homepage and everything that is being done in that respect. Mongoose is actually one of the first embedded platforms that support AWS IOT and X509 across multiple architectures

I fail to see how when C is part of the tooling.

Unfortunately the documentation is lacking and mJS (especially the ffi) is nowehere near production ready

Why don't more people use FreeRTOS? I always find it to be a nice way to coordinate all the tasks you need to run in an embedded system, without having to manage a huge kernel like Linux. It's also free so there's that...

This is based off of freertos

Is it? I looked all over the site and don't see any mentions of "FreeRTOS", "RTOS", "real time", "tasks", or anything else that would indicate it's based off of FreeRTOS.

Okay, so lots of comments on here and most of them are just plain wrong, FUD or stem from simple misunderstanding. Also, lots of people not groking the value proposition. Let me take a crack at clarifying some key points.

So first off, the project is GPLv2 whether you use it for commercial or non-commercial use. The team's first language is not English, they are actually Russian and based out of Ireland, so there is bound to be some confusion. What they were basically trying to say with that, is if you need the extra features and the backend, etc. Those are not GPLv2 but the project itself is--no matter how you use it--is. I mentioned it to them team and they already corrected the site.

Second, the value proposition behind this is tremendous. Remember the days before Unix and DOS/Windows ran on every machine in the world? Every machine had its own design, its own arch/cpu, its own OS, and its own interfaces. Computing was cool, but each machine was really an island. If you wanted to run your code on another machine then you had to port it over. Then Unix and CP/M-80/DOS came along and you could write something on one machine and it ran (almost) on anything with the same OS. Thats the name of the game here. This is groundbreaking for embedded/IOT development.

Real embedded development is hard enough as it is. If you're doing a one off project for something in your home, then its pretty straightforward. Now try and take that to a mass production-scale product and the level of complexity is increased 50x.

Imagine trying to bring a product to market, you need to pick a hardware platform/MCU to build with. Now imagine your suppliers hit a chip shortage and you can't use that chip, what do you? Sit back and wait for 6 months? What Mongoose OS allows you to do is write your code once and run it on multiple embedded platforms, you would just select another MCU, maybe make some minor modification to the pinouts, flash the firmware and BAM, you are back in business. Not to mention the fact that you have standard interfaces across all devices, MCUs, etc. It just makes development so much simpler.

Not only that, but you now have to manage potentially hundreds of thousands of devices (or millions if your product is really successful). What do you? How do you handle firmware updates? How do you track status of all those devices? How do you do customer support without a debug interface, well the enterprise offering (or something like AWS IOT) will help you manage that process and make your life a whole lot easier.

Now on the topic of why mJS vs. Python and a mix of C. You have to understand that embedded development is often EXTREMELY resource constrained. mJS fits into ~25K of flash space and less than 1K of RAM. This is awesome. It affords you the smallest possible functionality with the greatest possible flexibility. Write your logic in js and then call C for anything more critical/performance.

I asked one of the team members and basically what he said was (I paraphrase) that mixing C with a scripting language is a pretty production ready solution. Obviously its preferable to write the critical pieces in C and then the higher level logic in the higher level language. It would be ideal if you could have type safety and compile-time checks in the high-level language. The ideal language to write logic in would be Go, and Go 2 promises to have a smaller runtime/footprint so hopefully one day that will be a possibility.

In terms of everyone else talking about how the project is positioning itself, well let's just say that marketing is a work in progress ;)

> mJS fits into ~25K of flash space and less than 1K of RAM. This is awesome. It affords you the smallest possible functionality with the greatest possible flexibility.

I agree, but having said that, I have been trying to use Mongoose on the CC3200 and it is very difficult with Mongoose and mJS. Mongoose with mJS occupies upwards of 225K of flash, and the CC3200 only has 256KB of RAM (and the program must be loaded into RAM to execute). Plus I believe you lose another 16K to the Mongoose bootloader.

But this is more of a problem with the CC3200, admittedly; 256KB of RAM isn't great for an internet-connected device.

yes the cc3200 is a difficult platform to deal with, but one that is very popular due to the proliferation of the boards, the excellent battery life capabilities and the number of inbuilt sensors. The support for it isn't totally baked yet, at last as far as my last go-round with it, but it is being actively worked on.

look, it is shocking how you run covering the holes forgetting about security, who needs automatic device update if it can be hacked by a child??? In most cases, like the door bell, a RTOS is not only unnecessary but also risky less reliable and unefficient!!! Use an unhackable ATmega without the neeed of any OS instead

I hadn't covered security because at the time, it wasn't a major point of comment in the discussions. However, now that several people brought it up, it's useful to discuss.

I'll refer you to this page on the site, https://mongoose-os.com/docs/overview/security.html. It'll give you a pretty good overview of where the teams head is at. Mongoose is using ARM mbedTLS with a few patches to optimize for small memory constraints. Theres support for quite a few of the most common crypto chips which are used. All the supported cloud platforms (AWS, GCP and Adafruit I/O) as well as the mqtt support and local http/ws support all have the options to turn enable tls. The greatest think, imho is that its possible to fully encrypt the flash on the espressif chips. For those who don't know, those chips are pretty prolific in IoT and AFAIK mongoose is the only platform (aside from the Espressif SDK itself) which can do that. So pretty keen on security.

Your point about automatic device update being hacked is just FUD. There are can be multiple attack vectors on any given device, and thats why great security doesn't just happen, it has to be a pervasive part of the underlying philosophy of the platform. All the sound bases are kind of covered here, encryption on almost every level, from the application level to the transport level to the flash itself.

If mongoose plus espressif hardware are pretty keen on security I am Batman and Russian winter of IOT is not coming.

Interesting, I'll have to look into it when I build some prototype (just a personal hobby-type of project) with my ESP8266.

"Better. Cheaper^. Faster"

^ Contact us for pricing