Embedded - 196: Software Server Thingybob

Episode Date: April 20, 2017

Aditi Hilbert (@HilbertAditi) spoke with us about MyNewt, an Apache-licensed RTOS and bootloader. MyNewt’s Apache page is mynewt.apache.org and the github repository is github.com/apache/incubator-mynewt-core. In the README.md, check out the section marked browsing which points to the file system, ble stack, and assorted other source code goodies you may want to read. The secure bootloader code is also in there but as it is also a cross-RTOS effort (with Linux’s Zephyr), you can find the MCUBoot repository at github.com/runtimeco/mcuboot Aditi works for Runtime.io (@runtime_io), a primary contributor to MyNewt. They work with companies who want to use MyNewt on their products. We talked about OIC (openconnectivity.org) and using UDP endpoints over BLE. Constrained http is actually called constrained application protocol: CoAP (coap.technology). We also mentioned MQTT, an older standard attempting to solve some of the same problems. The Apache license is one of the most permissive of open source licenses: choosealicense.com/licenses Assorted other links discussed in the show: Decoding the Heavens by Jo Marchant List of HTTP status codes (418 is the best) Last year’s tshirts, logo will be the same but the shirts will be slightly different for the tshirt campaign starting April 26, 2017.

Hello and welcome to Embedded. I'm Eliseo White here with Christopher White. Today we are going to talk about WebStuff. Wait, before you go, it will be Embedded WebStuff. We have Aditi Hilbert of Runtime.io to explain why we should be learning about what a web server really is and why we would want to run one on our device. Now, before we get started, our 200th episode is coming up. That means there will be a survey so we can learn more about you and what you like about us. Of course, if you fill out the survey, you may win something. And I have to admit that thing you may win is pretty darn cool. So if you are listening a few weeks behind or you have a time machine, skip to that show for more information, episode 200. I do have another notice for future you, and that is that we will be starting a t-shirt run next week on April 26th.

It will last two weeks, and if I have organized it all properly, you will be getting your t-shirt as soon as you hear the episode 200. Depends on shipping, of course. Your mileage may vary. Hi, Aditi. Welcome. Hello. Thank you for having me here. So could you introduce yourself like you would if you were on a panel at a technical conference? Sure. I'm the product manager at Runtime. I work on cloud-based solutions to manage and monitor devices. These are embedded devices, so-called IoT devices. I also work on Apache Minute OS, which is an open source project and the OS that powers the devices that we manage and monitor. Okay. We're going to be talking

a lot more about that Minute and all of the webness of it. It's Minute, not Minute. Right. It's M-Y-N-E-W-T. Like, I have a lizard, not like I have only a second to talk to you. It's minute. But it's supposed to be a play on words. Because it's supposed to be small. Yes.

All right. So before we actually talk more about that, I want to do a lightning round where we ask you short questions. We want short answers from you and if we are behaving properly we won't ask you why and how and all of the other details that everybody will want to know but they won't get to find out because we're all going to be on our best behavior okay all right favorite movie or book which you encountered for the first time in 2016? Decoding the Heavens by Joe Marchant. This was about the Antikythera Mechanism. Oh, cool.

It was really cool. Favorite animal? Pets. Amongst house animals, I love dogs. In the wild, I love all animals, but I love the meerkat. I think they're very funny. Yes. Preferred voltage? 3.3 volts. Were there any conferences last year you wish you could have attended? I would have liked to attend the ApacheCon

since I've been working on this open source project. But, you know, I will this year. It's coming up in May, so I'm looking forward to it. Do you have a favorite microprocessor? The Nordic

NRF52 is really cool. They've done lots of demos and stuff on it. I use that one, and52 is really cool. They've done lots of demos and stuff on it. I use that one. It is pretty cool. Have you ever touched a pangolin? No, I have not. Favorite web error code?

That one's so easy. There's only one right answer. Really? 418. Let her answer. I'm sorry. Go ahead. There's only one right answer. Really? 418. Let her answer. I'm sorry. Go ahead. It's 401.

I don't know that much. Okay. What's 418? I'm a teapot. All right. That is an official HTTP status code. 418. I'm a teapot.

Okay. All right. Well, really, if I was a teapot. Okay. All right. Well, really, if I was a teapot, I would be able to do more than that because, yeah, anyway. Web servers. When I think of web servers, I think of, gosh, I guess I think of Wikipedia or Google or even- Those are websites. Those are, yeah, those are... What is a web server? It's so embarrassing to have to ask this,

but really, what is a web server? I mean, that's a great, great question because we are using web servers all the time. So a web server, I mean, in the simplest form, it's hardware and software that serves up with web pages. It doesn't have to be web pages. It can be some information or data. And it serves it up over some known protocol.

