 All right, well good afternoon everybody and thanks for joining me today My name is Brandon Sattram, and I am the VP of developer experience engineering at blues a wireless IOT product company And to get things started today I want to talk about one of my favorite IOT topics and that is purgatory specifically the prototype or proof of concept purgatory that we often find ourselves in as Builders as developers now we all know that hardware is hard the firmware is difficult But that in and of itself doesn't really explain why 70 for 75 percent of IOT products take twice as long as estimated and many and that being Cancelled even before that pre-launch stage before a company sees any value from that effort And often it seems like the reason why this happens is because of the time It takes us to get a POC off the ground to go from that point of idea to something working and running in the field Even before we consider a thousand or a hundred thousand or a million units, right? It's often that first second or third device that we have issues with that slow us down So consider an example So let's say you're looking to build a device to monitor outdoor outdoor conditions on a farm So for your POC you want to start with a garden so you buy the hardware you You need and you grab your favorite MCU or single board computer But this project is going to be outside and away from Wi-Fi So you're also going to need a cellular modem and you grab one from quick tell or you blocks or you get a Nordic 9160 dev kit and you got the pieces that's great You've assembled this bag of parts as it were But now you need to figure out how to program the modem using whatever flavor of AT commands the modem vendor uses You're going to need to source a SIM and a data plan from somebody Then you need to figure out where to send that data how to communicate remotely with your product Oh, and if needed where to store certs how to encrypt your data and then figure out transport Oh, and you also if you want to do firmware updates You're going to have to figure out how to do a DfU back to the device and there's a lot So alternatively rather than doing all those things yourself You could sign up for an IoT platform where all of those decisions are made for you and what you tend to give up is flexibility and control For that for that trade you right you take the MCU the language data limits Pricing model whatever you get and you don't have a fit you follow the guardrails set out for you and In either case what we engineers have to deal with in this space almost more than anything else is complexity It's a word that I say a lot that we hear a lot the reality is that it's hard to do the work that we do and Any time that I think about complexity I think about a quote from my boss and our CEO at blues Ray Ozzie and that quote is complexity kills It sucks the life out of developers. It makes products hard to plan build and test I'm guessing all of us in that in this room feel the truth in that statement because we've lived it We've experienced it in one form or another the funny thing about this quote is that this is something that Ray said long before Founding blues and really when he said it he was referring to the software space He hadn't yet seen the pain that those of us that have worked in hardware for a while have had to deal with and it is doubly true for us We are a wash in complexity in the IoT space and over the years We've tried to come up with ways to manage this right? We've tried to figure out ways to to deal with that some some you know One of the ways that we've done that in the past is by having IoT platforms by setting up guardrails that we That we use to navigate to make things easier, right? Another is that we try to standardize processes We try to figure out we all come together and try to agree on the way that we're going to do things in The hardware in the firmware space and there are some good examples of this in the early days of Arduino's rise There were a small number of pin layouts which made it easy for other vendors to create shields that can plug in easily Into a compatible Arduino to add additional capabilities We're all familiar with this part of what led to the growth of the Arduino ecosystems rise was that for many years This pin layout the shield ecosystem was relatively consistent But I would argue that the Raspberry Pi is an even better example because with that 40-pin double-wide header The Pi created inadvertently an add-on ecosystem that was so popular that that same header can be found on almost every competing single-board computer out there today and Then there are some examples where we made a solid attempt, but the results were mixed and we can look at peripheral connectors Here's an example in 2013 seed studio introduced the humble Grove connector a four pin JST that could be used to connect serial i2c and even in some cases GPIOs with a huge number of Grove compatible peripherals There are hundreds of these things of these things that you can buy that do almost everything that you can imagine The problem is that that you know as our boards and our products get smaller that that that Grove JST looks pretty big So other vendors like spark fun and Adafruit introduced their own variant using a smaller JST spark fun calls There's quick and Adafruit calls. There's stemma Qt two different names same connector So are they compatible kind of for most applications you can use breakouts from spark fun and Adafruit interchangeably But there actually are a few edge cases especially around whether the peripheral has a logic level shifter built into the actual peripheral itself and a regulator so that It can be used with both three volt and five volt logic So you could potentially buy one of these boards plug it into a different connector and you've burned out your project And you'll figure it out when the magic smoke appears or not Another example of where we've gotten mixed results to date is in the world of firmware updates So specifically firmware updates perform remotely or over the air We spent a lot of time in trying to solve this problem in SDKs and platforms But has anybody really solved this problem in a way that doesn't force us as developers to either give up control Or have to embrace dealing with the complexity ourselves And that's what I want to talk about today a little bit about the current state of OTA DFU and the two most predominant approaches that we have today And then I want to introduce a new third way something that we at blues are calling outboard DFU And I'll do a couple of demos along the way first Let's just kind of take a look at the current state of OTA DFU Now when I say DFU, I never assume that acronyms and the TLIs that we throw around are known by everybody So DFU stands for device firmware update This is simply put just the process of getting a new piece of firmware on a device By laying down a binary with an updated program in some known memory address that is physically it And in all cases DFU relies the existence of some sort of bootloader to be programmed The bootloader can be a small piece of code that's stored in non-volatile memory or can be a soft bootloader But the bootloader exists to do two things one is to launch the main application on the device And the second is to provide the capability of updating that device's firmware if a new binary is available Now for the latter capability devices require There's the bootloader itself has to be entered right you have to actually place the device into its bootloader mode So for example, if you've ever flashed your firmware to an STM32 device using your Arduino IDE and a USB connection or platform I own a USB connection and not a programmer You've actually done this by placing ST devices into its bootloader by manually pressing the boot and reset buttons And hope that you get them in the right order and that actually does enter the bootloader properly Alternatively if you've used an ST link or a J link or another programmer You've gotten to skip that process because those programmers have a hard connection to putting the device into its own bootloader for you So that's the DFU process That's DFU OTA is the piece of the puzzle that stands for over the air And it means the process of delivering new firmware to a target device over a wireless connection So not using a programmer like I just talked about or not using a USB connection now often in this in the early days of OTA DFU we talked about Bluetooth Bluetooth was one of the early ways We talked a lot about doing this with either Nordic or Sylab devices using their mobile apps That has tended to be sort of the early way of doing OTA But it doesn't have to be Bluetooth to do OTA DFU shipping a binary over cellular or Wi-Fi is also over the air Now in a world where nearly all solutions are cloud connected OTA DFU is it's a table stakes feature, right? None of us would build a product in the field these days and put it in the field without providing some remote way of updating Updating that capability updating that firmware. I hope we wouldn't at this point Like we've seen enough botnets in the wild to realize that we should probably have the ability to patch our devices If there is a security issue And but even in today this it's still complex, right? They're really only two approaches available to us when we actually want to reach into a deployed device and Do something to it to update its firmware The first approach is something that that I like to call OS DFU or operating system DFU in which a Vendor solves that DFU problem end-to-end with their own kernel and their cloud service So the vendor in this case and it's going to be an IOT platform Solves all of the complexity of DFU for you and they provide a cloud console for updating uploading firmware And they facilitate that firmware delivery process to devices to one device or a fleet of devices all at once Now on the device side because there's two pieces to this right There's the cloud piece and then there's the actual physical device piece on the device side The vendor provides firmware that will actually manage that process as a part of their kernel or RTOS And that manages every piece of retrieving firmware from the cloud service Placing the device into its bootloader and then updating the application or RTOS firmware on the device Restarting the device so they can enter its new operating mode The advantage of this approach is that it's completely hands-off for the developer if you opt into one of these platforms You get this ability to perform DFU for free It is included for you the platform takes care of everything from delivery to on-device updates Now the disadvantage of this approach is the lack of control on the part of us developers right in order for the vendor to make this experience hands-off they have to place very high guardrails in place and Dictate a narrow set of supported hardware Programming languages and even IDE right you don't get that choice of bringing your own microcontroller Bringing your own cloud service in this sort of an environment to get the benefit of OSD If you you have to yield some of your freedom as a developer to the vendor Now the easiest way to know whether or not a vendor uses an OSD OSD If you approach is to look at their hardware support for host mcs So do you have to use the hardware that they sell in order to and that they manage in order to use their Firmware as a excuse me as opposed to an off-the-shelf kit or a chip based on your skillset or preference that is going to be OSD FU Now on the other side is Cooperative DFU and in this approach both the vendor and the developer have to complete some piece of the puzzle They have to cooperate in order to perform the update process And usually the way that this works is the vendor hosts that firmware binary for you in a cloud service It provides that binary for secure delivery to a host and then the developer We then have to write the actual code to update that host and put the new binary lay the new binary down Alongside the running application in real time and restart the device Now and this is a this is an approach that differs a lot depending on what form of wireless protocol You're using for example if Bluetooth is your update mechanism the server that actually hosts the binary is a Bluetooth capable device like a phone You download it that must be brought within a few meters of the host in order to initiate an update and on the target The process varies from one MCU vendor to the next and wireless communication protocol But the you know every every product will follow a similar approach Which is getting some sort of notification on the embedded device that firmware is available receiving that firmware from the server one chunk at a time and placing that firmware in a temporary location in flash Validating each chunk or the entire binary after it's all been streamed in Copping that complete firmware to an appropriate location restarting it and now we're off and running again And if you're not using Bluetooth for OTD if you you're likely using something like cellular or Wi-Fi and the server in this case Is very similar it's a remote cloud service that hosts and delivers the binary But beyond that on the host side on the actual device side The process is exactly the same whether it's Bluetooth or whether it's Wi-Fi or cellular Now this is all important because in the case of my company blues OTD if you consist of two key components I'm going to demo these for you in just a moment before we talk about the third form of OTD if you a firmware update It starts with a note card So the note card is a hardware product that we provide to customers It is a device to cloud data pump that comes in a 30 by 35 millimeter package With an m.2 connector and it can be incorporated into any design or field replaced It comes in Wi-Fi and cellular variants that are project swappable and the cellular variant includes 500 megs of data and 10 years of secure cellular connectivity Included in the cost of the device or you're not paying for a monthly data plan in order to opt into cellular Now as a data pump the note card is meant to be used with the MCU and host of your choice You can spik you can pick an STM 32 ESP 32 or even an 8-bit Arduino Right any embedded device that can print and read strings can talk to the note card and the note card speaks 100% JSON so you're not writing AT commands against a cellular modem In dealing with their specific variant it communicates over Serial or I squared C and you can also use any embedded language that can print can read and print strings right whether it's CC plus Plus Arduino tiny go rust and circuit Python Now on the cloud side, which is where the OTA D a few piece comes in That's all facilitated with a very thin piece of middleware that we call note hub.io No hub exists to basically provide a couple of capabilities that are relevant One is the data routing side is specifically just there to help our customers route data to where that data actually needs to go We are not a platform And so when you're taking data from a temperature and humidity sensor and you need to get it to AWS We saw that messy middle piece of getting those devices talking together But we also provide the firmware update capability, which is something that I will talk about here in just a moment What we do effectively is the note card can provide secure firmware updates not only for its own Firmware there's an STM 32 L for R5 a low-power chip on the actual product itself But can provide the binaries to whatever embedded program that you're actually working with so let me show you a demo of this right now And as I do that What I'm going to be demoing today in a couple of different variants with a couple of different MCU's is This is the Wi-Fi version of the note card that is actually sitting on a Development board a development kit that we call note carriers And so because the product is on an m.2 connector We recognize people aren't going to spin a board just to try something out for one So we have a couple of different variants of these note cards one that has a feather compatible slot on it So any feather microcontroller you can slot in there and work with and the one that I've got on here right now Is the good old ESP 32 the early the ate a fruit ESP 32 has a specifically and That is plugged into the ESP 32 and I've also got it plugged in over serial and so let me Switch back here And I have pulled up Blues.dev is our developer docs our tutorials, but it's also the place where we host something called the In browser terminals So one of the nice things about modern browsers is that if you're connected to Microcontrollers over USB serial you can with certain tools and utilities have the ability to actually talk to those devices Over the browser without installing a custom tool chain and that's really nice And so in our case I have a USB connection to the note card So I can actually send commands to the note card before I demo the ESP 32 side of this I did want to show you briefly when I talk about the note card speaking JSON exactly what that looks like and so Every every request made to the note card looks exactly like a valid JSON object And there is a set of complete docs that show you Exactly how to communicate with a device, but what I can do is I can actually find out what is its connection What project on note have am I connected to using hub dot get I can also do a hub dot set to actually change the product That I'm connected to but when it comes to actually sending data I can do something called a note dot add and the way that this works is I can send any arbitrary JSON to the note card itself and that ends up in the cloud service and ultimately on the other end in your ultimate Cloud service and so all I need to do in order to do this is pass in a valid JSON body. I'll do a very simple one Canonical developer example foo bar. I'll add that three or four times And you'll notice here that I'm queuing notes to the note card when the next sync actually happens I can see in the status message at the top that I did my last sync 23 minutes ago Not quite time for me to do it yet because I haven't actually initiated a sync But what I can do is also query the note card to find out, okay What do you actually have loaded on you? And so if I do file that changes if I'm looking for it in the up my go here file that stats, excuse me I can see That they are not there. I must have already done the same. I did this thing before I could do it Here I'll go to it again And I'll do file that stats and I'll see now I've got these two files that are actually sitting here waiting the note card operates in a store-in-forward model You can be continuously connected, but if you're building an application that doesn't always need to be connected Then you can queue up events queue up notes and then send those later on down the line now on the on the actual cloud side If I go into my project here at note hub.io I can see that my device is connected that I just sent in a couple of events And then I can route those out into any location that I might prefer on down the line But let's get back to the actual firmware piece I shared that with you briefly because I wanted you to be able to sort of orient what this looks like when I go into the ESP32 specific example, and so I have here in in VS code a very very simple ESP32 application. It is an Arduino application And all it's doing basically is waiting for button presses and then sending notes But you'll see that in my in this Arduino application. I'm sending in JSON strings just like I did in the in browser terminal I'm configuring my connection to the device. I'm checking whether or not there's a DFU that is available using the DFU status API And then I am basically waiting for button presses to either perform a sensor measurement Or to check for new firmware, and then I'm doing the note add to send data into the cloud service But that's not really the relevant piece for this demo The important piece is that I am also because this is an ESP this an ESP32 that's using the cooperative DFU approach I'm responsible for performing that firmware update. So in order to do that I have a second I have a second file here that is actually using the ESPIDF's Partition system to pull down firmware updates from the note card and then put those on the device one at a time And so I'm not going to belabor this code because this session is not about how to perform ESP32 firmware updates using ESPIDF You're welcome to check that out if you want But the real point of this demo is to show you everything that I have to do I basically have to CRC check every chunk that comes along I have to pull to see whether or not a DFU is ready from the note card If the DFU is ready for the note from the note card I then go and get one chunk at a time in 8k increments I validate the CRC on each one of those increments And then I basically create boot and running partitions on the ESP32 itself Stream in that new binary once I've got it and then reset the device, right? And I'm getting 8k chunks over and over again as those are coming down the device What this all comes down to is that in order for this to work in ESP32 I've had to add 311 lines of code that do nothing but facilitate the firmware update capability and that's going to be Important in just a second, but once I built that once I've actually written this application I've built the binary the way that the note card piece of this works is that I can go into The note hub UI into my project and I have the ability to pull up firmware binaries And so you'll see here that I have this ESP32 Co-op DFU. I have another binary here. It is a 282 the ESPIDF is huge a 282k binary that I'm going to ship down Over the note over the note card that will then be delivered to my device And so the way that I perform that update is I will select my device I'll choose host firmware here. You'll notice that I'm running version one zero zero. I want to update it to one one zero I'm gonna come here in the menu. I'm going to select the update option I'm going to choose this one one zero version. I will click apply and at this point the note card The note hub now will tell the note card the next time it syncs that a new binary is ready And so what I'm gonna do is I'm gonna turn on Special hyper programmer mode that prints everything that comes across the terminal So you're gonna see a lot of stuff stream across What I'm gonna do is I'm gonna manually perform a sync And as that sync happens The note card will then be informed that a new binary is available and it will start downloading that binary now It doesn't halt the running of my actual application It's just delivering the binary on behalf of the device and you can see I saw one very quickly You can see one come across right so it's getting that binary one chunk at a time What that what it does basically is it places that binary once it's reassembled it places it into the flash on the note card There's room on the note card for about a meg in terms of the binary that you can pull down to then put on the device It's grabbing that one bit at a time. You'll see here is the DFU user the migration messages come across It's gonna reassemble that and then it's gonna let my host know that a binary is available now if I refresh the browser here I can see Well, I hasn't done a sync again. Let me do another sync here Restarted oh, it's trying to do that. It's trying to do it a different hold on So I'm seeing ready to install firmware now I'm not gonna show you the the device and the DFU process yet on this demo because I want to save it for the next one but what I did the reason why I wanted to share this is because what has to happen then when that binary is delivered is that my host my actual ESP 32 application then has to go in and do the rest of the heavy lifting and I have that 300 lines of code that go and do that for me so One of the most important things to really think about when it comes to cooperative DFU is that my actual application Code it was only a couple hundred lines. It really wasn't that much to it It was a very small part of all the code that I had to add in order for this process to work Even with a library or a helper class That facilitates the transfer process the app itself has to know a lot about how to update itself in order for that process to be useful And so in general the strength of cooperative DFU is that the developer has complete control You can use any host you want you can use any cloud infrastructure. This is completely within your control And there are really no gear and there's no guardrails beyond whatever those guardrails are Imposed by the silicon that you use right whatever their bootloader process might be So the drawback however, and you saw this is that you're because you're responsible for handling the update You have this manual and time-consuming process of having to write the firmware update code as a part of building your application But if it changes introduced it bricks that bricks your device the update mechanism is running in your app code You break the app now you can't update it You have a device that cannot physically be updated in the field Which means that the benefit of OTA DFU is lost when you introduce a bug that causes the device to no longer be functional So with the two approaches that I shared it might be possible to think okay Well, we have two choices we either give up control to get hands-off DFU or we keep control and add a lot of time-consuming work right we can either Have control and choose the parts and products we want to work with or we can get a hands-off DFU approach and I really want to I want to introduce the third way because we believe that You can actually get hands-off hands-off DFU without sacrificing that choice And that's through something that we have blues call outboard DFU Now use the word outboard here like an outboard motor on a boat And it's a boat that is attached to but not an integrated part of the boat itself It's effectively lashed to the craft and it can control it and propel it when placed in the water But it can also be removed or replaced without damaging the boat itself It is not it is an integral part of the system But it's still a boat if you remove the motor just a boat that doesn't move and move through other other mechanisms Right now outboard DFU is a capability that we released earlier this year as a part of our product set And it provides the benefit of being able to use the note up for hosting and delivering binaries like I just showed But it also allows you to use the note card to be the process to be the thing that performs an update process So all of that code in that ESP 32 example are gone and are replaced by one piece one JSON request I'll show you in a moment that makes that process a lot easier You're then opting in to a different update approach and the best part about this is that we can we cannot you can do this And we also allow you to preserve that choice of MCU family So there's a lot of ability to continue to use the products that you're used to and the reason why this is Possible today and the note card can perform this is because there's an increasing number of MCU's that have been introduced in the last decade That are shipped with their primary bootloader in ROM and that are unmodifiable by any user operation so on these devices which includes all modern ST micro electronics devices and Expressive microcontrollers when you assert the reset pin ST micro electronics and expressive They know they know they load their ROM bootloader It enters that bootloader and it can load and execute code from a variety of sources including flash ram UART USB iSquared C or spy the ROM bootloader's behavior is controlled by probing the IO ports on the device checking to make sure that boot and reset are asserted entering that bootloader and then Streaming in the update and then resetting the device from that point and that provides new alternatives for us to actually lay down Firmware so putting it another way Using this approach you can defer the DFU process to another device in this case the note card and let that handle up to any of your hosts But you preserve the ability to then choose the device that you work with and the way that this works in our Ecosystem is that it's really two steps on the part of the engineer One is that you make a physical connection between your MCU and the note card via its auxiliary pins So what this does is it allows the note card to physically assert the boot and reset buttons to place the device into its bootloader And then it streams that over using the RX and TX pins using this secondary UART that we have on the device and then second using the note cards JSON API the essential command the essential thing that you send is card.dfu the name of the microcontroller that you're working with STM32 ESP Nordic MCU boot which I'll demo and just a little bit and then you have everything you need to actually then work with this process in the field Now I recognize that we are talking about this is a hardware change when you're building a product And so when it comes to giving it a try This is actually something that's already supported in the hardware that we sell and the products that we work with And it also it works with ST devices Espressive and Nordic the 52 840 as well This device on the lower left is the dev kit that I was using for the last demo that I'll continue using for the next couple of demos And it works in that Avenue uses an ST the kit that we provide has an STM32 device called the swan That I'll demo just a moment. It's in a feather compatible form factor There is also the STM32 f405 that works with this as well works with a Nordic Nrf 52 840 I'll demo that in a moment as well as the micro mod ecosystem So if you're working with spark fun micro mod Their new boards actually support this outboard DfU capability as well So you don't have to use the hardware that we provide. So let's let's actually take a look at a demo of this Because this one is a lot more fun. So I'm going to start by actually removing My device here so not messing anything up specifically I'll delete that very briefly I'll come back in here and I am going to do a secret factory reset on my device and I will show you I'm going to take the power out I'm going to go to another one of my demos here and what I'm going to demo here in a moment is basically going from Arduino to a Zephyr Artaus application using outboard DfU So I can use this approach to swap between Artaus's to swap between programming languages Completely whatever it whatever it is. I might wish to do so. I'm removing the ESP 32 I'm putting the swan SCM 32 micro controller in here. I'm going to plug it back in and What you'll see on the device as it powers up is the the light here is blinking every 250 milliseconds This is the application that I'm running my delay is 250 milliseconds I have the typical Arduino setup and loop. You'll notice here. I'm again I'm doing a hub dot set just like I did in the ESP 32 demo That is my connection to tell the note card how to find its project on the cloud service side And then this is the opt-in thing that I need to do I want I'm telling the note card if you get a binary for me You have permission to stream it in you have permission to place my device into the boot loader This is in an SCM 32 family and that's it everything else from that point is just delaying That's all I had to add to my application. That's what's running right now But I have a different version of the application that is in Zephyr So I have a very similar application that I've written using Zephyr We have a Zephyr SDK for the note card that is available to work with and I am doing a very very similar thing If you've done a Zephyr app before I'm basically just getting a handle to the primary the primary boot GPIO the LED Checking for button presses and in my Zephyr application. What I'm doing is basically every time I get a button press I set a note to the note card and that goes up to the cloud service And so again, you'll see a hub dot set a slightly different serial number here to indicate that the change is made I'm doing the same opt-in here for Card.df you and then from that point everything else is just waiting for button presses and then when I see them to actually do a note add and Add a note to the note card that then ends up in the cloud service So I've already built this binary and I'm doing the exact same thing that I did with the ESP 32 side of things and let me actually Reset here make sure this is doing the right thing Make sure this is properly configured here before I go on it is Swan Arduino DFU My device should be back online. Here it is. I have another firmware binary That was built specifically for this demo and this is my Swan Zephyr bin, so I will apply this binary and Same as with the ESP 32 as soon as I sync again The note card will be notified that a device that a new binary is available and it will start downloading that streaming it down Let me try Try that again. There we go So it is going to once when the note hub notifies the note card that the binary is available it will start pulling it down Looking for the magic incantation here and on the note hub side as with before I should see it I should see a notification. There it is. There's my saw my it's gonna go fast There's my swan is ever been so the download has started It looks like it's actually going through the process of doing the update right now So you'll see what's happening here is I'm my application code isn't doing anything the note card is actually writing flash To perform that DFU update for me. It's gonna happen relatively quickly and as soon as everything is verified It'll reset the device and it should come back online and what I'll actually start seeing is New behavior from a new device so notice that serial number. I shared earlier that said swan Zephyr outward DFU You'll notice that the device will when I refresh it'll show up. Yep, that the DFU has completed Now when I press the button on the device, I'll actually be able to see Notes that pop in from the note card. Where we go. Well, maybe There we go There's a note from the note card when I hit the button and I'll sync again And if I go into my events list I can see there we go The OS has changed and I'm getting new behavior from a device and I didn't have to physically Program that in order to make that happen I was able to use the outward DFU process in order for that to work and that ability to move between Languages is really quite powerful because it's actually something that we've seen as a real need in the IOT world Where for the sake of speed and we have customers that do this we often want to Ship a POC written in Arduino or circuit Python quickly even if we intend to might to migrate to something like Zephyr RTOS or free RTOS in the future and Speaking of circuit Python. This is an interesting one. Actually one of our customers Expire inspired the genesis of what this feature became because they were working with circuit Python The problem is even though circuit Python is awesome a binary with a circuit Python virtual file system and runtime is 500k And I don't really think any one of us want to wait for that or burn up a cellular data plan Or even worse by pushing half-meg binaries down to our devices And so we actually provide a couple of different capabilities for working with this Which is something that could be used in generic applications as well because one of the cool things About circuit Python is that it actually exists in three pieces and each of those is pegged to a known memory address One is the circuit Python you have to bootloader, which is at address 8 0 0 The circuit Python runtime, which is at address 8 0 1 and then your app Which is which is basically just the circuit Python scripts and libraries, which is at address 8 Which is an address 8 1 0 and what that means is that you can build a binary that targets those addresses and update Just your app piece and save a lot of transport time and data and this Works through two utilities that we've created at blues one is the open-source circuit Python file system builder This packages up your pie file and libraries directory into a binary format So you basically take that if you've ever done anything a circuit fight circuit Python before your code dot pie Your lib directory it takes just those two things and it puts those in a binary format for you And then with that bin you can tell the note card. Okay great turn this into a bin pack format and bin pack is Format that we sort of effectively invented But all it does is wrap the binary in a small header that you can see at the bottom That tells the note card exactly what it's getting and what memory address this needs to go to because the value here is what I'm basically telling that the note card is Take this binary that I give you and when you see this without word Df you lay that down at address OX 810 and we know that that's actually the scripts and libraries portion of circuit Python But you can actually use that library to update any arbitrary at memory address for your application So if you're building a C application or you're building a free RTOS base or Zephyr RTOS based application And you want an update just a piece think about an ML model for instance You want to update just that model file and you have that you know the address the memory address that that's in Bin pack is the way that you can do that and actually get that into the note card itself in addition We have the ability. Let me actually let me demo that really quickly and I have a Another device in my bag that I failed to pull out so we grab it really quick because I can actually show circuit Python in action before we go to the last piece here and I Have the same swan the same STM 32 microcontrollers before but it has actually been pre-loaded with a Circuit Python application that does something similar to the other demo that I just showed it blinks an LED such a wonderful Multi-purpose right we all build real-world apps that do nothing with blink LEDs, right? Is that just me? and so I am now going to Show you now that this is plugged in I can open up a Circuit Python IDE like Thonny It's always good fun and let's see. I will open this Where is my how did it not show up? Hold on might cut bait on this demo really quick if it proves not to work Okay, it's not registering the drive. That's all right With circuit Python on the note hub side I have a version of that same The same demo and you'll notice I mentioned a 500k binary versus circuit Python if I take just Code up high and files. I get something more like 78k I get it quite a bit smaller application that I can put down on the device itself And I can get even smaller than that now the last thing that I want to talk about very briefly Before I take questions in the last few moments that we have is to talk about MCU boot, right? Because we've already looked at how Albert DFU can be used with ROM based bootloaders Like what I showed with ST devices the reason that that works is because STM 32 microcontrollers all have a ROM based bootloader that you're able to work with and so the no-card places that device into its bootloader streams in Binary and then resets right but it's very common for devices nowadays to have soft bootloaders the Nordic Devices have a soft bootloader and one of the things that has been really neat as we've seen this develop in the ecosystem Is that we have support for Nordic devices using MCU boot now? MCU boot is an open-source standard and the idea if you're not familiar with it is to provide a Standard and library that defines effectively a common infrastructure for devices bootloader So you can effectively put a bootloader on any device and that system flash Knows its layout it knows where the bootloader exists It knows where the application and exists if there needs to be some sort of swap or scratch location It knows where that resides in memory as well And so you have a cross-platform way of defining or sort of structuring a bootloader on a known device And then that can work with a bootloader capable ODF you System and so now MCU boot has great support in Zephyr It works in Apache minute nut X the riot riot RTOS Embed but it also works a lot of expressive and Cypress and Infineon devices So there's a lot of broad support for outboard for MCU boot and What this ends up looking like? I'm not going to demo it live But what this ends up looking like I have another Zephyr application and it is again very similar to the other Zephyr application I showed before it's basically just looking for a button press and sending notes to the no card But the difference here is that I have this child image Director, I've done a couple of things in my project conf I have I've done a config I basically added a configuration to say I have a bootloader I'm using MCU boot Zephyr sees that it knows what else to look for from this point It goes and finds a child image directory called MCU boot and it pulls in the overlay for that So it actually knows what I'm doing in the overlay with Zephyr is basically saying What's my LED and what's the button to enter or sorry? What's the LED for status and what's the button? I use for actually entering the bootloader or the GPIO for entering the bootloader and So then Zephyr can actually take care of the rest of seeing that bootloader mode has been entered and putting that device into that mode And then the only difference from the note card standpoint when I tell the note card. I'm going to do card dot DFU Is it basically is instead of sending in that STM 32 string. I send in a MCU boot string and then that works with any compatible device at this point So definitely something worth checking out if you're interested in learning a little bit more You can learn more about outward DFU at blues dot dev Try it out for yourself Here to answer any questions in the next few moments that we have We also have a booth upstairs on three right at the top of the escalators the top of the stairs over here Am I even pointing the right direction? Maybe who knows wander and you'll find us in a booth somewhere Please do come and visit and thank you very much for your time today. Appreciate it Any questions before we are done? Going once going twice. Oh one question. Yeah Yeah, so the question is are you connecting the note card directly to the STM device? Yes. Yeah Great. Okay. So the question is yeah, where's where's the over-the-air part? So just to be specific about it the connection between The host and the note card is actually on the PCB itself effectively if you're building a product for this You have a physical wired connection between the note card and the STM 32 the over the air part is what gets the firmware onto the note card itself The the DFU part the note card then handles with Then then facilitates on the host right with the host itself It places the host into its bootloader and it streams the binary in one chunk at a time on to the device itself with DFU. Yes I'm sorry. What was the question? I'm not sure I follow the question. We should just we should talk afterwards I'm not sure I'm following that the line of questioning. Yeah. Yeah Yeah Yeah, question is do we verify the image after it was written to the device? So we verify we do a CRC check on every chunk as it comes down to the device 8k at a time And then the note card will verify the entire image and if you're using MCU boot You have the additional verification in the signing check that MCU boot facilitates. Yeah Yeah, the question is with the first update. Oh, yeah The first update mechanism that was using the cooperative DFU are you downloading the whole package before verifying the metadata and the answer is yes Yeah Okay, I am out of time. I just got to stop sign Thank you all