 I think we have more people than registered, so we could wait. Well, what time does it say? My watch is always, it says now. We can start anytime. It's up to you. Let's go for it. All righty, I'll get started. Where's our little doohickey? You got the doohickey? Yeah. Welcome to the 420 session at the, which day is it? Are we the embedded Linux day or the open IoT day? Or are they all the same day? It's all the same. OK. Welcome to our talk on prototyping with ESP32. I'm Ivan Judson, and my colleague Pamela Cortez. To give you a little bit of context about what we're talking about, who we are and what's going on, I am a sort of career academic who's gone into the commercial world. I have been three years at Microsoft at a startup before that. And in my role at Microsoft, I helped sort of get our hands wrapped around partner opportunities in IoT, working with the All Join Foundation Framework Consortium, and then rolled into a bunch of open IoT events being involved here. I have a little bit of experience all over the place, but what I've done at Microsoft over the last couple years is really engage in customer problems around IoT. And then more recently, I have taken all of that and rolled it up, and I've moved over into the product side. So I'm working in our Azure IoT product team, and I am specifically tasked with working on the Microsoft Connected Vehicle Platform, which we announced at CES this year, with a whole bunch of details left unanswered intentionally. And I have been working, I'm sure there's other things that we were going to talk about, but I have been working with Espressif and the ESP8266, and now the 32 for about a year building various ideas and products. And I have a little bit of a startup passion, so I've been advocating these devices in various scenarios. So I'll let Pamela introduce herself, talk a little bit about what she does. Thanks, Ivan. So my name is Pamela Cortez. Before Microsoft, I worked at SparkFun like Tronix in the engineering department. So I did anywhere from Harvard Engineering to their software league, and then anywhere from making a tweeting turkey to playing office pranks to robotics and going out and teaching as well. So I'm interested on your guys' background. Are you guys mostly embedded Linux? Who's the embedded folks? And then who are the folks where they're focused on the cloud side of IoT? Everything, could be both. Raise hands. I love it. All the end-to-end IoT solution. So we like to think of this more of like a chalk talk where it's very interactive. So if you have any questions, let us know and just interrupt us. And if you have anything that experienced in some of our products or some of the open source commits that we've done and would say you have positive or negative feedback, feel free to give it to us because we want to hear it as well. So I'm going to get started on really what the agenda is going to be for this talk. So we're going to be talking about the prototyping process and really high level on that. And then we're going to talk about the ESP32 background. And who in here has worked with the ESP8266? So we got you. Who's already worked on the ESP32? Great, great. So that gives me a little bit more contact. So I could talk a little bit more about what is the ESP8266 and ESP32. And then we're going to talk about Azure. And then Ivan's going to do an ESP32 demo. So I'm going to talk really high level on the prototyping process for IoT devices. So first step, number one is come up with that new idea. So anywhere from, let's say you have an idea for a streaming device for home automation, or maybe you're just copying Alexa and deciding to make your own device, just starting off with an idea and what you want for your product. The next step is actually thinking about the requirements. So for example, what's it going to do? Do you want to stream video? Do you want to stream audio or none of the above? Or maybe the tenant use of it is being able to have a home automation device. But sometimes you have to think about the real life use, because sometimes people will take your product and totally use it for the different use case, which we see all the time. Or even hack it as well, which I believe is the fun part. But if you're trying to have a product in the consumer side, you don't want anyone being able to hack your product of course. And then doing market research. So if you're going to do this product that I just described, and there's already 50 other companies doing it, is that something that you want to do? Or what is the difference between your product versus other products? And then device selection. So budget is a real big thing, especially when I was doing hardware engineering. We thought about the bill of material all the time. And the reason for that is because if we're building a cheap Wi-Fi solution and our bomb, our bill of materials is $70. And our margins need to be at 4X. There's no way that we could actually be competitive in that market. So budget is actually a really big topic for engineers. And then device lifecycle too. Is this something that's going to be out in the field for 15, 20 plus years? Or is this something that you think is going to last for the five years? So it's something to think about. And then of course, how you connect to it. So a big topic right now is remote monitoring in places where there's no Wi-Fi or Bluetooth. How do you deal with that? How do you connect? Is it through gateways, cellular modules? So that whole methodology of how you design devices is very different than designing and consumer devices. And then also for device selection, you've got to think of products that are going to be end of life. So if you've got a really great deal on a microcontroller from eBay and you're thinking, oh, that's great. And then your product gets big. There's going to be, you're going to have some tough learnings from that, especially if you want to have millions of devices. And you find out you can no longer use that chipset, mostly because it's end of life, so things like that. And then product, lifecycle. Development testing, device management. You're seeing a lot of great headway and device management. How you do over-the-air updates with firmware is a big topic, especially for security as well. Being able to patch those devices, if someone does get hold of those devices, is something to pay attention to. And then also product support. So if you have a product, let's say we'll go back to Alexa, because it's a really popular IoT product at the moment. One of the things to, or the echo, one of the things to think about is what type of technical support you're going to have for that. Because there's going to be a lot of beginners using the echo, so you want to be able to be sure that you have enough customer service representatives. And then if you have developers hacking with that project or that product, you need to be able to have the staffing for that as well. So that's super high level. And it's really going to set us up for the rest of the talk. So some of the actual devices that we have SDKs with and support for and a lot of our device SDKs, Ivan will talk to at the end of the talk as well. So I have anywhere from the ESP8266 to Raspberry Pi's, Edison's. One of the things to think about between microcontrollers and microprocessors, microcontrollers are really good at ingesting data and sending it to the cloud, doing really simple things. And the microprocessors are really good for, let's say you want something where you're doing compute on the edge. So you want to do something that you have all this amount of data, but you don't want to send all the data straight up to the cloud. You can do some of the analytics right on the device side and send what you need to send up to the cloud. And the reason for that is a huge cost savings. So it really depends on what type of scenario that you want to do. So let me know if you guys have any questions, but I would skip ahead. So why Expressive? Why are we here talking about it? And why Microsoft is putting an interest in it? Mostly because it's a low-cost chipset which is made by Expressive Systems. It's ideally under $20 for a dev board and easy to get started for. And also it crosses between the maker community, beginners, and then also startups and R&D research and to production. So you can actually go from prototyping to production really easily. Unlike some of the products in the maker community, some of them are great for prototyping, but when you go to production, you'll find out that there's not that support for it or it's hard to scale up with some of those products. And then also there's fast adoption by SparkFun, Adafruit, and many others using this chipset, which is great because it will help beginners out who want to, you know, their influencers in the communities, but maybe they don't know how to start it with hardware. It's easy for them to prototype their idea, bring it to an investor, and then be able to build up a team behind that idea as well. And then I forgot to mention that Expressive was named a cool vendor in IoT in 2016 by Gardner. And Gardner is really that gold standard of, you know, who are the leaders in IoT? And they say cool vendor, but it really means that they're the most innovative vendor at this moment. And it's mostly due to their open source community support. This is really taken off in the community. So let's say you are a maker who wanted to, you know, make a smart light bulb or a connected device or a connected appliance. You can actually do that really easily because there's such a huge community who's willing to help you out and open source code behind it as well. All right. I'm going to jump in once I can say. For those of you who've worked with any of the Expressive chipsups in the past, the 8266 development environment was not entirely open. There were most of it was, but some of the actual libraries that Expressive had built and distributed binary because of whatever management they had been going through. But in that process, and by working with them over the last couple of years, for the ESP32 in particular, it is entirely open. The entire tool set, the entire source for everything. So you can basically start from a piece of a board and an editor and build and run your app in minutes. It's a pretty straightforward process. And I think that they understand that they are in the hardware innovation business and leveraging communities, the open source and open tools from the community accelerates their business as well as everyone else's. So they really do get that sort of model. Yeah, yeah, definitely. And they're really good at building up that community as well. All right, and why the ESP32? So the ESP32 is, you can use it for many different applications. Anywhere from wearables, connected appliances, to streaming audio and video players, and even connective appliances, oh, I already mentioned connected appliances and home automation. So another thing is it has 12 years of committed expressive support, which is huge. Especially when you make a product, you wanna make sure that that product has support for a long time. And they're guaranteeing 12, even 20 years of device lifespan, which is really great, especially when it's going out in the field. Because a lot of the products that do go out in commercial enterprise scenarios do stay in the field for a really long time. And then also, it's mobile factors depending on your product requirements. So you can really just have it simply ingesting data straight to the cloud, or you could do stuff with that data before it goes to the cloud. So it's really versatile. So it comes in many different form factors to get started with. Here's a couple. So this one's their dev board. If you breadboard before, it nicely fits right into a breadboard. It's, you can connect it with jumper wires, really easy to get started with, great documentation. And then the next one is the rover board. It has an LCD in the back, and then extra components as well. What's great about this one, you can stream audio, you can do video. And so that's a great way of getting started without connecting a bunch of shields and everything with it. And then on top of it, you know, Adafruit and SparkFun, they're already making boards, development boards and shields for this product as well. So if you're a fan of their company, you can work with their past shields that were being used for the ESP 8266. How many of you are familiar, before you move off the slide, how many of you are familiar with the difference in the board versus the dev board versus the shield? Okay, so I just want to point out in this picture, the ESP 32 is actually only that part of the picture. It's this square here. The rest of this is their dev board. So it's mounted to expose all the interfaces on the 32. And it has some LEDs and buttons for resetting and firmware, and it actually has a UART serial, blah, blah, blah. I can plug into my USB port without an adapter. Which is really nice. Makes my life happy. Yeah, FTDI interface, that's what I was looking for. Yeah, because a lot of dev boards, you have to have the FTDI basic to connect with it and the extra boards. So it's the full package and you have to add sensors to it but it's still nice to get started with. So we're gonna. Of course we lose the time. So the ESP 8266 versus the ESP 32. So the 8266 came first and it's a wifi chip. Ooh, thanks for helping. And so this one is based on the Tensilica. It's a 32-bit microcontroller. And then the ESP 32 is still Tensilica, but it's a dual core LX6 microcontroller. And the reason why I wanted to mention that is because this company, the Tensilica, is actually we're using HoloLens and their technology in our HoloLens device. So little, little tidbit there. And then some other things are that the operating voltage and the operating temperature is the same between both chip sets. And then for the ESP 32, it has both wifi and Bluetooth. So something to think about is that the ESP 32 is not a complete replacement of the 8266 because there's applications where you don't need that Bluetooth. So if you don't need the Bluetooth, why spend more on your bill of materials to get that feature? So something to think about if you're deciding if you're gonna use it for your product or not. So the sensors, the ESP 8266, doesn't have any sensors included. So that's probably good if you just want a really basic microcontroller. And then the 32 has a hall sensor, capacitive touch, ultra low noise, analog, amplifier, which is really nice. So a couple different sensors you can use. And for GPIO pins, the 8266 has 17 pins. And then the ESP 32 has 32 pins. So there's a lot more pins that you can work with. But then again, it goes back to do you really need 32 GPIO pins for your application? And then I'm gonna tell you right now, I haven't done an application where I needed that many, but it could be very useful depending on what scenario you're using. For security, the jump from 8266 to 32, there's a lot more security features for the 32. They've done a lot of really great innovative updates to security. That doesn't mean that the 8266 isn't secure. It just means that the 32 with the Bluetooth support and Wi-Fi combined, they also have even more security features. Yeah. Mm-hmm, excuse me? How many bit curve? I don't remember off the top of our head, we can look at the specs. It's one of the things that's interesting in terms of the extra features we don't have in the table, but I don't think we talk about them later in the slides, is that the ESP32 actually has the notion of doing secure firmware. So it has memory protection, that if you mess with it, it'll erase itself. And it also has the ability to encrypt the flash and the bootloader. We don't do that in our demo because once you encrypt, then the process is longer for doing all the updates. You can't really do over the air yet with that way. And so we're not demoing any of that, but it has significant more security features as a IoT edge device that you want to put in a place where it may get tampered with and you want to be able to trust it. So. Yeah, thanks Ivan. And then for power consumption modes, we like to always point that out because battery management and power consumption is a huge topic for IoT. So for the 8266 versus the 32, things to keep in mind that is the battery management, the power modes are a lot better with the 32. However, there's also a lot more modes in the 32 that you could change for. So if you have any questions for that, let me know. And then there's also sometimes that the power consumption is gonna be more for the 32. It's mostly because you're doing more with the chipset the microcontroller and the scenario. Yeah, one detail in that that's useful is even in low power mode with the 32, there is an ultra low power co-processor that can be woken up and used. And so there's actually like, I wanna say eight different power modes in the 32. So in this table, we just tried to match up the most sort of the closest corresponding modes. Yeah, hibernation is the lowest state that they document. Yeah, this is literally powered off. It's still consuming that one. It doesn't have a powered off state. Yeah, so it's not a direct comparison when you get to the last numbers from off and hibernation. All right, so Microsoft Expressive, Adafruit and SparkFind. So we've had a really strong partnership with Expressive and also the maker companies as well. And the biggest thing that we take away from that is that we wanna be able to contribute to Expressive's ecosystem. So and make sure that it's able to connect to Azure right out of the box. It'll make it a lot easier for developers to get started with. And then we've also been working with Adafruit to create the 8266 kits. So for people can breadboard, different sensors like temperature, humidity, and really get started to see what you could do with the 8266. Other thing with that is that you could use the Arduino IDE, but you can also use the native CSDK as well, which I really recommend, especially if you're thinking about going into production. But if you're a maker or someone who wants to get started with it and you're comfortable with our Arduino IDE, there's full support for that as well. And you're seeing it with the ESP32 that's coming out for Arduino support. So that kind of just is what the kit looks like. All the code is open source. So it's the hardware is easy to get started. Wait, go back to the point I just wanted to point out. If I recall correctly, correct me if I'm wrong. This kit we put together with one of our partners. Adafruit? Adafruit. And this I think retails for $46.95, about $50. And it has all these components. This, the rover board, retails for about the same price, just about the same price. It has many of the same sensors, but not all of them. It has an LCD, which that doesn't have. And having given hundreds of hours of tutorials on IoT, I would rather carry these around and help people learn how to write software than match up pins to holes. Yeah. There's a big value to integrate it. Yeah, and LCDs are not cheap either. So they definitely got a really great deal on that dev board. Though I totally agree. And if you're not familiar with breadboarding you're just starting, it could be kind of a little intimidating for people as well. So as I mentioned, we have Wi-Fi, Bluetooth, and power management for the ESP32, and here's the pinouts, the 32 GPIO pins. So I'm gonna let Ivan take over and talk about the cloud side and the full end to end IoT solution. Well, let's see how it goes. How many of you have built IoT solutions with the cloud? Going to the cloud, about a quarter of you. How many of you have used Microsoft cloud at all, Azure? Okay, a different quarter of you. Fair enough. I'm gonna give sort of a very quick overview of what we provide in Azure, but mostly from the point of view of an IoT, trying to build something in the IoT space and have an end to end solution that delivers some value, not just to the customer, but also to you, because no one gets into the business of doing IoT just for fun, right? Go ahead. So ESP32 does not integrate with the funds like only A266? We'll get to that. That's part of our demo. Excellent question, but you're setting me up and I'm not ready yet. That's where we didn't plant him. We'll pay him later, but we didn't plant it. So this is generally the way we think about IoT in the big picture. And what you should notice here is this big bar in the middle is essentially where the cloud starts from the client point of view. This is, from here to the right is infrastructure that you would outsource to a cloud provider, Microsoft, Google, Amazon, whomever. And we would all provide functionally the same kind of solutions. We would provide what we call batch analytics, hot path analytics and hot path business logic. Business logic is things like real-time applications that trigger on the data coming in. So logic applications, lambda, we use actor framework, so we're monitoring things in real-time. Hot path analytics are more things where you're gonna process the data as it's coming in and do some interesting things on it, sliding window averages, aggregations, things like that. And then batch analytics is more where you're gonna do, try to extract insight and knowledge from the data that you're acquiring. This isn't something you're gonna do every minute, every hour, but you might do it daily, weekly, monthly. It's places where you would apply technology like Hadoop or Spark to process large quantities of data. Or in our case, we have things like Azure ML where you can build machine learning models and then execute them on the data as it flows in. You need that large quantity of data to train your model and then you can run your model as either hot path analytics or a logic app. Tell me when an anomaly is happening with my devices so that I can notify someone to go out there and repair. That kind of stuff. We have a bunch of infrastructure in these places that's Microsoft specific and so does every cloud provider. The only point I wanna make about this side is that one of the things we have worked very hard at over the last few years is to make sure that you can bring your existing expertise and add the value to this side of the pie with the tools and technologies you're familiar with. So you can write node based applications, Python. You can still do C sharp and various other Microsoft technologies but you can do it with essentially anything. Our Spark implementation is Python native so we're not doing anything sort of strange in that space. So that's kind of all the stuff that happens in the cloud. This cloud gateway, this is an old slide. This is now, if I were to make up, if I had gone and found the newer slide, this would say IoT Hub. IoT Hub is the cloud endpoint for IoT devices in the Microsoft ecosystem. IoT Hub provides large scale telemetry ingestion as well as command and control out to devices. We have documented plans for device management, software management and various other components that are going out to the device. I don't know where we are in the delivery of those plans and I'm inside the product team so I'm trying to be very careful not saying anything I'm not supposed to. We did release the device management and twins, methods, routes, all of that recently. So those are ways to build up data models on the cloud side that interact with the data on your device and so your device becomes a first class managed object. In fact, I think in the public GitHub repo I did see device methods. Yes, that's live. So device methods are the notion that you have an object over here that you can invoke a method on that goes all the way to your device, executes and comes back with a return that looks synchronous from the programming model. I'll leave it at that. It may or may not actually be but it behaves the way you would anticipate it. So from the cloud side, from IoT Hub, the next step out is what we talk about is the protocol adapter layer and you're all probably, if you've been in this business longer than five minutes, aware of the fact that everybody has their own protocol on the wire to carry data and do what they wanna do and everybody's protocol is the best one out there. So don't get into the trap of arguing just right in an adapter. So historically speaking, our protocol choice has been AMQP. We also now support MQTT as a first class citizen from protocol support. So over time, initially we had an MQTT to AMQP adapter. We now host that natively so that we can do AMQP and MQTT devices natively without another adapter layer. But you can imagine any number of other protocol adapters. They could be built for anything and in fact, this is how you bring in legacy devices where you can't change the protocol on the device. That's one way to bring them in. Another block you'll see up here is a thing we call the field gateway. So the notion of proximal networking is important. If you put a bunch of sensors out in an environment that's disconnected or lightly connected or in a place where you put a whole bunch of sensors that have short range networking, you can put a field gateway. Think of it as like a wifi router in your house out with them that can communicate to the sensors and then it can communicate to the cloud. That's what we think of as a field gateway. It can be either necessary for networking infrastructure reasons or because of logical architecture that it makes more sense to design a system that way. And then from there on out you have devices that are connected into your IoT infrastructure. And the point I wanna make before I leave this slide, which I am anxious to do, is that everything that we provide technology wise that's outside of the IoT hub today is available on GitHub. It's all MIT licensed. So the protocol gateways that we have out there, the field gateway SDK that we have out there and all of the client SDKs be them in C, Java, C sharp and some other set of languages I've lost track of. They are all available and people can play with them today without having to talk to us at all. And we're also expanding it to like for the gateway SDKs having support for OPC UA, which is really great for connecting legacy devices and industry 4.0. So it's something to think about as well if you're really trying to take your legacy devices mostly on the manufacturing floor and connecting them to the cloud. That's actually an interesting point. I'm gonna skip off that slide, but I wanted to point out that when I came from outside of the product team to the product team at Microsoft, one of my biggest axes to grind was why they weren't, why the IoT product team wasn't paying more attention to what I care about, which is innovation and product discovery. And then I was very nicely informed from outside of the company actually that our IoT announcement, sort of when we went live with our IoT solution, we went live at Hanover Massey, which is the largest manufacturing conference that occurs. And we went live with the ability to announce that every device on the show floor was capable of connecting to Azure IoT because we had put in the effort to build the gateways to make it happen and gave them away essentially. And so the fact that on day one, we lit up 38,000 devices made me realize we might have made a strategic investment that made sense. And so I had little criticism after that. So here's the things that you can do in building your own IoT solution. I'm gonna burn through a bunch of this stuff, but essentially you can process your data in real time, you can build dashboards, get smart with Azure Machine Learning because if you don't have Azure Machine Learning, you can't beat, no wait, that's a joke. Storing data for later analysis, all sorts of other stuff. And then we also have Azure Functions for this new fancy thing that everyone talks about serverless computing, which is really not serverless because they run somewhere, but it's a great buzzword. This is what IoT talks about, our IoT hub. Since I talked about it, I'm gonna skip over this. One thing that we do have that I think is interesting, and if you're in the space and you're going, I don't know what device I want, I don't know what capabilities I need, I don't really understand all this stuff that's out there when it comes to hardware. We have this thing called the device catalog that we host, it's catalog.azureiot suite.com. You can actually, you can't see it over here, but this is industry device type, tested compatible sensors, built-in sensors, OS, connectivity, hardware, interfaces, manufacturers, cloud protocol, geo-availability, so every potential sort of aspect of the device that you might wanna understand, we have a way to pivot on that data and look at the various devices that we've interacted with or that we know of. I'm gonna say this because it comes up on a later slide, but one of the key values that we bring to the conversation is a history of working with a very large partner ecosystem. Putting something together like this for us is actually pretty straightforward. Putting this together, if you have to go sign 99 two-way NDAs, just to get access to the spec sheet is a little bit cumbersome for a single person or a single entity. So this is something we can offer to the community that is a huge value. And one thing I would wanna point out is that Azure works on all platforms, as Ivan has said, and this device catalog really highlights that if you wanted to work on Windows 10 IoT Core, that's great, but we also have all these other devices and partnerships that use this WinRiver, Yachto, or no operating system at all. So we wanna really make sure that people know that it's not just Windows that is all different platforms that we're contributing to and wanting to help out with. Yeah, actually you'll notice that, what's community to do bring? So one of us brought a Windows computer, but the one we're demoing from isn't a Windows computer, because that's not the one I brought. Oh, a whole golly, I wasn't ready for demo yet, I hadn't teed it up in my brain. All right, so I'm gonna take you through a little bit of a tour and by tour what I mean is I am hoping everything works the way I expect it's going to. This is my desktop, that's a trout, in case anyone's wondering, I get that question a lot. I have to find the right window. So I am going to show you a couple of interesting things. So what you'll see here, if you could see, and it doesn't get bigger on that way, how do I make it bigger? I'm gonna point it out, and it's gonna be a pain. But what you see here is this is a top-level directory in my home directory called ESP. So what I've done, which is a pretty straightforward exercise, is I have literally followed the ESP32 directions off their GitHub page. Their development environment is called ESP-IDF. And so I've created an ESP directory, I've checked out the ESP IDF project from GitHub. I downloaded the Extensa tool set. So Tencilica is the company that actually maps out all the logic for the processor. They provide a tool chain called the Extensa tool chain. It's a GCC derivative for cross-compiling for their hardware. So you can see that that's installed here. Extensa ESP32-ELF. I put it in my path so that I could find the compiler, right? So now I have this ESP-IDF and Extensa tool kit, and the extent of the configuration was essentially, whoops, I can type, and I can make this one bigger. You'll notice I have this IDF path set. So I had to set an environment variable to find the IDF path, pretty straightforward. And then in my path, I had to add the Extensa tools, the bin to the tools. Literally, that was what I had to do to get started. Now, I've plugged in an ESP32 into my machine, into my USB port, and it is currently running as the slab USB-UR device. What you see here, actually I'm gonna start over so that you can see it from, I am going to go get bigger so you can see. So this is that ESP-IDF. That's not big enough for the people in the back. Tell me when. I can't see very well today, because I'm tired. So this is the ESP-IDF path. If you look at the readme, it'll tell you exactly the same thing as what I just did. Basically, check it out and do stuff. Now they have a make system setup that should look really familiar if you've ever built the Linux kernel in the old days. I don't know how it is today, I haven't done it in the last N years where N is larger than I'm gonna admit. But if I go to the examples directory, here's some simple examples, right? Here's a hello world example. So if I sit here in the hello world directory and I say make, menu config. It just keeps getting better, doesn't it? Yeah, it never, it always bites me somehow. There. So it goes through this very handy little configuration menu. If you look at this, the first option is the SDK. So it's gonna tell me that it's found the extensive compiler and it's using Python 2. I can do bootloader config, which is basically how verbose do I want the system to run. In the under security, you can see I can actually select enable secure boot and enable flash encryption. It says read docs first, because once you do this, you can't actually go back through the development cycle without more work. So they don't want you to be surprised as an engineer that you've made a choice that makes your life harder. Serial flasher config, this is where I can tell it things like, that's not where it is. I'm gonna go here. I'm gonna select this. I'm gonna not go there. I'm gonna go here and put it there. It sets itself to a reasonable baud rate, compresses things when it goes up. They have a couple of tools. One is make monitor, which I'm gonna show you, which is really handy in the development. I'm gonna save it just to be pedantic because save your work often. Something will blow up. You can choose how you want the partition table on the ESP32 to work. It has a couple of out of the box solutions. One is a single app with no over the air support. And the other one is, you can have a factory based app with two over the air segments defined so that you can then do over the air updates. I'm gonna leave it like it is for now because the demo is gonna change some stuff later. A bunch of optimization stuff gets done if you go to release, but we wanna see all the stuff come out when we build it. And then in component config, this is where you start getting into the meat of what's included in the app that you're gonna build. So you can turn Bluetooth on and off. First thing to know. That way if you're doing wifi and you don't wanna use the power, just leave the Bluetooth off. Under the ESP32 specific commands or configuration, you'll notice a couple of things. One is you can select the CPU frequency which will affect your power consumption. The choices are 80, 160, and 240. It comes out of the box at 240. You can reserve memory for two cores. The ESP32 actually has two cores inside the chip and you can reserve memory for both. But also down lower you can say, if I can find it, maybe it's not here. Oh, it's on a previous setting, I think. No, it's gonna be here somewhere. I'm missing it. Somewhere there is an option to say lock the app to a single core. So then you don't actually need both enabled and you can save resources. But you can see there's a bunch of other configs. This is the ultra low power processor that is available to run even when you are in sleep mode. But you have to program it with assembly and their tooling isn't filled out yet, so I never enabled that. It's just not worth the work right now. A bunch of other stuff. Real-time clock source. So you'll notice there's no clock which will come up later in my demo. Turning Wi-Fi on, this is the one. Under RTOS, I can say run the RTOS program only on the first core. So if I allocate memory for both and lock it to the first core, I'm wasting memory. If I don't allocate memory for both and I run it on one, I've kinda got the optimal resource stuff going on. Then there's a bunch of other configs. I haven't experienced any, but my experience is anecdotal. I haven't tested, so I'm not sure. That door doesn't like to be opened, by the way. Bunch of other interesting things. One of them being, where's the debug stuff? I think it's under here. There is an interesting debug behavior that they support where you can have the ESP32 when it has a problem dump its core. In one mode, you can dump the core to flash memory. And in another mode, it'll actually ask you to encode the core and dump it over the serial port so that you can grab it and they have tools for then converting it back to a core to analyze on your desktop, which I think is kinda handy. Anyway, I'm going to save this because I think that I haven't made any changes that are gonna kill me. You never know. And I'm gonna say make. For now, I'll just say make. Just for fun, to show you. So it's building all of its various pieces, and it's pretty quick and simple and straightforward, nothing magical going on, other than it's using the cross-compiler to target. Five minutes. There are cross-compilers for you to deal with. Yes, yes, it is. There are cross-compilers for most of the platforms, if not all of them, at least those three. It's a GCC port, yeah, for that. Now it's built, you'll see it says you can run make flash. I'm gonna run a couple of commands at the same time. I'm gonna run make flash and monitor. So now it's gonna actually flash to the device over the serial port, because I pre-configured that all on the menu. And once it flashes, it's gonna invoke the reset on the board and open a serial port monitor so that we can actually see it as it goes by, all the same sort of command. This is compared to the, so there you go. Now it's started and you can see it said hello world. And then it'll reboot again. And there's the output. So this is about the most amazing improvement in development over what we did with the ESP8266 that you can imagine. That was not fun to program. I mean, it was fun to program. It was high effort. This is fun and low effort. We have Azure IoT using MQTT running on the ESP8266. We have it compiling and mostly running here, which explains why I'm tired for this talk. The one place that we, the one thing we have left to connect, which I can show you actually for fun. Let's go now to ESP, ESPIDF, Azure. So I'll take you through what I did here really quickly. Merging to make environments. So Azure IoT C99 library, we use CMake. This is clearly not using CMake. It's using component make files and platform make files and makes infrastructure. So if I go into components, which is where it looks for default for subcomponents it wants to build, you can see I have an Azure IoT SDK and C. If I go in here, you'll see I built the component make file for the IoT SDK. It has all of the stuff that you need to build. I have pulled out a subset of all the various libraries because I don't need all of them. I don't need a MQP, I don't need HTTP and web sockets. I just want the MQTT layer. I'm gonna get the, I'm running out of time sign. So if I do make, and I'm just gonna go fast here, make flash, monitor, actually I have to go up here. I can spell, I promise. So I built it and there have been no changes. So now it's flashing, re-flashing. This will take about a minute and a half, two minutes because it's a fairly large binary. There's not a lot of optimization in the ESP32 build system. So there's a ton of object files that are still linked in and moved to the ESP32 even though they're not necessarily in use. There's a big opportunity in our community to come up with a single set of reliable object file implementations for things like around security that everybody doesn't have to include their own TLS layer every time. So here I am, I'm launching. You can see, you can't see it because I went by too fast, but what you can see, I've exited, what you'll see here, it fires up one of the first things that you see right here, which is interesting, is we're on the LF Events Channel Wi-Fi, we got our IP address, and I invoke an SNTP server to get local time because if I don't set my local time right, generating credentials sucks. So I set my local time and I print out the Portland time and Shanghai because that's where it's expressive, so I thought it was kind of cute. And then I've initialized the IoT SDK and I've created the client and I've set the message callback, which means I'm registering for when I get an MQTT message from the cloud and I've posted an asynchronous message to go to the cloud. And then in the background, when my work loop happens, you'll see I'm trying to connect to this endpoint, which is my MQTT endpoint, and the first thing that happens is it fails. And I can tell you from our experience with the 8266 that this failure is that I did not tell it what client certificate to provide when it did the TLS connection. So the cloud side is saying it's really nice you wanna talk to me, but I don't know who you are. And so that's where we are on the demo. But you can see we've got a whole bunch of stuff built. We'll share this on GitHub. It'll be freely available if anyone wants to do it. We have really good interactions with Expressif and others, and if you have questions, now is probably your time because if I talk anymore, he's gonna give me the, I have no time. Look, he's going to zero. Stop, I got the big red, stop. Thank you guys.