In this case, usually it's HTTP or HTTPS. So I once built a Wi-Fi Internet of Things widget that we won't talk about what it did. But at some point for the user to be able to give me their Wi-Fi password and SSID, I had to serve a web page. I had to show a web page and they would connect to it and then they would type in their information and I would go back and then I could connect to the webpage with my device. But all I remember from that is that I would take this file that was HTML, shove it into my Spy Flash, and then at some point I would pull it out of my Spy Flash and the user would see it.

Yes. So if I understand what you said, really a web server is whatever the code was between Yes. Correct. And so it was part of my operating system and I don't even think I noticed what it was. I just said, go page and it went. Yes, it should be that simple. It should be? Yes. Okay, good.

And especially if you want to put it in an embedded system, it should be pretty simple. But an Apache web server is much bigger. It does a lot more stuff. Like I had to do manual translation between spaces and percent 20s. But an Apache web server would do a lot, lot, lot, lot, lot more than that, right? Right. So you are, I mean, you can go far with it, with how you present the data. Is it dynamic?

Is it static? How is it presented? Is it a form? Are you querying some database? So there is a lot of things that you could do. And as it gets more and more complicated, the web service becomes more and more complicated. You have to have interfaces that people understand, and so for that you have to have standards. And so, yeah, it could get pretty complicated. But we want to keep things simple in the embedded world.

And that's what you will hear later on. So you mentioned the Nordic NRF-52. But when I think of Internet of Things for web servers, I usually am more in line with the ESP8266 or the newer ESP32. Because those are 802.11 devices. They go on Wi-Fi instead of BLE. But they're so small. Could they support a web server like an Apache web server? I always think of those as huge.

Perhaps not an Apache web server, but definitely a web server of some sort. Oh, okay. Of some sort. Yeah. Yes, these are small processors, but people want to be able to communicate with them easily and just get some simple information from them. Yeah. Is my garage down or. Exactly. Is my fan on or, you know, is my light bright enough? Whatever. So. Okay. So when I look at Runtime's page, there's all,

there's a lot of information about Apache web servers in embedded systems. And I have to admit, I just read that and I was like, that doesn't seem like a good idea. But you're here to tell us why my initial hesitancy is not right. So tell me, correct me, because I'm wrong. I'm often wrong. I think it's just a slight misunderstanding because when people hear Apache and they see web server, they just put it together

and they think about the Apache server project. You know, the Apache server, the free server that everybody's using. It serves a path of all web traffic. It's huge, the free server that everybody's using. It serves up half of all web traffic. It's huge. Yes, exactly. It's huge.

But we are actually, we don't use the Apache web server or we are not trying to put an Apache web server in the embedded device. We are interested in Apache and we are interested in web server, but not the Apache web server. So what I mean is,

so I'm here to tell you what, how we are linked with Apache and how we are linked with the web server. Okay. Before that, what is Apache then? I mean, if it's not just the name of a software server thingy, Bob, you can tell I'm an embedded software engineer. I'm like cloud, blah, blah, blah, blah, cloud. But what is Apache? If you just say Apache. Foundation is a non-profit organization that supports lots of open source projects, I think over 300. Apache Web Server was one of those projects. It was hugely successful, as you know,

but it has supported other open source projects as well. So we are part of the Apache Software Foundation. In fact, my newt, our project is the first embedded project that they're involved in, so we are very excited about that. There's also a license associated with Apache, too, that anyone can use, right? Yes, and that's a big factor as well because the Apache license is a very permissive license. It is good for commercial product manufacturers because as long, you know, you can take the code base and you can modify as you wish. And you can redistribute on your own terms as binaries as well.

So manufacturers and commercial product manufacturers like it. And then if you are a project under Apache, you obviously have the Apache license. And our project also comes with the Apache 2.0 license. Okay, so I know if I use a GPL license, an older GPL license, once I modify the code, I have to make it so that my code is now open source as well. And so it's very sticky. Exactly. And if I use SparkFun's license, I have to buy Jim a beer at some point in the future.

The Apache license, you're saying I can take the code, I can modify it, I can release it, I can sell my binaries and keep my changes private? Yes, you can. It's that permissive? It's that permissive. Wow. So we would, of course, like it if you contribute back,

but it's not necessary. As long as you preserve the copyright and license information on the unmodified parts, you can do whatever you want. And then if I modify a file, do I leave the copyright there or can I take it out? You leave the copyright only in the unmodified parts. In the modified parts, you just do, you know, you can put your own terms to it. And then with the BSD license, I have to put it in my documentation. Otherwise it is very permissive, but I have to say I use this. Is Apache like that where

I have to put it in my documentation?ive, but I have to say I use this. Is Apache like that where I have to put it in my documentation? No, you don't even have to put that, but we are compatible with the BSD license. So if you have a BSD license, Apache license is, you know, we'll accept that. Yeah. So if somebody, sorry, I'm totally stuck in licenses now and I'll get out of here soon because it's, I know, legally kind of boring. But if I have a GPL licensed project, and it's sticky, and I have an Apache licensed project, does the GPL infect the Apache so that now I have to release all the code? Christopher's nodding. I mean, I guess that's true. GPL is sticky, but it doesn't change the original? Christopher's nodding. I mean, I guess that's true. GPL is sticky,

