 So, welcome everybody. This is a session about SDK in the browser for CephirOS. I'm Sakare Poster from Intel. I work in the web technologies team there. And our mission is to enable web technologies in all the computing platforms. And today, we're going to talk the CephirOS and what we have done there. The agenda for this talk is, first, we talk about the problem we are solving here, and then one solution that's the core of the talk. I'll do a live demo. Let's see how that one goes. And then we'll talk about the founding blocks, how the solution is put together. It involves a couple of things. First, the JavaScript engine running on Cephir, and then a new standard called WebUSB, and then the browser application itself. And if you have any questions, please interrupt me at any time. So really, what's the problem we're trying to solve here? For an average developer, IoT might be walking the park. They know what they're doing. But especially for newcomers, students who are new to the area, starting a new IoT project can be a tedious task. You have all these boards and cables and sensors, and you really don't know where to start. And starting a new IoT project typically involves you need to set up your development environment. You need to have all the sorts of different cables, the correct ones, some sensors, documentation, sample codes. You might want to or need to update the BIOS and firmware and even your OS and all that. And the documentation, at best, it's all over the place. And maybe, outdated, then you don't know which one is true and which one is not. So the solution that we're going to talk about today is really a simple one. And so the idea is that this is all you need. So you need a board, obviously, which you're going to write your application. And then you would need a USB cable, in this case, and a web browser. That's it. And so I'm going to do a demo now. And so you get a sense what it is. And then I'll present the building blocks, how it actually works, assuming that it works well. I'm going to talk about that anyway. OK. So I have a Chrome browser here. I do know one-on-one board, the Cephir board. It's running Cephir OS. I'll talk about that, what's in there. But basically, it's a Cephir board. I have the USB cable. And I have a couple of sensors attached to that. But more about that later. So when I plug in the USB to my PC Mac, in this case, the board will boot. And you will get a notification there on the corner and says that, OK, web USB detected. And it's telling me a URL where to go. So I'll just click that. And it'll launch me the browser. As I said, I'll get to bottom of all these wonderful things later during the presentation. But what it does is that it'll take you to a web page, which in this case is our IDE or the SDK. It's just a web application. And so I'll hit the Get Started. It gives me the IDE. And I hit the Connect button. It tells me that, OK, there's a web USB device out there you want to connect. It says Paired because I have talked to this device previously. If it's a brand new, it just don't say that. Otherwise, the functionality is the same. I connect. So now I'm talking to the board. So this console there on the bottom, can you actually see it? Let's try to make it bigger. So you have there on the bottom, you have an interactive shell. You can type some basic commands so we have the file system there. You can eval JavaScript code there. And you can reboot. And there's all sorts of commands available. Then you have your editor. And you can start typing some code here. So like console, log, hello, ELC, OK? And when you hit the Upload button, it'll copy the file to the Safari board. It runs it there. And the console output, it's coming to the bottom of the page. I mean, this is brand new. So we need to clean up the console. So it's showing there some protocol commands. But you get the picture. So we can then try to do something to access these sensors. So we can say that, OK, I need some pins. And here comes the node require statement. So you can require modules. Right now, these modules are built in. And so you say, OK, it's Arduino 101 pins. And I'll try to access some of the sensors. I hooked to the GPIO. So I say GPIO. I need GPIO module. And at any time, you can test your code. You can upload that, see if there's any errors. And then you can write any JavaScript, like interval, set interval function. And you say, again, let's log something from the loop. And you run this one every second, something like this. OK? So it'll start executing that on the target device. If you want to access the hardware, I have a buzzer in the GPIO. So you open it, and you say, OK, the pin is, what is the pin? The buzzer is in pin number two, right? No, that's the button. The buzzer is on the pin four. So then you say, pins IO4, direction is out. OK? And let's declare a alarm, which is false. And then in the loop, you say, buzzer, write, alarm. Let's try this one. Nothing should happen. Error. OK, where's the error? Thank you. Let's try it again. OK? So now if we change the alarm to toggle it here, you should hear something. OK. So it's working. Let's kill that one. I was told not to do any LED, so it was an LED demo. But you get the picture. So I mean, you can write code here, you can download it to the target device, and you can execute it there. I'll talk about the APIs we have, so you can do much more than the GPIOs and the basic stuff. I can? Yes. Stop. Good. It's good to have the experts on the audience. All right, so that was the demo. So how does it work? So is this one working? No. Yes, OK, it's better. So the way it works is that on the left-hand side, you have the Sefir, then you have the JavaScript runtime for Sefir, which is on top of the JerrySkip. That's an open source project that we have been working on about a year now. The Sefir OS itself has now a WebUSB driver, which we actually contributed there as well. And then we have a part of the JavaScript runtime, a module called AShell. And what this AShell is doing, among other things, is that it's telling the WebUSB that, OK, these are the URLs that I support. And then when you connect the USB cable, the Chrome browser will ask that, OK, this is a WebUSB device. What are the URLs you want to go to? And that's where it shows the dialog on the top-hand right corner. And you click that, it'll get to the internet where the application lives. It downloads the application to your Chrome browser, and you have the IDE there. And this application, the Web app, doesn't need anything from the cloud. It's just a static, well, not a static, but standalone Web application. So you can run it even offline. We are planning on adding the offline support there, so you don't even need the internet connection in the future if you have launched the application just once. So from there, you have the Connect button there. So you hit that, it'll connect back to the device, and then you have your data path ready. It's a serial connection on top of a USB. So you can send, receive anything you want. You build on top of that. So that's the, in a nutshell, the operation. Any questions on this one? OK. So comparing the development flow on most embedded systems, this is true at least for Sephir, and for the Arduino 101. The ARM boards work a little bit differently. But the cycle, if you're doing native development, is that you edit your codes, you compile it, you link it, assuming that all your cross-compiling environment is correct. You reboot the device, you flash it, you reboot it again, and you run your codes and see what happens. With the JavaScript development, the cycle is much faster. You just edit your codes, you copy, and you run it. And with these ingredients, the IDE, the web USB, and the JavaScript runtime for Sephir, this is possible now. Then next, we'll talk about one of the ingredients a little bit more detailed, which is the JavaScript runtime for Sephir OS. By the way, this is the official beautiful, beautiful name for our project. Some people call it Sephir JS, but that's the way it is. So the purpose of that project is to enable the JavaScript application development on Sephir OS and to address the big, big JavaScript developer community, which already been building websites and mobile applications for decades so they can use their familiar language, familiar tools also in the IoT. And as I demonstrated, the development cycle, it's fast, so there's no flashing. Just copy the files over. It is based on the Samsung open source project called GeriSkipped. That's the engine. And an API layer, which is the JavaScript runtime. We try to mimic the well-known Node.js APIs. And when there's not available that type of API, we need to invent something our own. And that's always a struggle. So already today, we can see some application portability so we can run the same codes on Linux, on top of Node.js, and on top of Sephir with this JavaScript runtime. And right now, the run time supports two boards, the Arduino 101, which is the x86-based board, and the Freedom board, which is an R-based. We understand that we need to support more boards. And most of the Sephir boards should have, should run this runtime. But it's all in the details to support every single kind of the pins and the external peripherals there. So the way the architecture, you know, high level, it was already in the opening picture. But we have unmodified Sephir, so we don't touch that. We just consume it. Same goes with the GeriSkipped. We're just using it. There's no internal batches on top of that. We have actually contributed some codes there to make our life easier. But they are just the upstream versions of those. And then comes the JavaScript runtime for Sephir, which contains there on the left-hand side all the API bindings, which actually allows you to access the hardware, Bluetooth, network, whatever is available on the device. We have pretty nice build tools so we can just type make and it'll produce you the image. And we have a lot of sample codes, demo applications. The APIs that we support are all documented. And yeah, it's open source. More about that later. We have two modes in runtime. So we have a runtime mode or a production mode, which takes your JavaScript applications and converts that to a C string and embeds that to the final Sephir image. And then you flash that image to your device and it then picks up the JavaScript application and starts executing that. And that's the only application you're going to run on that configuration. Then we have the developer mode, which is what you saw with the browser IDE. And that's where we can change the JavaScript application. So you can just copy over the application and replace that over and over and over again. And so the way you distinguish these two things is that in the runtime mode, you just type make and it'll take everything. It takes your JavaScript application, the runtime, the JavaScript engine, Sephir OS, builds everything and out comes the binary. And then you flash it back to the device. And then if you say these magic words, dev equals a shell, it'll leave the JavaScript application out. It adds other things like the web USB, the file system, and the shell so you can do this development mode. And well, that's basically a summary. Summary of how it works. The JavaScript APIs that we currently support are listed here. I think I have at least the material of them. So there on the middle, we have the Sephir OS APIs. And then on the right-hand side, we have the corresponding Node.js APIs. As I said in the beginning, we are mimicking the Node.js APIs as much as we can. So the events, timers, console logging, that's available now. That's part of the core APIs in the Node. Same with the buffer. And then we have a BLE API so you can do BLE applications. You can do Google's physical web type of application. You can define GAT profiles all in the JavaScript. So that's pretty comprehensive API. And we modeled that according to the well-known or widely used Bleno NPM package. Then we have all the hardware APIs supported. I believe the SPIs still not supported, but all the others are. And there, the API design is kind of problematic since there's no well-known standard there. And that's where we try to go with the Johnny 5 type of APIs. That's the plan for the future. They are not today like that, but that's where we're heading. We also implemented the OCF API that Image, who was talking about earlier today, in the keynote. So you can write these OCF-compliant, well, not compliant, but at least OCF application sensors with JavaScript with our APIs. Then we have a couple of W3C APIs, namely sensors and performance APIs. Because as I said in the beginning, we are part of the web platform team at Intel, which mission is to enable web developers or developers to have harmonized APIs across all computing platforms. And these W3C APIs, they are in the browser API. So all the application that runs in your browser are using these W3C APIs. The latest API that we got from Paul here in the audience is the UDP, which is according to the Node.js UDP Core API. We are pretty close in the file system API, the next one coming TCP, HTTP, so you will be able to run actually HTTP server in your server device. Co-app, MQTT has been discussed, but no actions there yet. OK, so that's the JavaScript runtime. That's the piece running on the Sefi board. So then a couple of sites about the web USB, somebody already asked about that. So why it matters? USB is everywhere, so it is the de facto standard for connecting devices, it's fast, reliable, and inexpensive, and it can power your device, unlike, for example, Bluetooth. And there's a couple of advantages over Bluetooth and other wireless technologies, and I'm not going to go over those details, but one thing to point out here is that we can make this happen with the web Bluetooth as well, which is yet another API in the browser. So that's potential future enhancement, so you can run the IDE over Bluetooth to your Sefi device. So what the web USB is, it's a W3C standard. Well, it's not a standard yet, it's actually, I'll take that back, the way the W3C standardization work is that it's a long process, sometimes even too long if you ask, well, maybe me or somebody else as well. Anyway, Google, Mozilla, they have been heavily pushing this web USB standard, and it's in the fairly early phase right now, it's in Google's terms, it's in the origin trial phase, which means that they are planning of enabling it by default. And we are, this IDE, for example, is participating that origin trial, so you don't need to do any tweaking in your Chrome settings, it just works. And the way it works is that, I don't know, the USB protocol that well, but there are these headers and descriptors what you exchange between the handshake, and the web USB just defines few URLs, or few new fields there where you pass these URLs and things like that. And there's a whole bunch of documentation and material available about the web USB. Security, of course, is one of the big concerns, and one of the, couple of the main topics in the security area of the web USB is that the URL that the device is advertising to the browser it's only gonna talk to that site, and it needs to be HTTPS, and only scripts from that site can access back to the device. That's a good question. This is actually, Kenneth provided me this material for the web USB details. Will become, but are recommended and required for... Yeah, I think the way... Yeah, it's a good question. I cannot answer that right now. Sorry. And it works only in Chrome right now. Chrome is the only browser who has implemented the web USB, so that obviously a limitation. But Chrome is available on Linux, Mac and Windows, and it works on all of those platforms. Did I? I think you saw Safari browser in my Mac. That must have been... Yeah, I mean, you cannot do that with Safari, because Safari doesn't have the web USB API. So that is... Well, let's go to the issues. So it's new. The web USB is new, so it doesn't come without issues. So on Linux, most of the distros ship with the packets called Modem Manager, and it's hijacking these USB CDC devices, which this web USB device is claiming to be, and it is that CDC device. So you need to explicitly kill it. The Modem Manager is pretty aggressive in acquiring those devices. Unless you blacklist your vendor and product ID in the Modem Manager, so I think we want to be on that blacklist. On Windows, the earlier versions, before 10, it needed some custom driver. You needed to download somewhere. It didn't work out of the box. Now it works, but Google is still having quite a bit of problems on the Chrome and Windows, but that should be getting better. On Mac, on the other hand, I haven't seen any major issues. Okay, so then the browser application itself, the one that you see in the browser, so this one, this is a fairly, a bit more updated picture, and what we are planning of doing is actually quite a few things. So you saw the editor. You saw the console. On the right-hand side, we're going to integrate a module called BoardViewer, where you have an interactive SVG image of the boards that you're connected to, so you can hover your mouse over. You see what pin is what. You can see a documentation of that. In the future, we might want to enable a feature where you can just drag a pin there to the coding window. You can use the code to initialize that, so it'll come up, drag and drop exercise to write code. And then based on, you know, what board you are connected to, it'll automatically load the proper board. That type of plans, but we are not there yet. So the application itself, it's a browser-only web app, so there's no server that you need to talk to. It's just a standalone app. The code editor itself, it's a editor called Monaco. Monaco, however you pronounce that. It's from Microsoft. Microsoft is using that in their Visual Studio code, the open source version of the Visual Studio. It's a pretty robust, full-featured editor. The console that you saw there, that's another external component from Google. So we haven't actually invented a whole lot of things here because those are available already. The board viewer that I showed, that's a new, that's an Intel code base. Then obviously we have the Web USB for device communication. Oh, and actually one thing that I forgot to mention is that we have these multiple tabs. So you can see here that they're on the top. You cannot really see it, but this is a tab. And with this green button you can get another tab and you can connect that to another USB device. So if you're developing a client-server type of application, you can write server code in one window, client code in the other one, push the code to both boards and see how things go. We also have a GitHub integration, so you can pull in your code directly from the GitHub. And it's done with using an Angular 2 framework for those who understand or are interested in front-end frameworks. The IDE itself is also open-sourced. We open-sourced that I think a week ago, so all the code for the browser application is available. And the live site where the actual browser is running on top of a web server, it's using the GitHub IO pages. So you can just directly go there to that site and you'll get the browser or the IDE. So those were the three major ingredients for the IDE. So then I think I have like 10 minutes, so I'll just briefly go over the next steps in summary and then I have time for Q&A. But you have a question there? Yes. Well, okay, so Node.js is not part of this project. But you need it. No, no, no, no. And then you need a web server which is serving the web pages and the JavaScript scripts and CSS files for the browser. But that's it. The thing that I meant when I said that it doesn't need a server means that the web application, the IDE, doesn't talk to a build server or any other service in order to perform its task. Like if you're familiar with the ARM embed, it's a browser application, but it's totally relying on the back end. So it's sending your code to the server which is building it and it's giving you back the binary. So there's a strong connection between the front page you see and the back end. What I'm saying here is that we have no back end. It's just the web page. Yeah, yeah, I agree. I think it's cool and we want to keep it cool so we have no plans of introducing any server, at least the mandatory server requirements. Okay, this presentation is available already online. GitHub.com, zero one org, sefirjs-ide, that's where the code lives. And then you mangle it to the way the GitHub does the IO pages. It gives you this type of URL where the live site is. Did you get it? Okay. Okay, so as I said, this is a pretty new project. There's a lot of work to be done. And so what we would like to do is to have, first of all, the board viewer available, have more boards there. Right now it's just the Arduino 101. The communication between the panels that I talked. Then it would be good to have the proper API documentation to the Monaco editor, meaning proper the sefirjs, our runtime APIs. So when you type in, you know, GPIO, it'll give you a GPI dot, it'll give you all the functions that that object supports. Now it's just some, I don't know exactly what it is, but it's not very relevant. So then you don't actually, in that case, you need less and less the API documentation because the editor is giving you that. It would be easy to plug into other IDEs because on the device side it's just the USB and then the protocol on top of that. However, the protocol right now it's really ad hoc. We need to define a proper protocol, document it, so then any project can implement their own IDE on top of the web USB. It would be good if we can flash the device via the web USB. I don't know whether this is even possible, but so then people don't need to do the initial bootstrapping of the boards. One pretty big limitation right now is that because it's a browser application, you don't have access to the local file system. So, well, that's the way it is. There's ways around that, but we need to pick the correct solution for that one. The web USB itself, it's undergoing some changes. The current origin trial runs till end of March and then after that Google has already announced that they will, and the W3C working group has announced that they will revisit the API and most likely change that. One of the problems we have with the Arduino 101 is that the way we built the ACL is that since, okay, let me take that back. In the production mode, the way we built the runtime is that it analyses the JavaScript application and it only builds the modules that the application is using. So, if you're using Bluetooth, it'll bring in the separate Bluetooth module, but if you're not, it doesn't build it. In the ACL, on the other hand, we have no idea what the application is, so we need to build everything there and that's where we're running short on the ROM memory, which we have 256K or a little bit less than 300K at the moment. And this has been only tested with the Arduino 101. It would be good to test and fix that for other boards as well. And as I said, it's all open, so we're really looking for contributions and users and applications both on the runtime and the IDE. So, as a summary, the browser-based IDE, it's an easy-to-use, fast-to-get-started development environment. It should lower the entry barrier to start IoT projects and we think that it's a really perfect match for education, classrooms, hackathons, demos, where you don't have a lot of time, so you're kind of a time box. You have 45 minutes an hour to get things going and you don't want to waste time setting up your environment, so with this one, you can just get up and running in a couple of minutes. Okay, so I think I have five more minutes for questions. Yeah, it's a good question and I think JavaScript in the IoT will have this challenge for years to come. But there should be no reason for that. Yes, but then once you're done with your tinkering, you should switch to the so-called production mode and you said, okay, now it works, let's go to some trial, let's flash a couple hundred devices and that's where you bake in your application into the image and you just flash that. We have a hackathon tomorrow, Wednesday afternoon, which unfortunately is already full, but there we are kind of demonstrating and trying out these different workflows. The production mode, I mean these guys, they flashed, I think we have 35 boards and it took what, a couple of minutes, five, ten minutes to flash them all with the production image. So once you're done, you just keep copying it. Yeah, it's another good question. The vague answer, it depends, it depends on your application and we have been running demos where we have BLE, doing the physical web advertisement and then a GAT profile which is accessing a few centuries and we haven't hit a RAM limit with the Arduino 101 which contains 55k RAM. But once we start running, we have TCP and HTTP and we start running a web server there and somebody sends a big JSON blob or something, I'm sure we're going to run out of memory. So, I don't know. Yeah, yeah, yeah. I think the answer, the question was about RAM. Yeah, RAM. Yeah, but I don't know, I mean, what type of application do you need to run over the RAM limit? Yeah, Arduino 101 and so, yes. Yeah, we don't have the bindings yet but maybe later this year. Okay, anything else? All right, I think we're done. Thanks.