 Okay, let's get started. So this session is about JavaScript on Sefir. My name is Sakari Poussa. I work for Intel. I'm part of the web platform team there, which mission is to enable JavaScript on various platforms, including IoT, and now finally on Sefir. There's a lot of topics here today which I want to cover. First a little bit about the why we want to run JavaScript on these MCU-class devices. Then a little bit about the architecture, how we've done it, and then more specifically how it's done on the Arduino 101. We have other boards as well, but that's where we started. Then how everything comes together in our build system. A couple of words about the security and the memory, because those are the questions that usually comes up with the JavaScript on these type of devices. Then we talk about the APIs, what we have now, what the planning of adding. Then I'll show something, what we've done also is a browser-based IDE, so you can use that to upload your JavaScript code on the board. Hopefully I have a demo, but hopefully it'll work, so it's a bit shaky, so that's a disclaimer, but we'll see. Then the open-source project itself, and hopefully we can cover all of those topics in the next 50 minutes. This is, as I mentioned, part of the web platform team at Intel. This is our mission, meaning that you can use JavaScript for everything. You can write your cloud applications with nodes, you can do your client mobile applications with the different frameworks there using HTML and JavaScript. The gateway functionality headless or headaches can be done with the node or with the crosswalk runtime, for example, we have. But really this presentation is about the very smallest devices, the things, and especially on Sefir. The JavaScript runtime for Sefir OS, that's the project name, and there's a couple of highlights here, what it is and why we're doing that. The big reason is that there's a huge JavaScript web developer community out there and we want to have a smooth path for those to come to the IoT and be able to use the Sefir board. On Linux, the Node.js story is pretty strong already, so we kind of want to offer the same language and tools for the, on Sefir. Another benefit of JavaScript is that the development cycle is pretty fast. You don't have any compilations of flashing, just copy the JavaScript files over and run it, especially on these embedded boards where you need to have a lot of, you know, setting up the compilers and development environments. What we hope also to have is really easy to use and good tools. One of them, I'll show you the browser IDE and later on, including the debugging and all the modern software technologies there. Our runtime is based on the JavaScript that Samsung presented earlier this week. So what we have done is to build an API layer on top of that. I'll show you a little bit more details later on. What we try to do is for those APIs is to not to invent anything new, but based on those kind of well-known JavaScript APIs where the Node.js is kind of the de facto standard there. The long-term goal is the JavaScript application portability between the MCU and the MPU platform, so you'll be able to take a Node.js program and run it on Sephir. There's a lot of details where it won't work, but in principle, that should be possible. Right now, we support the Arduino 101 boards, which is based on the Intel query, and then the freedom board, which is pretty popular on board for the NXP. So that's the start. The plan is to support, follow the Sephir OS support board. The why part, why we're doing that, part of that was already mentioned in the earlier slides, but really the address, the big JavaScript community, having the cross-OS APIs so you can have your single-scale set, the team can just do JavaScript and they can do end-to-end solutions. Sharing code between these two systems, or actually all the systems. Another one is that we can run this JavaScript runtime also on the Linux, actually on the Mac as well. So you can do a lot of developments on top of this runtime. You can start with Node, you can move to this JavaScript runtime on Sephir, continue on Linux or Mac, and then finally move to the target. That should give you plenty of options to how do you do your development. Okay, so another benefit which I touched was the development flow. On a native side, as most of you should know, the cycle is really that you edit your code, you compile it, you link it, and everything is fine. You reboot your device, this is the cycle on the Arduino 101. On some other boards it might be a little bit, you might say one or two steps, but still the principle is the same. But then you reboot, then you flash your image, then you reboot again, and you run it, and then if something goes wrong, you repeat the cycle. Whereas on the JavaScript side, the cycle is simpler, you edit your code, you copy that to the target, you run it, and that's it. So the cycle is shorter and faster. This is then highlighting the how part. So what are the, you know, how we've done it? There's an architecture slide on the next page. So really the Node.js is way too big for the MCU devices. The V8, the engine in the Node itself takes like 10 meg of RAM. So that's clearly not a viable solution for MCU where you have, you know, hundreds of kilobytes of memory. But Node.js has proven that there is a good programming model for JavaScript on these type of environments, MN-driven environment. So that's what we kind of put the baseline that, okay, we would like to have something like Node.js, but for smaller devices. So earlier this year we studied the proof of concept. We took the jerry skip. We had a couple of other runtimes, duct tape. We evaluated those as well. Decided to go with the jerry skip and then took the Arduino 101 board as the, you know, target and implemented a few APIs like timers or events actually based on the Node.js, BLE API, then the PIN APIs and realized that hey this is possible. We can run a fairly complex application on the Arduino 101 which has 80K of RAM. And the only kind of a tweak we needed to do there was the ROM space. By default this has 144K flash available for the x86 side. So we needed more. So we increased the size to 256. But with that set up, we haven't been able to do everything needed. So really the target state is to have the same jerry skip APIs on the Linux on the Zephyr side. And that should enable the application portability. So here's the high level architecture. So on the right hand side you have, you know, whatever MCU, the board you have. We have the Zephyr unmodified. We don't need any patching there. Same applies to the jerry skip. The jerry skip natively upstream builds for Zephyr. We are using that unmodified. Then really the value add is the JavaScript API layer which exposes the JavaScript APIs to the JavaScript application on top. Then on the left hand side you have on the bottom the integration. Right now we are separate repo in a GitHub. I'll show you in the second. And where the repository is. We open-sourced that earlier this week so it's accessible to anybody. And the make system which I'll show in the next slide will pull in all these dependencies together. So the way you start using your JavaScript runtime for Zephyr is that you clone the repo and then you type make. This is the oversimplification. There's some shell setup environment, set up variables pointing to proper places. But in principle, once you've done your shell environment variables and save that to a file, this is what you need. And the make has a lot of different options where you can start tuning things. But what the build is doing, it's fetching the Zephyr.js from the Zephyr Git repo. Same goes with the JerrySkips. It then gets the API layer, which is this repo. And then finally, your JavaScript application. There's a command line option to point to your JavaScript application what you want to build. And then it's building everything and out comes the Zephyr binary. And then whatever flashing mechanism you use, whether you use the flashing on some of the boards, you can do something else. But anyway, the end result is then flashed to the MCU or the Zephyr boards. And once it boots, it runs the JavaScript application you've put in there. So in a nutshell, this is the workflow. I'll show you. We have kind of two different modes. We have the production mode, which is this one. Then we have another mode, which is called developer mode, where you only build the runtime. So you leave the JavaScript application out. So you just have a runtime. And then with the command line tools or with the browser, you can copy over the JavaScript file and run that. So that's kind of a more developer friendly. But if you want to put this one on production or to some demo, both you want to have this production type of environment where the JavaScript application is embedded into your image. So you don't need to do anything. You just boot it up and it starts running. So this is then a little bit more specifics on the I do in a one-on-one port, because the way the board is set up, it actually has two... Well, actually it has three cores. The third one is the Bluetooth one, but I'm going to show you that one. So you have the x86 core there, the curry, and then you have the arc. And the arc has access to the... It's called a sensor core. So it has access to all the IO pins and things like that. So we don't want to expose that complexity to the JavaScript side. So we are hiding that by offering a JavaScript runtime support image on the arc. And then it has an IPC to the actual runtime, the JavaScript runtime running on the x86. So when you do a GPIO call, for example, from your JavaScript application, you don't know that it's actually going to be executed on the arc side, the runtime and the support image takes care of all the IPC behind the scenes. On some other boards, this is not needed if you have a single core, but the JavaScript application is the same. So that's kind of the portability aspect of it. Okay, so then a couple of words about the security, because when people hear JavaScript on the IoT, they obviously think about browsers and all the exploits you have there. And so how we address the security aspects of this one, at this point, is that, as I said, we have the production mode and the developer mode. The developer mode is also called the insecure mode. So you may call the production mode as a secure mode. But anyway, during the build time in the production mode, the JavaScript source code is converted to a C string, which is embedded to the Sefer image. So it is embedded to the image. It's not sitting on any file system or anywhere. We, on purpose, disabled the eval function. And then the developer can enable the developer mode with the special make environment variable like dev equals a shell. Then during runtime, we only the embedded JavaScript application, which is built into the image, only that one is executed. We don't do, right now, there's no way of doing actually any, you know, ACTP request to web pages. But even if there would be in the future, you won't be able to code your website and then download the JavaScript piece of code and execute that. So that's not possible. In the browsers, that's the default behavior, unless you disable JavaScript, which people don't do. And that's where the most of the exploits come in. And so that's one of the protection mechanisms. Then on the developer mode, all the beds are off. You know, you copy whatever file there and it will get executed. Then on the memory side, the engine itself, when it boots up, without running any scripts, the RAM memory consumption is about 5K. So it's not much. And then really the memory consumption of the application, it really depends on the application. I mean, you know, if you do Hello World, it's 5K. But if you do, you know, more complex, the memory consumption increases. Just for the reference, we have a demo in our booth. Well, it's a software project booth. A demo which is written entirely in JavaScript. I'll show you the demo details in a second. But basically it contains BLE API. It's doing the Google's physical web advertising. It has a BLE GAT service built-in, which contains two characteristics, temperature and LED control. And we have the BWM analog APIs. We have an I2C LCD there. And this is 200 lines of JavaScript codes. And this can fit into the Arduino 101 to the ADK of RAM. And we are not actually using all of it. So there's still quite a lot of space available. So as I said, if you haven't seen the demo, here's the highlight of the demo. So basically you have your JavaScript application running on the Arduino 101. It has the BLE, I2C analog. And the way it works is that via the BLE, it's advertising this physical web URL. So basically whether it's a physical web or it's called Eddystone nowadays, is that you advertise an URL. You have your Android phone. It'll show up in the notification area. And when you click it, it'll launch the URL via the Chrome browser. So the URL is pointing to a web application. The browser on the phone loads that. And then it's using a web Bluetooth API on the browser. So it's just a web page with the new API from the W3C. With that, you connect back to the Arduino 101 to the GAP service. And then you can start reading the temperature changing the color of the RGB and all that. And on the Arduino 101, the application is all JavaScript. Well, actually the whole demo is based on web technologies. So that's kind of the end-to-end story here. Okay, so then as I mentioned, we have a proof of concept prototype of the browser IDE. And what that means is that it requires the developer mode on the JavaScript runtime for Sefir. So you need to build the image for Sefir in this mode. And then flash that to the Arduino 101 boards. That's the only one we have tested it, but it should work on other boards as well. And what we don't have yet is a new, again, W3C standard called WebUSB. And what that means is that it requires both sides. It requires the API to be available on the browser. Chrome already has it behind a flag. And then on the Arduino, well, on the board, you need to implement a WebUSB compatible interface. So it's different from any other available USB interface descriptors or whatever they call it. So we are working on that one. So once you have that, all you need is your laptop. And your USB cable and your board. And I'll try to demonstrate this one now that you'll have your browser, then your device with this setup. I'm cheating a little bit because we don't have the WebUSB available now. I'm running a small node shim layer here on the host PC, which is talking to the browser and then talking serial over to the board. But that should be unnecessary once we have the WebUSB. And with that, once we have this one working, you can build command line tools. You can do third-party IDE integration pretty easily directly from the browser or with some other mechanisms. So let's see. So this is the demo part that I give no guarantees. But so let's see. So this is the Arnoono one-on-one board running the JavaScript runtime. And it has an LED and a button. The target is to run a JavaScript application which blends the LED when I press the button. Nothing very exciting other than the workflow. So this is the node server that I need to run there because we don't have that yet. The WebUSB. The code I want to run is I'll take that from the Sefirjs website or the GitHub. We have a lot of samples here. We have re-implemented some of the Arduino one-on-one samples. So this button sample here contains a few lines of JavaScript code. So I'll take that along with the browser with the IDE. We also have a small shell here. So you can type some commands here which will be executed on the boards. And then the results will be back, a code back here. So you can run programs. You have some basic file system commands and things like that. So this is pretty much a prototype right now. But the really one I wanted to show is that here's the editor. So you paste your code here. This is based on the Node module from Microsoft that they use in the Visual Studio called Monaco Editor. So you just plug it into your website and it's a pretty powerful editor just like that. So what I want to do now is upload the code to the board. And now the JavaScript application should be running. And yes, I can link the LED with the button. Great. It worked. I bet you've seen quite a lot of LED blinking doing these IoT conferences. But that's not the point. The point is that you can do your development on the browser, hit the upload button, and then it runs. There's no flashing, no recompiling, no nothing. So that's kind of the IDE part. And as I said, it requires a little bit more work on both sides. But really the web USB is the key enabling factor. We can also use the web Bluetooth, which is part of our demo upstairs. So then you don't need any cabling to make this one happen again. OK. So that was the demo. Then the API kind of a comparison between the Node.js, which runs on the Mac and Linux and Windows. It has a pretty extensive set of APIs, I think like 35 to 40, HTTP, sockets, cryptos, file systems. It's a pretty good coverage. And then so we have implemented two of those right now. And these are not by no means complete one-to-one mapping to the Node APIs. But there's events, especially it's pretty complete. The buffer is missing a few methods and tweaks. But then in the future we plan to add more where it makes sense. And then in the Node environment where something is missing from the core, the NPM kicks in and people can write those NPM modules which extend the APIs on the Node. So what we have done is we've taken the kind of the best known, most widely used, most stable NPM packets for certain APIs like the BLE. In the Node world there might be 10 or more packages for the same API. So it's sometimes difficult to choose the right one. But anyway, we are using the Bleno API. So basically what you should be able to do is to take your BLE code written on top of Bleno and run that on the Aluno or on Sefir. The same with the GPIO, the Pins and Buses API. The Johnny 5 is a very popular framework in the Node world. We are following that API paradigm as much as we can. On the OCF side, we've done a IOTVD Node, NPN packets. We've been doing that over a year. And it has a pretty stable, good API. It's been used in a few other projects. So we have implemented the same API for the Sefir JavaScript runtime. So that's pretty much where we are. There's a lot of new APIs we want to do like the Co-App, MQTT. Another interesting area is the W3C sensors. So W3C is kind of entering the IOT world by doing APIs which doesn't require the browser environments, more specifically the DOM. So all the APIs so far has been that you have a navigator dot or document. You know, it's the DOM binding there. But these sensor APIs are browser independent and they have been designed with the spirit that they should be able to implement on the Node.js as well. So that's what we are planning of doing as well. Another interesting API is the HTTP. But that requires a little bit more plumbing on the Sefir site, namely the TCP, the HTTP parser, and then some HTTP API there. The rough subject to change roadmap is that for this second half of the year we will have a subset of Node APIs, the OCF, BLE. Even though they are there, they are not complete, so we need to finish those. Have the PIN and buses APIs finished. Get this copy and run feature completed. The way, for example, it works now is that you can... Well, it's a prototype. Let's put it that way. It worked on a demo, but we need to productise that and make it rock solid. We already have the freedom board support, but that's very basic and enhanced that. And then moving forward to next year and more Node.js APIs, power and battery management APIs, as I said, co-app, MQTT, NFC, security and crypto APIs, the sensors. And then add the tooling like remote debugging if the Jerry script is offering that to us. So that's part of the tooling roadmap. And as I said, this is an open source project. We just open it. Here's the URL. It's under the 01 org organization in the GitHub. And we are totally open for contributions, participations, comments, feedback, anything. Actually, we just got yesterday the first external patch from Linaro. We were happily merging that to the project, so that's all good. Having said that, it's a early start alpha quality type of thing, but you can build already. As I said, if you go to our booth, it's a stable demo. We have been running that like tens and tens of times during this show. We have a lot of sample codes. One of those was the button. So if you buy one of these boards and the, for example, the group kits, just hook up the sensors, take one of the samples. It should run and you should have your board up and running very quickly. We also have the API documentation. So if you want to enhance the application, write your own. All the API documentation should be up to date matching the code. The readme should get you going. It may have some, you know, gaps there, but we'll improve that as we go. Okay, so as a summary, we have, are pretty confident that, you know, the JavaScript application development on Sephir, it's possible. It's usable, especially for the web developers who master JavaScript and lowers the barrier, the bar to get started on Sephir and these MCU boards. And, you know, it's open source. Please join. And this is the, really the first step and we'll keep investing and doing, improving this one. So hope to see you on the project and in the future events. Okay, that's all I had. I think I have a couple of minutes for questions if there's any. Okay, going one, two, no, one question. Okay, it's vague right now, but if you think about running this type of devices on a battery, I know that the Sephir has some power management mechanism in there. So what that means is that we want to make sure that the JavaScript engine won't ruin the power management. So if, otherwise, the Sephir board would go into sleep and the JavaScript application or the runtime keeps spinning there and keeping the system awake. So I don't know if we want to expose that to a, or is there a need to expose the API to the application so it gets some callbacks that, hey, you know, we are going on to sleep. I don't know how the power management on Sephir works. And the same for the battery that you should be able to get the battery level you have. So when you're running out of battery, the application should know that, hey, you know, I'm going out of business now. So that's kind of the high level vision. How we're going to do those in details, I don't know yet. That's next year, right? Eric, is this something like, yeah, we want to do that, but it's complicated and we'll do it someday? Well, is it like we're almost there? No, no, we are definitely not there. I mean, we started that like a couple months ago, but we needed to suspend the web because we couldn't find a suitable HTTP library which is small enough. And then the Sephir TCP stack was, how would I say, unusual to put it lightly. Well, okay, yeah, that's maybe a proper wording. Anyway, the new IP stack is coming. The TCP support there, once we get it, should be better. And then the HTTP library, it's, I think somebody mentioned yesterday that it's in the Sephir tree already or in some PR or Garrett. So that should be merged for the 1.6 release, which is due in a couple of weeks. So then we have those two roadblocks out of the way, but I'm hoping that the Sephir project itself will provide an HTTP C API that then we can do the bindings. So there's still one thin layer or layer missing. But personally, I feel that it would be a very good API, so it's top of my list, but if there's a missing thing, I cannot do much. Okay, anything else? Okay, thanks.