but it doesn't change the original license of the Apache code. It doesn't, but if you do link it with the GPL licensed code, then it is under GPL license. And people wonder

why nobody wants to use open source code. Wow. Well, no, it's just confusing. Although it sounds like if you're in the Apache license world, then it's pretty clean and you can use it and not worry too much about it and explain to your boss how you got a lot of code

for not a lot of time. Exactly. And that's one reason. That's the big reason why we went with Apache license. So we, that's runtime? We as in the founders of runtime, yes. Yeah. So you write code and then you say anybody can use it, anybody can make

money off of it and then you put it on the web. This is weird, right? I mean, this is not like, when I write code, I usually want to be paid for it. You have this problem with open source. I know. You always do this to open source guests.

Why would anybody do this? You don't have to answer that if you don't want to no i i i know what you mean because i felt the same way when i entered this world previously i was not i didn't have anything to do with open source and it was fascinating people do it for all the different you know for a variety of reasons i think you know they have personal motivations and motivations other than money, peer recognition,

all those factors playing. And the thing is, I think it fosters some sort of competition or competition. And there is a lot of knowledge that is already out there. And if you can find the right infrastructure and build a sort of meritocracy where people can collaborate easily, then people will help out. It's amazing, but it is true. And nobody should have to write a linked list ever again or a circular buffer.

These are things that other people have written. They're good. They're open source. They're tested. Why do we keep reinventing wheels? And I do really like that part of open source that you stop reinventing the wheel. You start being able to read code and learn how code goes together because you don't have to invent everything. You start learning the tricks that other people know.

Right. all these components are out there. A tool or something or a project to actually stitch them together for a variety of use cases is what is missing. And that is why we feel like, you know, our project makes sense. There are RTOSs out there. There is management software out there, device management.

As you said, there's circular buffer. There's management software out there, device management. As you said, there's flash circular buffer, there's all this IP code, there is different connectivity stacks. They're all there. But when it comes to stitching together into a product, it's a difficult path. You then end up saying, oh my God, there's so much fragmentation. Or if there isn't fragmentation, then it's all too big to go into my tiny processor. Exactly. So how do I optimize? So where is the, you want a nice sandbox, you want, which is rich with all these connections. And again, you don't want a new implementation. You want to be able to link to an existing implementation or you want to connect or borrow from another repository which is already out there and collaborate.

So that's why the collaboration platform is very, very important. And so this is what Minute is? And that is what Minute and Newt together is. Newt sounded sort of a package manager system, sort of like apt-get or all of the installer things. Correct. Okay. I just wanted to make sure I understood what that was. No, you're absolutely right.

That is, it's a built-in package management tool. And so I start my project and I have to slash get to choose which packages I'm building. And so I don't need to put an IP manager on my BLE device. I instead put a BLE library. But then I also get to choose whether I want buffering systems like this or like that or search systems and reuse all of that code. Correct. And so you need an environment where you can do this easily. And do this not just at the time of development, but you want to do it when you're manufacturing the device, when you're debugging the device, when you're managing the device, when it's out there in the field.

So you have to think about the entire lifecycle. And you want a tool set or an environment, build environment that actually works for all these different stages of a product. Again, we're always thinking a commercial product that is going to be deployed and that is going to be used in the field. So that's why, you know, the new tool, we've tried to, again, you know, you know that you know it's not yet another os you're dealing with yet another os you're dealing with yet another tool and it's frustrating i know to even think about it so we wanted to keep it simple and it's just a simple command line interface tool and what you can do is it what it does is it builds the whole debug environment easily for you

it will just in one command you can just run it you can debug it open up a debugging session and work with it load the code see what's how it's working how, you know, it's all in one. If you now want to create an image for manufacturing, you can use the same tool to do that. It's just one command and it signs the image. It creates a manufacturing manifest, which is basically a snapshot of how the device looked at the time of manufacture. You can do all that and then provide that information.

Okay. So what is the development platform? I mean, I usually use a Windows box. Is this Ubuntu or Mac? It works. All three. Okay. And I usually compile using GCC or IR or Kyle. Is this based on GCC then?

It's based on GCC. And GDB for debugging? And GDB for debugging. You can also, yeah, and you can use the OpenOCD or Jlink. So all these things are already available in the debug script. So when you use the new tool and say that, okay, open up a debug session, new debug, then it brings all these things up for you. So the NRF-52, the Nordic chip, and the NRF-51, with those, Nordic partnered very closely

with Kyle initially, which I guess ARM makes Kyle. But they partnered with Kyle and they made all these packages and example code that uses the packages. And I felt for a long time like I had to use Kyle because getting access to these already designed systems was so valuable. I didn't have to worry about missing this or that file. And I was quite glad when they stopped the packages and started supporting more compiling options. But it's still difficult. Nordic alone has like a hundred different libraries you can include if you want this feature or that feature,

