Hello everyone, I'm Wellington Duraes and I am a PM on the Azure IoT SDK team. Hi all, I'm Dane. I am a developer on the Azure IoT C SDK team. Awesome and we are here today to talk to you. Everything you need to know about the Azure IoT middleware for FreeRTOS and how to get small constrained devices connected to Azure. We know that connecting this small devices can be challenging, specially if you are a device builder or an embedded developer. Because most of these smaller devices will be using microcontrollers that have limited processing capabilities and limited memory available. So a very common approach that embedded developers would use is to leverage a real time operating system or an art toss that would simplify tasks. Like scheduling tasks, memory management or multithreading, and in this scenario, free arthaus is a very popular alternative today. We want to meet developers where they are and several of these developers are using free artists today. So until now, connecting a free Artos based device to Azure could be a little challenging. Well, not anymore. Now we're today we're introducing the Azure IoT middleware for freertos and when you use this middleware. You're getting a fully tested set of API's, documentation and samples that would allow you to get a secure MQTT connection to Azure IoT and also out of the box access to IoT hub functionalities like device to cloud or telemetry cloud to device direct methods to win IoT plug and play and also provisioning libraries like the device provisioning service. Let's take a closer look at what this middleware looks like. As you can see here, at the core of the middle where we have the embedded C SDK, which is actually providing access to the all of these Azure features. And here we have the free artcles middleware. Getting all of these features and provide into the user application a set of API's that would make all of these activities much simplier. As you can see here, we also have for all of our samples and reference architecture. We have chosen a set of mekk TLS and socket to make these samples to work. In our cases were using core, MQTT embed TLS and FREERTOS TCP. In or LW IP, but you are free to bring your own network stack. You're free to use whichever works better for your platform of choice. And so, as you can see here. Also we know that core MQTT is a good is a good approach for several scenarios that might not be the best. Specially for scenarios like when you using a modem and you would have a mode in here and likely you would have the MQTT. All of the MQTT libraries also offloaded to that mode. And so you could also leverage this MQTT abstraction to get your solution connected to whichever modem you might be using. So let's take a look at some of these samples available right now to you. Here you see that we have samples working for the ESP 32, and in this case ESP 32 like to nodemcu. So no sensors also with the ESP 32 Azure IoT kit which is still based on the SP32, but this one here has a number of sensors. It has a screen buttons, ladies and the buzzer to help you build and prototype solutions. We also have samples to a number of St Microelectronics. Sports like the L475L4 plus and the age 7:45. We also have some post for the XP 1060 and if you don't have a any of these devices you can still try our middleware by using one of these free or to simulators for both Windows and Linux. In case you're wondering why, why should I be using this solution? Well, there are several advantages of taking our middleware for freertos. First of them, it will be the fact that if you take this, it provides you with faster development because you're going to be leveraging out of the box access to a number of Azure IoT functionalities. As I said before, we have this bring your own network stack, meaning that whichever network stack works better for. Your platform of choice. You can use that with a middleware. And also because we have a number of these samples for several different development kits. That also means learning how to use the middleware is faster as well. Second thing is support. So this is a Microsoft product, meaning that we will be bringing security updates to it and also any new features from Azure IO T will be incorporated to the middleware. Also you get official Microsoft support but and also the fact that. This is open source code, so feel free to look at. Look at the code and modify the code to your needs. If you have to. Finally, there is a big component on cost savings, because if you're leveraging this, you won't have to invest in time on the development and test to get all of your integration to Azure because you get integration to Azure out of the box with the middleware, but also because compared to the current solution which is using the C SDK with free arthaus. If reusing the middleware. It would require a smaller footprint, which means less RAM and run requirements, and that means you can save money on your bill of materials. So that makes all of this solution much more attractive to you. Come from a user experience perspective. We actually have these in two different repose. We have the first one that we call the main repo and here you will find all of the middleware libraries and this will have no external dependencies. So this is at the core of the solution. In a separate repo, which is the samples repo and here you will find working samples and in order to get these samples to work we have some dependencies on. Well first and foremost the middleware libraries but also dependencies on free or task or MQTT LWP and embed TLS. OK, so enough with a slide show. Let's bring Dane back because this is demo time, Dane. Beautiful thank you Wellington. Alright so here's what we're going to go ahead and do we're going to go through the different GitHub accounts or repost that we have so we have the main repo with the with the source code and that we have the sample repo. So go through that will go through documentation that we have both on the on the repo and on the source code itself and then we'll go over acquiring the middleware. So how do you actually get it? How you integrate it for the next point? That being building with CMake and then we have some guidance on how to. Port your different stack, so TCP, TLS, MQTT, that kind of stuff, how you get your own into that, and then we'll also go over the demo so we'll actually run a demo on STM 32L4 plus so. With that let's go ahead and get to the GitHub repo. Alright, so here we have the source code repo, so this is where all of the actual functionality lives. So here we have a top level README which describes what the middleware is doing, and then down below we have the structure. So we have a call out for the samples repo that you can then go to and see all of the samples that we have available for these different boards and simulators. We did have some some directions on code style which if you want to help contribute which we welcome. You can then run. Some kind of code style script in order to make sure their conforms. And then we have a AC make. How to sew? How is RCM structured? What things do we require from you in order to build our middleware and then the available target that you can then link to in your CMake projects. We then have a guidance on if you want to just use the source file, so let's say you're using maybe makefiles or some kind of IDE specific build system. We have guidance here that will call out all the specific things that you would need to either build, compile forward, include yourself. So configuration files, free artists, configs, all that kind of stuff. So if that is very particular for your build system, please feel free to check that out. We didn't have porting guidance as I mentioned, so we have TCP and TLS so that layer is up to the user to create and manage. So the porting that we have for the MQTT requires a sender ecv basically from the MQTT layer down to the TCP IP and TLS stack. So once you provide that for us then the MQTT we handle and we will send those messages along and then the basic contributing got into the bottom. And from here you can access the source code documentation via this link here and we have full doxygen support, so if you want to see all of the API's you can go here, click on let's say the Hub client, which is probably one of the the files that most people would use most often. You can then go through and just see let's say if I want to check out the connect. So what does that require? We have a clean session flag. If there was a session president etc. So you can go through here. Feel free to peruse. Those and see how all these APIs combine. And then with that, that's basically the source code repo. We separated out the samples repo just so that if you're using, let's say the source code, you don't then pull down all of all these different boards specific things that you might not need for your project. So over here we then have the samples repo. And here we have in the libs you can see that we have the middleware for free artists actually some module, so that is the only kind of external dependency that we have. But you know it's it's necessary for. For the samples. So here we have various call out, so we have two sets of samples, one for IoT central and one for IoT hub. If you want to central we then have this BL 475 E sample for you two to go ahead and use. Otherwise if you want to use IoT hub directly which combines provisioning and IoT hub, we then have several other samples for you to check out.
So we have ESP. 30 twos and XP mtes various BL4. 75 or the L4 plus, which is what we're going to be doing today. So we got the L4 plus here and then H7 Discovery Board as well, along with the PC simulations. So we have Linux and Windows if you want to do that, we have some additional guidance on how to run these samples, so we have PNP specifically called out, which makes the development process for embedded devices a little bit easier. Sort of high level version of PNP is that it allows you to declare what the capabilities of your device are and. With the service knowing what those capabilities are, it then makes the integration and the interaction with that device a lot easier by kind of taking care of some. Some sort of packaging data concepts, so we're going to go ahead and do that PNP sample today, so I'll be able to jump into that a little bit more specifically, and I should call out basically for each of these samples, we have links to each of their readme, so each one has a separate readme. So here, since we're doing the L4 plus, I'll go ahead and hit that and we have a full walkthrough of things that are required, some kind of prerequisites of C Make a ninja build system arm toolchains. Things like that actually having an IoT hub setup or DPS.
So if you're new to this we have guidance here of how to create an IO T hub. And let's say a a device provisioning service instance. I will have assumed that you have those created, but like I said, if you need some guidance on how to do that, go ahead and feel free to click those links and check that out. But I will be creating an individual enrollment in DPS today with a sosky. I will then use that in the sample. It will allocate that device to A and IoT hub that I already have created and the device will then connect to that IoT hub and then interact with it with the PNP concepts that I mentioned before. If you're on Windows we have specific guidance on how to.
Set that up and here we have guidance on how to get the middleware so it's a basic Git clone and that we have a one level deep of a of. Submodules so called out here just to initialize that. Middleware code. And then here we have some guidance on since we're using the L4 plus, we have Wi-Fi on board, so there is a specific place where you need to input your Wi-Fi parameters and that we have device ID, host name and symmetric key for hub, and that if you're using GPS then an ID scope or registration ID into the symmetric key as well, which we will be using today. And a nice thing that's that we have set up here is that the build system for all these different devices, whether using one of the St boards or. The XP or even the Windows and Linux samples. We have a very similar build process for all of these samples, so you use some kind of build generator and then we have a call out for the vendor, the board and the build folder that you use. So if I can actually go here and I'll duplicate, this tab will show. Let's say we're using the Linux since that's probably the most different. If I Scroll down. You can see that we have basically a very very similar build process, so calling out PC Linux and then build folder so you can build all of these if you really wanted to,
you could build them all in parallel and have a build instance of each one of these in a very similar way and at the bottom of each of the actual boards we have callouts for total code size, which is really nice, so you can see I'll pull up another one, for example for the NXP board. We have total sizes here, then here for the STL4 plus we have middleware library usage for Hub and DPS or just Hub only and what that requires in flash and RAM and then the total size of the binary. Since we are only a part of the total build, there's a TLS stack. There's the board specific code. There is what I said. TLS, TCP, IP and the MQTT library which we have. Uhm, so with that I will go ahead and start the build process for the L4 plus, which I believe I was right here. So I'll pull up vscode. We're going to use Vscode today. And here's basically how the repo looks, so you have a demo folder with common files, different projects which are basically the different boards. So here you can see ESPN XP PC and St. We then have the samples so we have a basic hub sample, so not using PNP, the getting started guide which is the IoT central code that I called out before. And then we have PMP, which is what we're going to be doing today. So this PMP code. Uhm, I'll show the basic flow of how this kind of breaks down, and then we'll go ahead and build the whole the whole project, so. There is some sort of overhead that you can you can look at inside of the inside of the board specific folders in the main, so setting up board specific things. You can check that out, but otherwise, once all of that board specific stuff is set up, then the sample flow is the same for all the boards, so we use the same sample file. All running within a task, so there's that whole setup process. We then invoke some task with using free artists and then all of the different boards will run the same code as demo here. So going over how that is all set up so we have the PRV Azure demo task. So it starts. Here it goes through Initialising middleware middleware code.
It'll set up the network credentials so it will. It will connect to either provisioning or. IO T Hub via the TLS and TCP IP connection and then later once you then. Connect to Io T or IO T hub or provisioning. It will then call the MQTT connect via our calls, which you can see right here. So we will make that MQTT connection. As I mentioned before, we have the the connection between the MQTT and the TLS TCP IP. Is this idea of ascendant erect fee? So in this case we're using the TLS socket send from free artists plus TCP and then record V as well. So once you pass the network context, anything that's necessary in order for the network to work, you can pass that as the network context. You then have this send in the rec. V. This network context will be passed back to the TLS TCP IP stack. Whenever I send in a wreck, V is called and once you have that, you then pass that into the initialization for the IoT hub client. Here. As you can see there. So once you have that setup, you then call the initialization and all we require is the Hub client, which is the actual struct that holds all of these IoT hub concepts. Host name, device ID, any options we have an option struct, so if you have like a module ID or a model ID you can use those in this case. We're gonna be using the model ID since we're using PNP,
so this is actually a thermostat in this case and then we will have a MQTT message buffer. So when you when we receive MQTT messages, we will use a buffer that the user passes to us in order to manage those those messages. A get Unix time in order for us to generate SAS keys, we require a Unix time function so the user passes us that and then we have the transport. Like I said, it's this this then that record V which will pass empty down to the lower layers and in this case we're going to be using a symmetric key. So we ask the user to set the symmetric key and once we then connect it will then create the symmetric key and authenticate with IoT hub or provisioning depending on which one you're then connecting to. And going on the feature list, we have commands, we have properties and within properties we have various different concepts, but in this case we're subscribing to properties, so anything that the. The service would invoke. We then receive on this properties these properties line. The command is the same thing we are subscribing to a certain topic from the service. In order to receive commands which we can then handle on the device and some kind of response back. And then here. So those are that's basically setting up the subscribed topics that we want. And then in this four loop here, we will continue to send telemetry messages. Here we basically just require a buffer. The user populates along with the length and the cost here and then in the process loop. After that we then will receive any messages and process any published messages from IoT hub. So in between some kind of call to, let's say send telemetry or maybe you're sending some kind of command response, you should be calling this process loop in order to receive any messages that might be coming in. And once that's done we then delay between publishes and we will continue to do this in perpetuity. But although we have that in a foreign infinite. For loop, we've also show how to properly breakdown all of the different connections and concepts. So here we will unsubscribe from a different topics which you're fully willing to do. Or sorry, fully able to do and then here we have a disconnect call which will disconnect the MQTT layer and then after that because the user is the one that controls the TLS TCP IP connection. There's a separate call to disconnect that TLS connection as well,
and after that we then delay. And you could then come do the whole thing over again. So that's basically how the sample breaks down. I know it's a lot, but it'll make sense once I think we run this. So here if I go back we have this call here. I have this queued up. There's a slight difference I have because I'm using a newer version of the ARM GCC toolchain, so here it's the same thing. Dash G vendor St V L4 plus that we have the build folder that we want all of our code to be deposited in and then we have a compiler. You can see I'm just using the GCC arm GCC 10. Compiler here and then. I'm also setting the toolchain path for the object copy functionality, but other than that it's exactly as as stated in the README, so I'm going to go ahead and hit enter. What you'll see here is we actually will fetch all of the necessary dependencies during the build step so you can see we don't have any dependencies on free artists within the repo, so we don't have any submodules that you have to worry about. This is all done via the build process so you can see it's. Cloning free artists source code. This could take awhile, but you'll see that it's pulling down for yard toss. It will also actually pull down the board specific functionality as well. So any BSP code it will pull down, which is really nice because it'll it actually uses, in this case STS functionality. But if you're using XP, they also have GitHub repo's of CMake helpers and board specific packages to then easily integrate into your projects. Alright, so once you have all of the build files then generated, you'll be presented with this screen here and you can see the build files have been written to your build folder and inside the build folder you can see in this depth you have that free artist sources and you have the STM cube L4 project which basically has all of those device drivers that I had mentioned. So once you have that, you then have everything necessary for you to build the project. So from there all you have to do is do CMake build and then you give your build project which in this case is the L4S5I so hit enter. And it'll use Ninja to build your whole project. And we will wait for that to build just so you can see. That finishing off. And once this is done and then is linking the executable and from here you can then drag and drop your your demo onto your board. But first we actually have to do the demo configuration. So here you can see under demos projects St L4S5I config at this demo config and from here you have to set up your IoT. Or sorry Azure IoT specific parameters. So in this case we're going to be using provisioning. So we need the endpoint which we give. This is a global endpoint that all people hit. You then have an ID scope for your provisioning service, the registration ID, and then we're going to be using a symmetric key today. So we're going to need a symmetric key for this device as well, so we're going to go ahead and do that before we drag and drop this onto our device. So here I am in a DPS instance here. I'm going to go to manage enrollments. And here I'm going to add an individual enrollment. From here mechanism, at least for demo purposes, we're going to use a symmetric key. It just makes a little bit easier, but you can use X509 or any other option that we have. Their registration ID will go ahead and call it deep dive. And once that's done, you can then see you can select your IO T hub that you want it to be assigned to, so this is the hub that I have chosen. And from here goes the all options we need to hit save. So this is going to save that individual enrollment and from here you could then click on it. And we should have a primary key, which is what we want, so we're going to copy that. Come here to symmetric key. Paste that there and then the couple other items that we need are the registration ID, which in this case is just the name that we gave it, so deep dive. Save that. And we also need the. See Overview we need the ID scope for the provisioning. Service, so here we're going to. Paste in ID scope. So with that you then have your endpoint ID, scope or registration ID and your symmetric key. So from here you can then rebuild the project. Perfect, that's all done, and since I'm using WSL, I need to then find. Where this is located? Uh, so let's see. We have our build folder here and at this point it follows the same directory structure as the actual source code, so demos. Projects Ste. L4 plus and here presented with LF files and binaries. We're going to use the binary, so with that I'm going to plug in my device here. See. Should have, Yep, pops up there and then. I'm also going to need a Wi-Fi network. Actually, I forgot to mention that. So at the bottom I'm I'm using my phone to hotspot, so I'll make sure to change this password once I'm done here so that people can't use my Internet access, but I will turn that on right now. Personal hotspot that should be on and from here I can then drag and drop the sample PNP binary here onto the device so you'll see it copied over. I'm going to use termite to see the output from the device, but you could use any kind of serial. Serial reader that you might like. We have directions on the readme of ones that are that are available. And so from here we should see some output. At some point. So we had to restart this. Here we go. So Wi-Fi module initialized its first creating a connection to the DPS instance. As you can see there. It is then establishing an MQTT connection. It will then ask to be provisioned. And once that's done, the service will then give the device a payload saying this is where you should be connecting. It will give the IO T hub, and from there it will then create a new connection to the hub right there. And so from here I have my IoT explorer here all then refresh and I should see deep dive here with IO T plug and play components enabled. So I should be able to go and use like I had mentioned before. A nicer interface in order to interact with the device so I can set a target temperature. Let's say I want it to be 40. Really hot I then update that I refreshed and it will actually submit back to the service saying I acknowledge within HTTP like code. I acknowledge and I accept that that new value and then here in telemetry you can hit start and you should be able to see the telemetry coming in. So it should say I believe temperature and then it'll say 40. There we go and we also in this case for this PNP device we have a command so we can get a Max min report. So let's say we change this temperature to be 41. Updated if I are the desired property. And then says 41 and once we invoke this it should give a report of let's just use today. As you said, bunch of basic values here. It will invoke and then here in the payload you can see the maxmin, so them in temperature at start at zero. So that's going to be the minimum, the Max temperature being 41, and then the average running temperature. Since the device booted. So that's basically the the whole breakdown of the sample. Like I said, you can run this sample with any of the devices that we have in the catalog, or at least in the README for that repo. So you could do it for the PC, Linux, Windows XP Board, or the ESP 32 and the build process for all of those. Will be very similar if not identical. It's basically the samples. I hope that gives some better information on how to use the middleware and what this offers. And with that I will kick it back to Wellington. Awesome, thank you Dan for this this walkthrough. I think that was pretty helpful to help folks understand how to get started with our samples. Again, if you want to learn more, please you have the link down here to show you where to find more resources, where to find all of these samples that then was showing and instructions for all of that for all of their dev kits we have available. If you have questions or if you have issues, by all means we have the GitHub. Issues, so feel free to file up and create another issue for us. We'll be glad to take a look at that for you,
so at the end I think the the main action that we are asking you to do is to take a look at that. Give it, give it a try, take a look, see what you think and let us know what you think. Perfect, that's it. Thank you all. Thanks a bunch, bye.
