 Good morning. Good afternoon and good evening everyone and thanks for joining me today My name is Brandon Sattram. I'm the vice president of experience engineering at blues wireless and IOT product company Now to get things started today. I want to talk about purgatory Specifically the prototype or proof-of-concept purgatory that we often find ourselves in as builders And we all know that hardware is hard But that in and of itself doesn't explain the reason why 75% of IOT projects take twice as long as estimated And that many of it being canceled at the pre launch stage before the company even sees any value from the effort And often it seems like the reason that this happens is because of the time that it takes to get a POC off the ground From an idea to something working and running on a small number of devices often one, but sometimes just only two or three Consider an example So let's say you're looking to build a device to monitor out or outdoor conditions on a farm and for your POC you start with your garden So you buy the hardware you need and you grab your favorite MCU or single board computer But this project is going to be outside So you're also going to need a cellular modem you grab one from quick tell or you blocks or you grab a Nordic 916 dev kit to help round some of that out for you And that's great So you have the pieces but now you have to assemble them and in order to do that You have to figure out how to program the modem using whatever flavor of AT commands your modem vendor actually uses And you need to source a sim and data plan from somebody then you need to figure out where to send your data How to communicate remotely with your project if needed where to store certs how to encrypt your data and or The data for transport. Oh, and if you want to be able to perform for more updates for the project You're managing when you're managing more than just a handful You're gonna have to think about how to do a DFU back to the device and hopefully not brick it at the same time Now alternatively you could sign up for an IOT platform where all of these decisions are made for you But you give up flexibility and control you take the MCU Language data limits and pricing model that you get and you don't have a fit you follow the guardrails that are set out for you And in either case what we engineers have to deal with in this space more than almost any other is complexity And you know at any time that I think about complexity I think about a quote from our CEO of blues wireless Ray Ozzie now quote is complexity kills It sucks the life out of developers it makes products hard to build plan and test Now that's something that he said years ago long before founding blues, but boy, does this apply to the IOT space We are a wash in complexity in the Internet of Things And over the years we've tried to come up with various ways to manage complexity across our space Some vendors manage complexity by setting up guardrails that you must navigate to make things easier Sure and others try to standardize the processes board layouts or pins to make the ecosystem more modular And there's some good examples to 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 plug easily into a compatible Arduino to add additional capabilities The Raspberry Pi is an even better example with a 40 pin double-wide header the pie in the add-on ecosystem that it created was So popular that the same header can be found on almost every competing single board Linux class computer out there just for the sake of compatibility with peripherals And then there are some examples where we made a solid attempt, but the results were honestly kind of mixed So take peripheral connectors for instance and in 2013 seed studio introduced the humble Grove connector of four pin JST that could be used to connect serial I squared C or even digital and analog pins GPIOs devices And they fostered an ecosystem with a huge number of Grove compatible peripherals But let's face it as our boards and our projects got smaller the humble Grove JST looks pretty beefy So other vendors like spark fun and Adafruit introduced their own variants using the smaller JST Spark fun calls theirs quick and Adafruit calls their STEM a QT two different names same connector and are they compatible kind of For most applications you can use breakouts from spark fun and Adafruit interchangeably with boards from either vendor But there are a few edge cases mostly around whether or not the peripheral has a logical little shifter and Regulator so that it can be used with either three volt or five volt logic which can potentially burn out the sensor if you get it wrong And another example of where we've gotten mixed results to date in the world is in the world of firmware updates Firmware updates perform remotely or over the air We spent a lot of time trying to solve this problem in SDKs and platforms But does anybody really solve this problem in a way that doesn't force developers to give up control or embrace having to deal with complexity themselves? And that's what I want to talk about today the current state of OTA DFU and the two most predominant approaches that we have to choose from Today and then I want to introduce a new third way that I think marries the best of both worlds Into something new that we at blues are calling outboard DFU and I'll do a couple of demos along the way Let's start by talking about OTA DFU as it stands today, and I'll provide a little primer on what both of these TLA's mean So starting with the DFU part which stands for device firmware update This is the process of getting new firmware on a device by laying down a binary with an updated program on some known memory address In nearly in nearly all cases DFU relies on the existence of a bootloader on the device to be programmed The bootloader is a small piece of code that is stored in non-volatile memory That's responsible for launching the main application loaded onto the device We're providing a capability for updating the device firmware Now for the latter capability many devices require that the device be placed in bootloader mode in order to apply the firmware update For example, if you've ever flashed firmware to an SDM 32 device using the arduino usb Arduino IDE and a USB connection between the computer and the usb port on a board You've done a serial DFU and you've placed the device in a bootloader mode manually by holding the boot and reset buttons Alternatively if you've used a programmer like the stlanck or jlink to apply firmware to a device You've not had to do this because the programmer can automatically place the device in a bootloader mode using the SWD connector on the board It's basically a hard-wired connection to place the device in a bootloader mode and that fact will come back around in a little bit So that's DFU The OTA piece of the puzzle stands for over the air Which means the process of delivering new firmware to a target device happens over a wireless connection And often you'll hear OTA DFU associated with using Bluetooth update devices from Nordic or Sylabs using their mobile apps But it doesn't have to be a blue it doesn't have to be Bluetooth to be OTA DFU Shipping a binary over cellular or Wi-Fi is also over the air And in a world where nearly all IoT solutions all solutions are cloud connected OTA DFU is a table stakes feature in these types of solutions And we insist on having it because if we're going to take the time to add remote monitoring and control to an application We probably also want to use the remote control capability to fix the product without having to touch it Especially if those devices are no longer in our control And in a world where we have to deal with botnets made up devices with firmware that can't be patched It's beyond frowned upon to deploy a solution without thinking through how you can fix bugs or apply updates Not if but when needed But even today in 2022 OTA DFU is still complex And there are really only two approaches to it that are available to developers and each has sizable pros and cons We call the first let's just call the first OS DFU And this is where one in which the vendor solves the DFU problem in to end within their kernel and their cloud service The vendor solves all of the complexity of DFU for you provides a cloud console for updating uploading firmware and Facilitates managing firmware delivery to devices across the fleet on the device side The vendor provides firmware update capabilities as a part of their kernel or our toss and Manages every piece of receiving new firmware from the from the cloud service Placing the device into its bootloader and then updating the application or our toss on the device restarting it once it's updated The advantage of the OS DFU approaches that it is completely hands-off for the developer once they load new firmware in the cloud console The platform takes care of everything else from delivery to on-device updates But the disadvantage of this approach is a lack of control on the part of the developer in order for the vendor to make this experience Hands-off you have to place high guardrails in place and dictate a narrow set of supported hardware Programming language and even IDE to get the benefit of OS DFU You do have to yield some of your freedom as a developer to the vendor The easiest way to tell whether or not a vendor uses an OS DFU approach is just to look at their hardware support For host MC use do you have to use the hardware that they sell and manage in order to use this feature as opposed to an Off-the-shelf kit or a chip based on your skill set or preference That's probably OS DFU On the other side is cooperative DFU and in this approach both the vendor and the developer have to complete some of the puzzle to make OS OTA DFU work they cooperate to make the DFU happen Usually the way that this works is that the host vendor is it the vendor hosts firmware binaries and provides secure delivery of those binaries to a host But then the developer is responsible for writing the code needed to verify the binary apply it to the host and then restart the device And this approach is different depending on what form of wireless protocol you're using for OTA DFU At least at the edge down onto the device itself For example of Bluetooth is the update mechanism and the server in this case is often a Bluetooth capable device like a phone And the device must be brought within a few meters of the host in order to initiate the update And on the target the process varies from one MCU vendor to the next and the wireless communication protocol But it does sort of typically consist of getting notification that new firmware is available receiving firmware from the server to host to the host one chunk at a time and then placing that firmware in a temporary location in flash Validating each chunk and or the entire binary when it's done Copying the complete firmware into the appropriate location for the application in flash and then resetting the device to run the firmware And if you're not using Bluetooth for OTA DFU then you're likely using cellular and Wi-Fi And in this case the server is an actual server It's in this a remote cloud service that hosts and delivers the binaries for you But beyond that the process is pretty similar to what I described above your host still has to get the binary Validate the chunks or the entire thing place the device in its bootloader, etc. etc restart it and you're good to go And in the case of my company we we offer today as something like a cooperative DFU style approach And I'm going to walk through that briefly because I'm going to demo exactly what it looks like And for us OTA DFU consist of two components the no card and our note hub IO cloud service And the no card is the hardware side of the equation that works with your host It's a device the cloud data pump that comes in a small 30 by 35 millimeter package And it has an m.2 connector so that it can be incorporated into any design or field replaced as needed The no card comes in Wi-Fi and cellular variants that are project swappable and the cellular variant includes 500 megs of data in 10 years of secure cellular connectivity in over 139 countries and counting and the data and the the plan is included in the cost of the device As a data pump the note card is meant to be used with the MCU host of your choice So you can pick an STM 32 ESP 32 Nordic device or even an 8-bit Arduino and communicate with a note card using a 100% JSON API over serial or I squared C You can also use any embedded language that can print strings and we have SDKs for C C plus plus Arduino tiny go rust and circuit Python And the cloud side of that equation when it comes to OTD if you facilitate with note hub and note Hub serves really key three key functions for developers One is that it's meant to be a secure end point for note card devices to transfer data from your host Or to receive messages from the cloud down to your ultimate hardware solution It's also meant to be a thin piece of middleware so that you can route event data from your sensors to whatever cloud service that you use and Then finally as a device and fleet management command center for monitoring devices updating configuration and shipping firmware via OTA Tfu and note up can deliver firmware updates for the note card itself and its core functions Running on an ST that run on an STM 32 L4 chip on the board and it can also securely download verify and deliver Firmware updated updates that are meant for your host and as recently as a couple of weeks ago The blues process for host firmware updates was in line with the cooperative DFU approach that I've already described note of host the firmware and delivers it securely to the note card and once downloaded and verified the note card Informs the host that a firmware update is ready But then the host like before is responsible for retrieving the binary one chunk at a time Verifying it and applying the new firmware using the host to find approach of putting the device in its bootloader and so on and so on So let's take a look at the demo of this process with a note card and with an ESP 32 now switch over the cameras and desktop for that on the desk here, I have the an ESP 32 that's connected to the blues wireless note card via This a no carrier F Which is this daughter board that we have that facilitates a connection between the two so the ESP 32 is communicating in the note card And I'm going to show off the cooperative DFU approach This is running a binary and I'm going to update it and sort of show you what that flow looks like if you have to manage all that Firmware yourself, okay, so I have my ESP 32 app I created it in platform IO running inside of VS code and In the project, I'm going to walk you through very briefly just sort of what what this process looks like in terms of What I have to actually include in order to do OTA DFU using this cooperative approach with the note card and Sort of the big piece of it is when the application runs it scans to make sure I have two partitions because this is the ESP 32 It uses the ESP IDF partition system and this is in my Sorry, this is my DFU dot CBP in my main dot CBP I basically am running The part the main part of the application right and so you'll see there's a couple of different things I need to do need to actually provide a product string I have my button pin and LED pin on the ESP 32 connected here I'm setting that product you ID which is that unique identifier that tells the no card exactly where on the cloud service side to go And that's here on the on the right hand side and then sort of the bones of my application is I'm basically I Set my connection to note hub to our cloud service using the hub dot set JSON request I give it a serial number Set it into periodic mode basically configure its connection to to the cloud service and Then so that's sort of the main part of the process The other main part of the application is me actually checking for button presses if I if the button is idle I'm checking to see if there's a DFU that is available on the note card side If I get a double a double press I perform a sink I set the LED high and low and then I can also do a sort of dummy Measurement voltage measurement that I send that as a as a data point as an event to note hub via note add Request that's all sort of the standard the main part of the application everything else that's in here facilitates this part of actually doing the DFU detection whether it's the setting the product to ID information here And more critically importantly checking the DFU status when I start up and then in my loop Basically polling for DFU at all of that logic happens inside of this DFU dot CPP helper And this is what actually pulls in the ESP IDF Helpers for working with the partition system. I have a helper in here that shows me that the available partitions I'm actually set in standard dual partition mode. I Have a helper function that handles doing a CRC check on those chunks as I get the the chunks from the note card And then the polling process do so does sort of the the main part I'm actually getting every chunk of my firmware binary from the note card The way that the process works is the note card Gets the firmware from our note of cloud service and as soon as that's there It sits in the note cards flash ready to be handed over to me on the host side It'll my ESP 32 needs to do is basically get that one chunk at a time To CRC each chunk to make sure it's valid as it transferred across Serial or I squared C and then I go through the process of reading those Validating it and only after that can I get down to the point where I can actually Set that into my boot partition and then reboot and bring the device online This is 311 lines of code that exists solely to handle that DFU process And then has to live on the main host itself So in a cooperative DFU approach once I've count once I've built all that my firmware needs to know how to handle a binary when it comes across I can build the binary and once that binary has been built I grab it from wherever location it lives in this case in platform IO It goes in a build directory that I can get it from and then what I'll do is I'll come over to the note hub side of my project and I'll load the firmware in here And you'll see I actually already have that in here if I make a change and I set the I go to my main dot CPP and I set the major minor to 1.1 and that's the new version that I want to run I'll upload that That firmware here and you'll see I've got this 282k Binary that's sort of sitting there ready to go and the reason it's so large is because it has all of the spidf DFU partition awareness stuff that's actually Invaked into that binary as well And once I have actually Assigned that or once I've actually figured out the right place for that to go I can then in note hub go into the host firmware tab Choose a binary to update and I'll set that I'll select this this version right here click proceed And what happens on the note hub side is that that process kicks off and the next time that I actually Perform a synchronization so I can actually connect to my note card here using The dev tools at dev.blues.io And the next time that I perform a sync I can actually see That I'll start to see that binary actually being downloaded From from the note hub service and it goes and gets that I'll see it actually here showing his idle right now because my device needs to reconnect But you'll notice that I'm getting some notes here to actually go and sync that information All of this trace information is what's happening behind the scenes as the note card goes and starts to fetch the binary And pulls all that information down and so in the background I don't have to see this on the host side in the background. This is all being downloaded But once that download actually finishes, then my actual main application loads I go into dfu poll And then I go through the process of downloading and rebooting. So that's the cooperative dfu approach Right the cloud service gives me the binary, but it's my responsibility on the host side to do the rest of the work So one of the important things to notice about that demo was that my actual application code made up a very small part Of all the code that I had to add to my app in order for this process to work Even with a library or a helper class that we provide to facilitate the transfer and update the process My app still has to know a lot about how to update itself for this process to be useful And in general the strength of cooperative dfu is that the developer has complete control over the host they use And there are no guardrails beyond those imposed by the bootloader process dictated by the host be it st Nordic sylabs or the like The drawback as you saw in the demo is that the developer I am responsible for handling the application of that new firmware Up that myself I have to use that approach is all in my code And not only is that manual and time consuming that litters my project with code That's not core to the actual problem that i'm trying to solve But if it changes introduced that I that I create that bricks the device The host ends up in a state where it can no longer be updated at all Meaning that the benefit of ot adfu is completely lost So with these two approaches it appears like we developers basically have two choices We can either give up control and get hands off ot adfu Or we keep control and add time consuming and potentially device breaking work to our plates But today I would like to introduce a third way One that provides an early hands-off dfu without sacrificing choice And it's something that we call outboard dfu And when we use the word outward we use it here like an outboard motor on a boat Which is a motor that is attached to but not an integrated part of the boat itself It's effectively lashed onto a craft and when placed in the water it can control and propel it But it can also be removed or replaced without damaging the boat itself An outward dfu is a capability that we've recently released in beta And it provides the benefit of being able to use note hub for hosting and delivering binaries While allowing the note card to serve as the outboard motor for controlling the dfu process So that you don't have to litter your app code with a bunch of dfu aware code and functionality And the best part about this is that we can do this while also giving you choice of mcu family Programming language and all of those things that we really prefer to have as developers And this is possible because there's an increasing number of mcu's modern mcu's that have been produced in the last decade that ship with their primary bootloader and rom Unmodifiable by any user operation So on these devices which includes all modern xt micro electronics and expressive microcontrollers When a reset pin is asserted the device enters its rom bootloader Which can then load and execute code from a derived from a variety of sources including flash ram ur usb i2c and spy And this rom bootloader behavior is controlled by actively probing ioports And by sampling the state of strapping pins that are specific or specific or specially locked boot option byte Boot option bytes in flash And these manufacturer provided rom bootloaders present Really new options for us as engineers specifically We can perform secure firmware updates in a manner that is far more flexible in terms of language and artas And far less vulnerable to bricking devices and introducing inadvertent programming bugs So putting it another way using this approach you can defer the dfu process to the no card And allow it to be the thing that handles updating your host and it can do it regardless of the state that the host is actually in So remember how I said earlier that using a programmer like the st link or jlink doesn't require the manual button press bootloader dance The reason for this is because those programmers connect via a special j tag header Which has direct access to the strapping pins or option bytes of a host And with outboard dfu we're taking the same approach By providing the capability for connecting the note card to the strapping pins on a set of hosts that we support And putting the device in a bootloader mode laying down firmware and then restarting the device and at present We support this with the stm 32 esp 32 and nordic and nordic nrf 52 8 40 So you can use any of these in a custom design using a guide that we've created that lays out how to connect To a set of pins on the no card To the mcu's reset boot and uart pins And this also works with our note carrier f and an stm 32 feather board that we produce called the swan Adafruit feather stm 32 f 405 express or the adafruit nrf 52 8 40 express feather Or with the stm 32 processor micro mod board from spark fun. It works with all of these devices So let's take a look at a demo of this now and see how much simpler our application code actually ends up being So for the next couple of demos, I'm going to keep the camera on my hardware the whole time So that you can actually see some changes that we're going to be making as we as we do firmware updates But I'm back to using I'm on my desktop and I'm using the note card as before This is a wi-fi version of the note card our note carrier f Which does support this new outboard dfu feature because it's been wired to the boot reset And uart tx and rx pins on the feather connector and for this host I've added this stm 32 board that we call the swan and It uses an stm 32 l4 r5 mcu and like all modern st Devices it has a rom bootloader and like we discussed previously the the boot and reset buttons are the manual The manual human driven way to get this in the bootloader But we're going to be able to do this automatically. So with everything powered up and connected Let's actually take a look at the firmware and this is a simple arduino app That blinks the user led every second. This is basically what happens and I have a a pound of fine 1000 milliseconds so every second it's going to set the led high delay set it low delay and loop again That is the main functionality of my application That's simple the only things that I need to do in order to enable this outboard dfu process that I talked about Is just like I did a cooperative dfu. I set the connection of the note card into the note hub cloud service So it knows where to go. I set its product uid same as before I'm going to give it a serial number to distinguish it and I'm setting in a continuous mode So it has a continuous connection and then for outboard dfu All I need to do is I sent a second request called card dot dfu I set the name of the processor st m 32 esp 32 n r f 52 8 40 You tell the note card which one of those it is so that it knows exactly what to do In order to stream firmware into the device Turn it on and I go and I go and so if I actually wanted to change this from 1000 milliseconds to 250 So I want to update every quarter of a second And then I built that version of the binary should take about a few seconds to actually build it So I've built that binary and just like I did for cooperative dfu I come into the firmware section of note hub dot i o I add this binary swan arduino odfu. It's the second example here. It's 55 k So not that big compared to what I had for the esp 32 that included all that partition logic and my custom functionality And then when I go in back into my device of you, I see that I have my device online I go into host firmware And then I will select the arduino odfu bin right here And so I am going to upload that And then what I'll do in order to actually start the process is I will Perform a sync from my device just as you saw before I'm in the web rep I'm in the blues the dev dot blues dot i o web rebel again And as I perform that sync I should be able to actually see that a There we go. There is the binary that's actually coming across I'll see these requests in trace mode that shows me that it's downloading the binary One little bit at a time And it is actually as it goes through the process of downloading that binary It's going to get it all together So as soon as that process finishes you'll notice that I lose my connection in the web rebel because the device has Restarted it's lost power. It's come online again. We also notice that now my light is blinking a little bit faster I can reconnect to the device Uh, and it's fine. It's come back online But I've all immediately seen that change as it actually has shown up On the device right there So it's as simple as that literally in order to opt into this outward dfu process This is all that I had to do and because the note card knows how to perform that process for the esp 32 It's as good as done right far easier than the esp 32 example from before Uh, but you know it gets better because without word dfu Because the host really doesn't have to know anything about updating itself You can effectively do a brain transplant between languages between our toss is really anything So for example, I have another project here And this project is a zephyr artos project So, uh, this is a it connects to the same note card and it runs the same sdm 32 host But you'll notice that the code is quite a bit different because this is an actual zephyr application. It's not an arduino application So i'm using the exact same idea here my In this case what the process is doing is slightly different I'm making a connection into the note card, but i'm doing the exact same hub dot set in this case just changing the name of the Of the serial number of the device so that I can distinguish it And I have a couple I have some logic here to uh to to pick up a button press And then anytime there's a button press it does a note dot add and also turns off and on The led as well, so i'll be able to see slightly different functionality that comes across when the device actually comes online So much like before what i'll do is i'll go through the process of building this And then I can pull it up into note hub when i'm ready to go And you'll see when I come in here that the dfu status from before is completed I have another version of the firmware for zephyr, which you saw before and this is about 46k So relatively small not much to it And then includes that note card library and i'll do a very i'll do the same thing as before i'll click update But this time i'm going to select the zephyr binary file. Click proceed It'll queue that for dfu update And if I come back to my device, what's going to happen now Is i'll turn on trace mode and I will sync like before And just like you saw before what i'm going to do this point is just sort of wait for that Binary to start to come down the note card is going to pick it up And just like before it's going to download that you'll see it's kind of already starting to come across It's going to download it and then we'll see the functionality change on the device And just as before I lose my connection to the note card as it restarts, but I can reconnect This point turn trace mode back on and now remember what I had decided to do for here is anytime that I press the the user button On the device that I'll get a note that pops up and you'll see that note shows up here And then it ends up syncing to the note hub service So when I refresh here, I can actually see my device id is now zephyr outward dfu if I click on my events Now I can actually see these button counts events that have gone across and without doing anything Really physically on the device all I do is I'll have the note card to go from an arduino application into a zephyr artos application In a matter of minutes using this outboard dfu capability. It's pretty stinking cool So that ability to move between languages is powerful And it's actually something that we've seen is a real need in the iot world where for the sake of speed and getting a poc out the door we often want to be able to ship something written in arduino Or circuit python quickly even if we intend to migrate to something like zephyr or free artos in the future And speaking of circuit python There are actually a couple of additional features related to outward dfu that are particularly interesting if you're working with this language On your devices because circuit python is awesome It's fun to use But a binary with a circuit python virtual file system in scripts is 500k And I don't think that any of us want to burn up the data plan on a cellular device pushing half make binaries down to our devices And so one of the cool things about circuit python that actually enables us to have a solution for this is that it actually exists in three pieces In each is paid to a known memory address. There's the circuit python uf2 bootloader. That's at address hex Hex eight zero zero the circuit python runtime. That's at hex eight zero one Or your app the circuit python scripts and libraries that are at address hex eight one zero So what this means is that if you can build a binary that targets just those addresses You can update just that piece of the app and save a lot of transport time And data which is pretty interesting and this works through our outward dfu approach with a couple of open source Utilities that we've created One is the open source circuit python file system builder Which packages your python your python files and libraries director directory into a binary format And which then allows the second utility to come into play and that's called the note card bin pack utility Which we we can use to tell the note card when that when the process is loading when outward dfu is happening It tells the note card which memory address to update when performing that outward dfu And bin pack actually works with any binary type so you can use that to peg Parts of your application into any memory address and update those independently, but this is extra useful with circuit python So let's take a look at a demo of this now and i'm running the same device as before But this time my swan is running a circuit python application that's blanking the led so let me show you Okay, so i'm running the same device as before but this time my swan is running a circuit python application That's blanking the led every one second and so here's the circuit python application. It's very simple Use the same product uid The one that's on there is running every one second i'm going to change that here in a second But again just like before i'm calling hub dot set Sending the json request to the note card in order to assign it to my project And then card dot dfu to turn that on and again just like my initial arduino application very simple On and off of that led every one second In this case i'm going to change this to point two five and then this is where i'm actually going to go through that process Of then creating a binary from my files that i can then flash only by itself onto this drive this device Already has the circuit python run time the uf2 bootloader the virtual file system is there But it's that file system piece that i want to change so i can keep this as small As humanly possible all i really want to put on is the code dot pi file and then the library which includes my note card sdk as well so in order to actually Do this i'm going to open up the circuit python file system builder. It's an open source Repository that you can clone to run locally. I'm going to set up a virtual environment for this Set up the virtual environment for that and then what i'm going to do is i'm going to run python Main dot pi i'm going to pull the files from my file system So this is a pointer to a folder a directory that has the live and code dot pi And then i'm going to turn that into a binary called circuit python files dot bin And it was good as done that goes in that bin directory there And then the next piece is bin pack as i mentioned before bin pack is the piece that then Tells the note card in the outboard if you process what precise memory address in order to send this to so This is part of the note card utility, which is another open source utility that we have that's available in the blues GitHub repository, so i'm going to call note card slash bin pack. I'm going to say this is bin pack for the stm 32 The address that this binary is going to be pegged to is hex 8 1 0 0 Like i mentioned before everything it hex 8 0 0 everything it hex 8 0 1 The uf2 boot loader the circuit python runtime those will stay the same The outboard gfu process is only going to update this little piece right here So that then creates that binary for me So I can see the bin pack binary right here I have one that i've created already and this is when I go back to Note hub and actually upload this firmware. So this is the last piece here. This bin pack file. You'll see Unlike the 500 meg Binary that I would get if I did everything in circuit python. This is only 78 k that has just my files So I can push that down just like before and just as you've seen me do two other times already I'm going to go into the device host firmware section. I'm going to choose my bin pack device click proceed My bin pack binary pardon And then I am off to the races. I'll go back here And I will initiate a sync just like before and then when it sees that binary it's going to pull it down One little bit at a time just like every other part of the process and then apply that to the device And now my device is back online. You'll notice I'm still connected here to the note card But look now the led is flashing Every quarter of a second again still running circuit python and I did that process through Outboard dfu so you've seen in just a few quick demos going from arduino to zephyr to circuit python All using this exact same brain transplant outward dfu process So that's outboard dfu and we think that this is an exciting new way to think about doing firmware updates and to rely on cloud infrastructure and intelligent controllers to facilitate the ot adfu process without taking away your ability to choose the mcu family Language or our toss that you're most comfortable with So to learn more about outward dfu and blues visit our developer portal at dev.blues.io And if you're interested in grabbing any of our hardware trying out a dev kit You can grab that at shop.blues.io spark fun or digikey Or you can scan this qr code and get 20 off of any of the kits that are available in our store So thanks for joining the session today if you have any questions Please feel free to reach out to me at brandon at blues.io or on twitter at brandon satchelman also be here for q&a So thanks again