if you want to use their flash debugging subsystem, or if you want to use their PWM with or without the GPIO manager thing. It's just very daunting. And you're saying that the Newt and the and the minute help you manage that complicated and daunting process yes to some extent meaning that it supports it doesn't support all the different compilers it doesn't support all the different you know options but if you want to add support for a compiler or if you want, it can be easily done. But if you're not, if you just don't, you know, if you're okay with just GDB and GCC, then you can go ahead and just use that.

The very basic. Okay. If GCC works, then I'm much too lazy to worry about the 5% of space or cycle bonus I might get from something else. But that process of you're just starting a project and you don't even know what you need is a very difficult one. There's some temptation to start with an example that is sort of close to what you want, but it never is what you want. And then you have to go back and you have to package manage things later, adding this or that, or realizing you don't need something

and figuring out how to delete it even though it's got fingers all through the code how is minute any different with that or is it just this is just a problem for everybody and we don't have a good solution yet i think this is just not solved completely yet but we do try to make life a little easier so So first of all, I think, let me just be a little clear on the motivations of this new tool. We really wanted something that would enable collaboration

across large core bases. So we didn't find anything like that. And so we built the newt so that you can link. It's a very simple directory structure it will keep track of which repositories you are connecting to you know it might be somebody somebody you don't know you know somebody out there in the github world it keeps track of all these different directories it keeps track of all the versioning of these different components.

And it tells you, okay, you know, there is a new version available. Do you like to, you know, sync up? And it allows you to sync up. So it kind of does the vendoring for you and keeps track of that. And so that's one piece. And still, you know, what you're saying,

you know, that's true. There is an activation energy. You have to spend some time to actually, you know what you're saying you know that's true there is an activation energy you have to spend some time to actually you know to get started so as you say you know we say follow the same path we provide you with examples which you know if you wanted to have a ble peripheral that just advertises something then you can take our beacon example and start there and try modifying a few things and see how it changes that's what i do as a product manager and i because i want these different demos and i want to see what how i can change it and so i start from there from the examples that are provided and change some of the code and try to get,

you know, build an image that does the thing that I wanted to do. How does Minute compare with Platform.io, which I believe is mostly an ITE and interface, but also manages packages to some extent? Are you familiar with that? I haven't used it, so I am not that familiar with it. Okay, then let me switch the question to how does it compare to Zephyr, which is the Linux tiny RTOS? Right.

So Zephyr is, you know, you can think of, we can think of them as a competitor or we can think of them, you know, we actually work with them and we're trying to see whether there are common components that we can leverage. But essentially they are yet another open source RTOS for embedded devices. So our goals are pretty similar. But I think where we differ is in a couple of areas.

One is in the whole process and the community and the governance of it, which is kind of important because we are not driven by any one company. That's what Apache, that's why we chose the Apache Software Foundation because it really gives credit to individual contributions and everybody gets a vote. And it's not, you know,

you don't really buy a membership into any organization, into the ASF. So as a representative, your own representative, you can actually push the agenda, which we really encourage because we feel that that is how we are going to be able to address real-life use cases. And that is the other difference with Zephyr.

I think we are very concerned about real applications, real use cases, and making sure that the code not only just works as it compiles and it's bug-free, but actually enables some applications and is being used by people. So we get feedback immediately. Being used in products is a huge, huge barrier. I mean, going back to Nordic, because I have been using them a lot, they have hundreds of source files I can include or not. And then they have this soft device. They have a number of different soft devices for different purposes, but let's face it, we all want BLE. And in that soft device, there are a number of RTOS functions, application schedulers and timer management, even some power management, as well as all of the BLE stuff.

Everything that goes from when I say I want this configuration or this characteristic set to three to all of the things that need to happen to get that onto the application on a mobile device. So there's this giant bundle of source and library that are provided by the vendor. And you're replacing all of that? Yes. That's a little scary from a perspective of shipping things. That's a little scary. Well, we are making sure that we are compliant with the specs and we are ready for certification. So it is we attend all the UPF, those are unplugged tests where you actually go and test interoperability with other devices. So we participate in that regularly. And so we're making sure that it is, you know, up to the specs.

And all those test runs, by the way, the results are included in the code base. So you can see the results and see that it's working. But that aside, we do that because we have heard from customers or potential customers that the Nordic soft device is not enough. They want to establish, for example, maybe 32 connections, concurrent connections, or they want to try and push it and get a higher throughput, stream some data, or they want to connect the end device to multiple centrals. So there are use cases, edge cases,

which the Nordic device cannot provide because the soft device is just a binary that you're getting and you have to work within the parameters, the bounds of the parameters. So that is the reason why we embarked on this big project, yes, which is replacing the controller. And we actually reached out to Nordic because, you know, to really understand the hardware, to make sure that we can extract the most out of the hardware, we have to understand the chip very well. And they were very happy. I mean, they collaborated and they understand that these are cases that the Nordic soft device will not enable.

And so they have worked with us. You said ready for certification. Has it been certified? No, we have not. Essentially, you know, we have, but it is ready for certification. So, and that is where runtime comes in. Because for VLE, you have to certify for each hardware. And we plan to have a reference, we want to plan have um controller subsystems that are certified for certain hardware we cannot do all different hardware no no you want to choose a module that's probably already been certified on the uh the nordic one sort of like the regatta modules are

are pre-certified and um so we have to go through the whole certification again because we're replacing all the code but yeah we are so it's a big undertaking but we have we go through the tests we actually you know so the testing is done but the certification process we want to do we are ready to do runtime the commercial entity is ready to do for the open source project. Ready to do and starting on Monday are different things. Yes. I'm like, I want to use this. This sounds cool.

And since I do use that Nordic processor a lot, I feel like, okay, but until it has been certified on a module, any module, I can't in good conscience recommend it. So if Nordic soft device is meeting your needs, you don't have any code size constraints, if the footprint is fine, if you don't want to enable any edge use cases, then sure. I mean, even we say that you can just go ahead with the Nordic soft device. That's okay. But if you want to do things

that the Nordic soft device does not allow you to do, and that's what we are working on with several different companies. And as I said, somebody wants to connect increase have a really high throughput so we have to manipulate the you know connection intervals so that we can send right one after the other a lot of data so they needed that well in 18 months ago i would have been all over the, I really, really, really want to be able to be both a central and a peripheral. I want to do both and I want to be able to switch roles.

But now that's in the Nordic soft device. I haven't used it. I heard it was terrible, but that was like eight months ago. So I'm hoping it gets better. Anyway. And I think we have pushed each other to do better. I will say that. Because initially the Nordic came out, they supported three concurrent connections.

Then, you know, we worked on 10 and so they had eight. And now I think they have something 20 or something. We have tested up to 32. So, you know, we keep pushing each other's boundaries, but we are ready to go to certification with the customer if the customer wants to. I can't believe you've implemented your own BLE stack. That's cool. I mean, that's

a lot of work. Yes, and it works very well. So we are very proud of that. And it's open source, so people can read it. It's not just a theoretical, here's the BLE spec, which is hundreds of pages, and here's a chip, and there's magic in between because you're using Nordic soft device. You can actually go see how a BLE implementation is written yes and you can test it and you can see the test results you can there are applications already available you can just

load it up it just takes a couple minutes and see it work so okay one of the things that you noted when I sent you my list of questions was something about a web server and BLE. Yes. What? BLE doesn't have web servers? BLE is the transport. But as I said, these end devices, they do something. They are in lamps, refrigerators, fans, something. And so you want to control them or get some information about them, about their state.

So a lot of them are connected over Bluetooth. So how can you use this transport and be able to manage or control these devices? So that's what we have enabled. Oh, okay. So normally these devices, when you speak Bluetooth, you have a GAT and you have characteristics and you have an intermediate between the device and the cloud.

Usually it's a mobile device. Usually it's your phone because that's what apparently everybody has that has a BLE in it. But that's what you used to talk to the device and to talk to the cloud. Correct. And so the web server isn't really in the BLE part.

The web server ends up being on the mobile device. No, The web server ends up being on the mobile device. No, the web server ends up being on the minute. So you could enable a characteristic and then have a service that retrieves that characteristic, UUID, over BLE for a certain light. But what about another light? What about, you know, there are so many manufacturers. There are lights that do slightly different things.

So what you do, what you would like is to have a consistent interface to be able to query lights in general or fans in general and you want to be able to do it as quickly in as constrained as possible so and you at the other end you want to enable applications to use that information right whether it's your smartphone or whether it's your desktop application you want to do something with that information, make decisions, you know, whatever, about changing lives or whatever. You want to do that.

So you have to be able to pass this information back to other applications. So what we invested in was what is called OIC, and it's from Open Connectivity Foundation. It's a protocol that is essentially like HTTP. And what you have on each of these devices, on the minute device, is a tiny web circle of sorts. You have a URI, a universal resource identifier. You have a URI, and then you can describe the resource, have a simple model, a data model for lights. And then you can use a

constrained protocol, something like COAP, which is essentially HTTP for constrained environments. You use that protocol to do your get, put, delete or the usual simple transactions on the device. So does that mean if I'm writing an application to talk to this device that I don't have to double my efforts and if the device speaks Wi-Fi and BLE, and the interface is the same, is that an advantage? Yes. So OIC runs on IP. Okay.

So as long as you have some IP address and connectivity, you can use that protocol. What was missing was the BLE part. And they are actually working on trying to see whether they can have some standard around it to do it over BLE. So what we do is essentially we have a GAT service that serves up all this data and then reassembles the packets into OIC packets. So that at least the applications, they don't have to worry. They just have a consistent protocol and a interface.

So it's basically IP over BLE, sort of? Or HTTP over BLE? Yeah, HTTP over BLE. Okay. It's co-op over BLE. So you're using all the normal BLE infrastructure, GATT and all of that. Absolutely. But you're putting higher level data on top of that that looks like web stuff.

Correct. Okay, let's say I have a light and I want to broadcast my status. And normally I would look through and see if there were any of the standard GAT profiles that met my needs. And if there wasn't, I would create a custom GATT profile and I would have characteristic that said light status. And I would make it so that you could read, write, or notify on that so that people could subscribe to it.

That's all a BLE thing. Someday we'll have a show about BLE again. And now you're saying that instead I would have a profile that was this OIC instead? Instead. Oh, okay. Yeah. And it's OIC, like Oscar India Charlie. Correct.

Okay. I heard YC, Yankee Charlie, and that's not right. That was something else. The web could not help me there. OIC. Okay. I heard YC, Yankee Charlie, and that's not right. That was something else. The web could not help me there. OIC. Okay. There used to be a lot of applications, mobile applications that would speak to their BLE systems over serial, over BLE, UART over BLE sort of and that worked for a little while especially with the early BLE chips and now it's a pretty inefficient way to talk

this is sort of like that in that you're making a generic profile and then adding a layer of software to not really parse the data but to parse the data, but well, to parse the data, really. Yes. And you're doing that so that things can be more generic. Yes, and something more.

It's not just about getting the data. It is also about discovering these resources. So the COAC protocol, which is kind of like whatever constrained http it allows you to discover these devices and the devices can tell announce that oh i have these capabilities so you discover the resource devices and the resources and then you can take action as necessary so you really don't have to model for each different type of lights, because the light will itself tell you what it can do. And it allows for vendor specific things too. So it's not one size fits all, but there is room for variations, but in a consistent interface.

There was another protocol, MQTT? Yes. Is that similar? It is similar, but CoAP is over UDP and MQTT is over TCP IP. So for these real constrained devices and environments, Coa is, we feel that that will be the winner. And this whole OIC framework,

it has really worked on optimizing, say, things like the URI. It's a very short URI. They use encoding, which is, you know, C-bore, which is constrained binary object representation. It's very, again, it's very efficient. So it has all the things that are good for these constrained embedded systems. So that's why we feel this is going to be successful.

So how big is all of this? I mean, this sounds gigantic. We're talking about partial I mean, you said UDP and that's partial TCP IP sort of stacks, and those are monstrous and require real operating systems with timing constraints. I guess the BLE stack requires timing constraints too. But how, how big are we talking for your piece? Are you going to leave me any room on the NRF 52 to write my application?

Of course we so we have, we actually, compared to Nordic, we have reduced the code size by almost 30 kilobytes, you know, to do all the BLE portion. Again, we are, it's highly configurable, our BLE stack. So once you have become familiar with the minute and how it's structured, you will see that there is a lot of system initialization parameters and configuration items. So you can optimize even more if you want to.

I guess that's the advantage to being able to compile it all from packages myself. There are parts of the soft device I don't use and will never use. Yes. And with a new tool, you can find out what exactly you're using. And all the package dependencies, it gives you all that information. What about security? I mean, I'm going to say this again because the joke never really gets old. The S in IoT is for security.

Now that you're making these URIs and making things more accessible from the internet, that makes it scarier. That makes security more important. How are you dealing with that? Security is extremely important. I was a security product manager at my previous job. So in this product as well, in this whole project, we are making sure that the building blocks are there.

So for example, we started off with the secure bootloader. It's surprising that there are so many operating systems that actually don't offer a secure bootloader. And they just leave it up to the chip vendors to just implement something. And there are so many variations of the secure bootloader when we all know what the basic functionality is, the requirements.

And so we have that already in the minute project. So you have to sign the image, you have to verify the image before you can boot up from it. And you can even have a fallback option. You know, if something is wrong, then you fall back to the previous known good image. So that is an absolute must. I did notice that Nordic's secure bootloader subsystem in the post-11 SDKs was so much better than it had been. And so it's okay with me if you take credit for forcing them to get it

together and make a much better secure bootloader system. And you might enjoy hearing that we also reached out to Zephyr. And we are actually working, we, you know, we said, let's collaborate on the secure bootloader. And we are working with them and the Riot operating system and we are all working so we contributed the minute secure bootloader we call it MCU boot and we are making it usable across different operating systems

so essentially getting the baseline security in all these different products is very important to us. So we're doing that. And as for communications, we are making sure that all the security provisions that are in the specifications are absolutely implemented, whether they're optional or not. Mandatory or optional, we are making it mandatory

in all our implementations. So the BLE security, it's all the security manager that pieces in, including all the legacy works and everything. For other, for IP networks, we are going to have IPv6 security that comes with it. Again, we actually didn't write the IP stack. We are using the LWIP. Again, leverage what people have done,

improve upon it if necessary, tighten any security holes. So we make sure that all the provisions that are in the specifications are implemented. And then lastly, that's fine. We look at these security implementations, all these little components. That's one aspect. As a whole, across the device lifecycle is there security. So that is the piece that runtime is making sure that it happens properly.

So starting with when the device is manufactured, when the image is built, when it is put on the device, how it is discovered, is it discovered securely, is it provisioned securely, and is there enough authentication or authorization when you actually do these commands. So if you see all these protocols, they do have provisions. So for example, Co-op, co-app. It runs on UDP. You can have DTLS on it and make sure that there is mutual authentication. And so we have that in our system

and we're going to make sure that it is used, actually used, not just implemented when you build a product. Even just implemented for some of these features, it hasn't been that long since I've been requested to write a secure bootloader and now I'm thinking, well, I wouldn't. I would go look at yours or look at one of a few of the other open source versions and avoid making my

own set of mistakes i can read your code use it learn from it maybe compare it to two since i don't have to write it all and now i can read a couple of different ones and end up with a better solution absolutely i would love to you know if you can join, you should join the MCU Boat team and see what we are doing and provide your input. The more eyes on it, the better. But I don't have to. I can just go on your GitHub repository and find it. I can lurk before I'm willing to join anything. I'm a terrible joiner. I don't join anything. I joined a podcast.

It was a while ago. It still hooked me. This is a pretty big investment, though, a big mental investment to get involved with these open source projects or even to use them. To some extent, it's easier to write code than it is to read it. How do you convince people it's worth the time spent learning minute and newt

and the constrained HTTP and all of this instead of just inventing it again? So I think the key is to show that it can be of immediate value. You, you know, have, there are people who are interested in them, show them the power by, you know, showing, okay, these are the applications, just see how easy it is and what all things you can do. You have to spend the time to actually work with them. So there is some, we have to reach out and work with everybody and then listen to what they need because they are looking for a reason.

And then brainstorm and welcome them to the community and take it from there. So if I did want to get started looking at my newt, is there a tutorial or a board that I should particularly look at? How would I get to the, not necessarily contributing or joining, but just to the point of trying it out, seeing how it works for me. So we've tried to keep our documentation fairly up to date. It is not.

I will say that. I will admit that. It's an open source common complaint. Common complaint for every source, not just open source. That's true. But do take a look, mynewt.apache.org. If you go to the website, you will see that there are quite a few tutorials with pictures. And the new tool, we've tried to keep it simple, but you can see how you can use the different things so i would say take an nrf52

since you love the board and create a beacon or just turn it into some you know um a peripheral that advertises something that you want or um you know take it from there. I noticed you said that the URL is minute.apache, but when I was looking, it was minute.incubator.apache.org. What was the incubator for? So the way Apache Software Foundations work, they first introduce, they take on a project as an incubation phase. That's because they want the project, they call them podlings, they want the project to understand how Apache Software Foundation works, understand the infrastructure, build the community, get help

from the mentors to actually get momentum. And then once they feel that the project has taken off and is being accepted and is useful with a larger community, then it becomes a top level project. It's called graduation. And then it becomes a project like Apache, you know, web server or Hadoop and other projects. So we have been in the incubation phase for, I think about a year and a half,

and we are about to graduate and we have started the process of graduation. So in about a month, we should be a top-level project where we can govern on our own. We have policies, we have release policies, we have contribution guidelines, and we have all these processes in place, and we can self-govern. I did see that you had very clear,

understandable directions for contributing patches. It made a that you had very clear, understandable directions for contributing patches. It made a lot of sense to me. And I think that's one part of open source that is always a little fear inducing of, well, I want to make this change and I'm happy to give it back, but do I have to talk to mean people? And your process made a lot of sense and was clear and didn't sound arduous. Thank you. So you've mentioned runtime. We've talked a lot about Apache and Minute. And we've sort of mentioned runtime, which is the company that pays you. And they write a lot of this

themselves. How do they make money? It's a very good question. Something we ask ourselves too. But so there are a couple of actually three ways in which we are hope to monetize this whole project endeavor. So one is to actually provide commercial support to different companies, whether they want to customize or they want, say, certification

or they want to have long-term support for a certain release, then we can work with them and maintain that release for them, put, you know, to the patches and make sure that it is always maintained and up-to-date. So that's like Red Hat for Linux. So we can be that, you know.

So that's one area. The second is actually to help with the cloud services. And that actually is in a couple of ways. you have a few devices, and you use our continuous integration environment and our basic cloud features to manage development on those boards. So what we provide, which is the minute operating system, one of the reasons why we did the minute operating system was so that we could put in hooks and middleware,

so let's say, for management purposes. So we have a logging infrastructure. We have a statistics module. You can define different statistics, whatever you want to monitor. We have basically rich instrumentation to understand how the device is working. We have reboot logs. We can do crash dump analysis.

So when the device dies, it actually records where exactly it died, what happened. And this is very important and very useful when you actually have devices out there in the field where you don't want to send people. I mean, it's very costly to do that. Oh, yeah. And so if you can retrieve it remotely, you know, that is great.

And you actually can see where the failure occurred, which task was it in, you know, and exact sometimes even the exact line of the function where the failure happened. So we have all those things available, even in the, you know, continuous integration environment, and a developer could also use it. And if you like that, then we have the second part of that cloud services, which is for scaled deployments. So deployments at scale. So it's one thing to do for one to 10 devices.

And completely different ballgame when you're actually managing, say, a million devices. Oh, yes. Well, I put the line at a thousand. Recently, we asked, somebody wanted to be on the show. And I said, well, your product's very interesting, but why don't you call me when you have a thousand of them in the field? Because I just, there is something about not being able to touch every unit that makes them a lot harder to manage. Absolutely right. And this device management is, I mean,

it's huge. The more we talk about Internet of Things, it does seem And this device management is, I mean, it's huge. The more we talk about Internet of Things, it does seem like the device management and data collection and with all of the privacy and security concerns, it's a huge piece that I guess as embedded engineers wouldn't usually worry about. We talk to the phone and that's enough. It's hard enough. Just go and do something else with the data. We wouldn't usually worry about. We talk to the phone and that's enough. It's hard enough. Just go and do something else with the data. We don't care about it. But that isn't really true. And if you're building a complete system or working with a team that is small and you have to be aware of the complete system,

knowing this backend cloud infrastructure and being able to integrate with it well, that is pretty useful. I'm thinking about the fact that recently I've had clients switch, multiple clients have switched to multiple different backends, and I'm just thinking about all of the different interfaces to keeping track of my sensors and making sure they know where they're talking to. It's a huge mess.

Yes. And you want to know whether the sensor is working properly. Otherwise, is it sending the right data? Is it the right sensor? So that's the data and that's the control plane. That's the device plane that we're talking about. Making sure that these devices are who they are and they are doing what they are supposed to do correctly and which one's got which version of firmware and

which one should have which version of firmware because you don't always want to release to everybody at the same time you really shouldn't release to everybody at the same time exactly and so you need to stage you want to try it, say, 100 devices and see how it works. 100 devices here, 100 devices there, and then analyze. And then push it out to the larger community, larger network. So, yeah. Yeah. These are my alpha users. These are my beta users. Don't send it to the customer until we're done.

Absolutely. So the framework provides both code for devices and systems for managing many devices. The piece that I'm wondering about is, do you provide anything for application developers? Every BLE device that

people make, there's the piece that has to be on a phone, most likely, and interact with it. And that's something that a lot of people don't have any experience with, that they're coming from the embedded side. Or even from the software side. Or also from the software side. Application development on mobile is non-trivial.

So is that a piece where you're providing examples or help somehow? Yes, we are. We are. We are not interested in the data itself and what you do with the data, so we are not going deep into what application you develop. But we

do want to maintain a consistent handoff of the data and the interfaces. And that's why we, for example, the OIC, there is a certain format data models that it supports and we have abstraction layers that you can use.

So yes, we will make sure that you can easily build applications using the data that comes from our system. Okay. And if somebody wanted to do, like you mentioned, make a beacon, there's already programs you can run on your phone to look at beacons. So you don't need to write anything to start with. Exactly. Exactly. But you would have to write something if you wanted to show the beacon on their cloud service. Okay. Yes. I have more questions, but now they're all informed because this is all pretty different than what I worry about. So I appreciate you speaking with us now and hope that I can email you with my questions and maybe we'll talk more about it in the future. I would love to.

Do you have any thoughts you'd like to leave us with? So one of the things that I feel strongly about is that there is not going to be any one best solution. There is not going to be a clear, you know, this is the best RTOS or this is the best communications protocol. So it's important that we leverage each other's knowledge, that we don't reinvent the wheel. And we have to have room for innovation and creativity and stuff. So we cannot have one size fits all. So what is important is making sure that interfaces are consistent, that systems modules are interoperable, and that the design, the modular design is very simple. So you know how to put together these different components and make them work.

And you have to be able to mix and match. And this is I'm talking about end-to-end system. So essentially, I'm saying that, you know, collaboration is the key to success. All right. That is true. So it's a good place to end it. Our guest has been Aditi Hilbert, product manager at Runtime.io. Thank you so much for being with us.

Thank you very much for having me. Thank you also to Christopher for producing and co-hosting. Thank you to Andre, who on the blog this week explained SPI and all of its intricacies. That is not trivial. If you want to read about it, go ahead. It's embedded.fm slash blog. And it is pretty cool to watch somebody try to explain something that complicated and how far off the path he had to get. How did he get to oscopes anyway?

All right, well, you can read that. And of course, thank you for listening. The thought I have to leave you with shows that I searched for some very specific keywords in order to find quotes. This one is from Shakespeare. Embedded is an independently produced radio show that focuses on the many aspects of engineering. Thank you.