 All right, so I think I'm gonna start just because it's 510 and that we get started on time as people filter in We'll just continue and leave the door open at least for the first five minutes So I'm sterling. I work at runtime IO Which is a company that provides management and monitoring systems for IOT deployments And I'm gonna talk about Apache minute, which is a real-time operating system effort that it's very similar to the Zepher effort That I think you've heard a lot about at this conference But perhaps with a little bit of a different take on certain things So runtime is one of the the major contributors to Apache minute here our background or The background of a lot of people at runtime Is in kind of large-scale early IOT systems So I worked at a company prior to this called Silver Spring Networks and at Silver Spring we deployed about 24 million Networks street lights power meters It kind of industrial equipment on large-scale sub gigahertz wireless networks and Our company was was really founded because when you have all of these devices and these traditional assets that are networked You want to do things like update software to those devices And what we found is we ended up building those management systems by ourselves And it seems like everybody who develops the kind of one of those first gen IOT devices Whether it's us with with power meters or Fitbit with wearables ends up building their own management system So that's kind of the idea behind runtime. I want to talk I'm gonna talk almost entirely about minute for this session, but just as a context from for where I was coming from so When we we founded runtime and we looked at you know, okay, we want to provide this management system We want to provide good software upgrade and secure software upgrade. We wanted to Be able to let people know what was running on an operating system or if there was crashes in the field We wanted to bring back core dumps to them We wanted to manage these devices out there But if you look there was a whole set of devices that ran Linux and were easy to manage and had standard kind of management APIs and then the entire set of devices that didn't run Linux So really if you think about it Cortex M series devices, you know, there's MIPS in that world and there's 8051 But anything that didn't have an MMU in it wasn't powerful enough to run Linux Things were pretty much a mess, right? What we did and what most people do is they if they have a kernel at all They buy an RTOS kernel or they use something like free RTOS and then they start to cobble together their own systems from there So they'll either use a chip vendor provided bootloader or they'll write their own bootloader they'll buy an IP stack from a third-party IP stack vendor and They'll essentially create and compose their own operating system for these devices However, the problem of course is also in addition to that making everything non-standard When you're writing your own flash file system and your your goal is to get out a connected power meter How much time are you going to spend writing that flash file system? Not a lot, right? And are you going to care about encrypting at first? Well, if that's not in the product spec sheet, you're not going to care about encryption to start with right? Are you going to care about? You know error correction on flash maybe a little but you're really focused on the first version of that product And so what ends up happening is you have all of these kind of half-developed modules in your own operating system That you then your life, you're lucky enough that the first version of your product works You end up having to scale that and grow that over time and live with those mistakes and that ends up being really really costly in addition it makes it hard to use third-party management services because what you've developed is very very specific to your company and specific often to the hardware platform or the chip that you've chosen and so it really becomes kind of your own little walled garden that you live in and And so that was really the first That was where it clicked for us that there needed to actually be an operating system on the endpoint That was open source that everybody used that everybody collaborated on so that we can that that provided Consistency for us to provide management and it also enabled these product companies who were developing connected products to not have and maintain Their own operating system efforts So that is the idea behind Apache minute. So Apache minute very similar to Zephyr in the in this scope is really an opera a more accomplishing Operating system for these devices where we differ a little from Zephyr is we do provide things like the bootloader for these devices as well As the upgrade and management schemes intrinsic to the operating system itself You wouldn't typically see that in for example a Linux But you know when you look at Linux, there's a lot more Code space available and a lot more RAM space and so you don't have to optimize things for it to be as small So what what's included in the minute system is everything down here from the bootloader itself? So we have a secure so we have built our own build and package management system to actually build the operating its system itself That build and package management system allows you to create Upgradable firmware images to sign those firmware images to locate them on flash and then our secure bootloader actually understands Where images are located and can switch between different images? There's a flash file system built within minute, so we support fat 32 But we've also designed other flash access mechanisms for these small constraints constraint devices So we've designed our own log structured flash file system for very small flashes So think you know a megabyte of flash with 128k blocks And you need to write a file system and 16k of RAM and you need to run a file system on that There are and in addition to that there are other mechanisms for accessing flash So a lot of what people do is they don't run a full file system where you actually have Writes anywhere in a file, but they just run TLV configuration storage mechanisms So we have flash TLV mechanisms in there as well on top of that We have a preemptive multitasking real-time kernel, which I'll get into This is nothing unique or different. It's just licensed in there The how itself is a is our hardware abstraction layer in the operating system So the how operates independently of the operating system and can be used in the across the bootloader and the core of the device itself And is really designed as a purely a peripheral abstraction Because you have so many different variants of MCUs that people use and they do share a core set of peripheral functions So that's what our how ends up doing on top of that We have the drivers and the power management infrastructure in the LS So there they the difference between drivers and how is that the how is meant to be a complete implementation for every MCU So you are guaranteed when you use this MCU that you art spy I squared C are there and implemented at working And and we've designed those APIs to be as low layer as possible So that you can then build drivers on top of them and drivers are meant to be where there's diversity in the system So you can you can write a driver for an ADC that uses DMA and is very complex Or you can write a driver for an ADC. That's very simple and just as a blocking read But the implementation of that driver doesn't live in the MCU code itself It's separate and comes along with the system. We tie in power map good power management support throughout the operating system So in addition to it being a tickless our toss all of the drive All of the house can can start and stop peripheral API's and the drivers have a concept of suspend and resume So that when you want to when the system goes to sleep you can suspend a driver and even if it's open It will go into a low power state. There's hooks in the code for managing power domains and clock domains and all of the things you kind of expect on a more on some of these more Complex MCU's you don't see that across the entire cortex M space So for example clock domains, you typically don't see on the smaller Bluetooth socks You do definitely see there on see them on the higher end STM processors and NXP processors So, you know depending on the platform will do different things there But we do have API's for both and then there's a whole set of kind of embedded middleware that provides Configuration management software upgrade all of the things you would need to do when you have a real product out on the field And they're engineered into the system itself Followed by networking stacks, which I'll get into a little bit more detail, but you know when we looked at Building an operating system the thought was okay. Well, so where do you start right? You have to make some this is a very very expansive effort And you have to make something that works for a set of users who are building products if you want to kind of paint This vision so the first area we focused was really on Bluetooth and low energy connected devices We chose Bluetooth because it's one of those protocols where you know if you're using an RTOS You probably if you care about power You're you're probably using an RTOS in the extreme and certainly most Bluetooth low-energy devices use our tosses So one of the major features of minute and one of the areas where we've gotten a lot of Initial adoption is we have a fully open source Bluetooth low-energy stack both host and controller Built for the nrf 51 and the nrf 52 And the idea for us is really open source wireless networking stacks And where we at runtime at least have spent a lot of our focus is not actually so much on the IP side of things So as a contrast to Zephyr, I think they're implementing their own IP stack We've we've adopted LWIP and we've integrated it into our system and LWIP is very Solid for us But where we really put our focus is on the wireless side of things because that's where we think the innovation Actually needs to happen IP's been there for quite a while Although if folks want to join the project and work on IP we were more than welcoming And then there's security that layers on top of that So another kind of core tenant of the operating system and I'll jump into the Kind of the good stuff next but just when it comes to how we run the effort The idea is to be a community-driven operating system effort so that it the contrast of that To other efforts is really that no company or corporation has a board seat or owns the effort in any way So we love companies to contribute We certainly want anyone here who's at a company to contribute and invite their friends But the project is run by the committers on the project so essentially the way it works in the Apache Software Foundation is if You come on the project you're you're using Apache minute and you find problems with it Or you want to improve it in some way you submit patches if you submit three four patches you start to commit to Contribute to the community you get Elected as a committer on the project and the committers elect other committers and after that point You then have a vote in the direction of the project. So there is no technical steering committee. There is no board That is bought there is no way to buy those seats But it's really all about submitting code and building a community on the development list And this is kind of the Apache way. So the Apache Software Foundation was founded in 1999 To do the Apache web server They've also done hadoop and a large lot of the larger big data efforts And really they started by building the Apache web server And then what they found was they had a scalable community model and they decided to apply that to other projects So every Apache Software Foundation project is run the same way. It's a 501c3 non-profit organization and We are just one of many members of the Apache community So onto the RTOS itself, and I think I've talked a little bit about this. So when we looked at an RTOS Kind of you know the the core design decisions that came into the RTOS were if you look at the kernel itself To make it simple and and have an easy programming model We've seen a lot of RTOS is over time from you cost a threat X to a lot of these kernels and They have you know four different message-passing APIs often there are both cooperative and preemptive models in a lot of these RTOS is there's a lot of things that allow you to be very specific about how you use them What we decided to do was distill this down to a couple of key elements So we have the concept of tasks tasks are preemptive There is a in the system there is event queues So pretty much on the next slide will talk about the event driven model But pretty much everything goes through an event queue which essentially allows you to sleep on a queue and when there are events Wakes you up. So most tasks what they do is they sleep on an event queue Timers IO everything is scheduled through those event queues and then the operating system itself Operates in a tech list mode. So you just you declare tasks by priority priority one being the highest priority 253 being the lowest priority and the highest priority task runs until it can't run anymore When it yields its context lower priority tasks can run and so on if a lower priority task is running and You want to run a higher priority tasks say you take an interrupt because you've received a packet if you schedule the higher Priority task is active. It's going to preempt the task below it There are mutexes semaphores and that's pretty much the core of the kernel itself in addition to that We we keep a few helper functions in the operating system itself So we keep a concept of unified buffer management So we have something called M buffs which are very similar to Linux kernel SK buffs so the idea that you have a Unified buffering scheme you can declare a certain size memory pools And we really locate that in the kernel just because it's a very convenient place to put it And we want all of the networking stacks and all of the system to share those buffers And we've engineered the entire system to share those buffers so that you can resize them to based upon your memory requirements And then there's a fair amount of Actually, the other major thing in there is a high resolution timers So our how how interfaces abstract MCU level timers But they deal in ticks because that's what pretty much every processor we've seen deals in and we didn't want to burden the how with the comp with the conversion from ticks to megahertz So in the operating system itself, we allow you to declare chained high-resolution timers And then the rest of the operating system is really focused on how do you manage this operating system? So we have memory debugging and for interfaces on the memory pools We've built in a sanity task which actually what is a software watchdog that tickles the hardware watchdog But also allows you to have checks on memory pools and on tasks waking up We've built in Research utilization tracking to the operating system so you can see which tasks run how often they run how many how many times they switch Tasks, so it's really the majority of the effort and focus has been in making the operating system easy to debug So this operating system right now works across Cortex M0 M3 M4 We are actively working on M7 and somebody has submitted the first set of patches for MIPS So those are the the platforms we've targeted to date So event queues and I'll jump over this quickly But when we focus on event queues really the if you look to the left here Essentially, this is how an event queue is working how an event queue works and really we expect in most cases people to Be using event queues sometimes you'll wait on semaphores as well If you if you want to have the concept of event flags where I want to wake up on a flag if any of these bits are set We do support that but primarily the task comes up and it waits for an event from the event queue This can either be IO and like an incoming packet It can be a timer it can be a message from another cat task and you wait from all of those operations You execute and then you go back to sleep The reason you want a program in this way is It allows the operating system to go to sleep and move the processor into sleep modes While you're waiting on the event queue so the event queue marks that the task isn't ready to run when the entire system Goes to sleep we're able to shut off the CP. We essentially look for the next scheduled event We shut off the CPU we suspend all of the drivers We allow for custom power management hooks in there And so when tasks you know tasks can run if you want a low priority tasks that just always runs That's perfectly fine, and you can do that, but the system won't go to sleep if you do that And so really the idea is that everything should run through these event queues and these event queues have a bunch of debugging Information built into them as well So when you have core dumps or when you have crashes in the system You can actually pull information about the event queues and what's been happening on a task So kind of going next on to connectivity layer. So where we've started is over here Where we really started our effort was on BLE 4.2 So we've implemented a Bluetooth controller for the Nordic stack kind of some of the highlights are you get a lot of Bluetooth connections so by default the soft device from Nordic only supports three connections in central mode one connection in peripheral mode We've run up to 32 simultaneous connections in production The addition to that is you also have some of the higher data rate features and just flexibility about how you configure the stack and run it It's down to the controller level, which means we manage all of the radio things and it's portable across trip sets So we're porting that same controller to the NXP KW 41Z and to other processors What you see in a lot of the traditional MCU efforts is that people have chosen the Specific networking stack provided by the chip vendor and so when you want to switch or when you want to procure a chip The problem that you have is oh, it's not just that I have to retest the hardware I have to retest the entire networking stack and all of the bugs I found in the Bluetooth stack and all of the things that I worked around in the software upgrade mechanisms all of those change And so it becomes a very large effort when you're switching between chip sets when when we implement out all of the Proprietary driver code that's been given by the chip vendors That allows people who are developing products to then go procure across multiple chips and they can choose on power and cost which are Pretty much power cost and size are the major reasons people will choose a chip set above Above this layer. We have two options here one is new manager, which is our own custom management protocol And it's it's very very small We use it for things like when we do our serial boot to do software upgrade in the Directly from the bootloader or on some of the very very small devices, but pretty much at the management layer We standardized on OIC so OIC It essentially runs on co-op the standard itself actually has Six low-pan and DTLS on top of GAT. We've removed that and we run directly on GAT But the idea is that we think OIC can work across all of the different transports and can be a protocol that provides unified Management and application layer traffic, which is which is a big deal on these constrained devices Right, you don't want to have one framework and one set of security policies for your management stuff And then another framework and another set of security policies for your application stuff and have to deal with all of that extra Code and what's really nice about OIC is that it has profiles for Wi-Fi It has profiles for VLE and it's going to have those other transports over time And so the same framework that we use for management can easily be adapted and used For your application layer data. A lot of people are using it We've recently added Wi-Fi support So for Wi-Fi connected socks This includes L-Web and TCP IP and TLS and DTLS OIC works directly on top of the Wi-Fi interfaces as well as the Bluetooth So you have the same API that you create those management commands works across both and the same applies for the application layer commands We provide as well In the future we plan on implementing a whole set of new transports Of course the project is open for anybody and anybody who has a wireless transport that they're particularly excited about We're welcoming of it. However, the ones we I think at runtime really think are going to Be in our future is Bluetooth 5, which we think is great The addition of mesh is going to open up a lot of use cases there And then we think that there's a lot of effort in low-power wide area networks That space tends to be a little bit more nascent But we definitely like to see Laura support in our operating system as well as some of the things like 15 4g and Y Sun there and then of course there's a lot of efforts in 3gbp like NBIoT Which we think will take off a fair amount of the market as well on top of that We do plan on running thread on top of IPv6 as well as the rest of the stack and of course, you know You don't have to run OIC you can direct write an app directly on top of any of these things It's really up to you But where we've really spent effort optimizing and engineering the system is around the OIC protocols Because we as a part of every release we test software upgrade. We test management. We actually use it for our operating system So some of the features here, I think we've covered a lot of them The only thing I'd mention on the the the Bluetooth stack is not only do you have better performance as opposed to the other options But because it's open source you can actually configure it so when you want to go peripheral only and you want to Take out security and take out things and have the smallest possible implementation You can do that as well as going full central mode and running it So that's a nice feature of it being open source and then on Wi-Fi the chipset We support it first is the Wink 1500 there are efforts underway to support other Wi-Fi chipsets Specifically, we've been working on media tech although we'd love Broadcom and a few others anyone wants So just jumping here a little bit and Kind of some of the challenges in maintaining connected products So one of them I think and just to kind of go off. These are the these are the Ways that minute optimize is to solve these problems So cross-platform support as we mentioned, you know What you really there's a couple of challenges here when you're developing a connected product one is just bidding chip vendors against each other Right, which you definitely want to do It's amazing how Much less expensive the product becomes when there's competition The other is that typically the old version of the chip has better software support for it Or has worse software support than the new version of the chip so in a lot of cases The next version of that chip will have all of the new features and the old version will just be supported when in fact You can have the old features running on the or the new features running on the old chip But there's obviously a reason that you want to upgrade there So having an open-source operating system that's cross-platform that implements things down to the hardware level Really allows you to exercise price pressure on the vendors It's also something that you want to consider because as you go into higher and higher volumes a lot of Companies will typically do their own system on chips. I mean, that's where you see any see for example having a ton of business And so it's also the ability to then port to your own system on chip as you scale Software upgrade is another big item here So the idea is how do you do secure software upgrades? So newt itself is our building package management tool newt will has the concept of targets So essentially you have an a target consists of the application you're building in the board support package It runs upon When you do that newt can generate a bootloader image of the bootloader itself for that platform It generates a upgradeable firmware image and it can generate a manufacturing flash image When it does all of those steps when it generates the manufacturing flash image, it generates a Shot to 56 of that flash image It generates a flash map that gives you a picture of how the flash is laid out So when your images come up, they can actually understand what version of flash they're running against and it creates these upgradeable Software images that are that are signed with either ECC or RSA and the bootloader can check those options In addition to that what you see on a lot of the smaller Bluetooth system on chips So Nordic as an example is they only have 128k of flash Sometimes 256 so what they do is they have in place software upgrade So the idea is instead of dual banking your image upgrade you have an application in one sector and a kernel in the other sector and Then that what they do is they'll basically erase your application Write the new kernel into your application sector and then replace the kernel and then write your application So we support both options in the bootloader both the dual banked approach as well as in place firmware upgrades An image download works over Bluetooth Wi-Fi and serial as well as directly from the bootloader for preload cases like it in a maker board Debugging is a huge thing that you need to actually put effort into so this is consistent logging and statistics Infrastructure that can be compiled out at various levels So not only do you want control over you know What modules you're logging at what level and whether or not you enable those log entries to be written Where you want it to be configurable where they're written either written to RAM or flash or somewhere else But you also want to make sure that those that that can be compiled out of your firmware image So we've built in the logging infrastructure to the operating system as well as the statistics infrastructure So the majority of our debugging at Silver Spring was done via statistics We didn't have enough memory to actually count the logs So when we missed a packet when we were late on handling and interrupt when we were doing any of these things we would be counting statistics and then pulling those statistics back and graphing them and Then core dumps obviously our huge issue most of these embedded systems don't have core dumps available for them We can you can either dedicate a flash sector to do a core dump of memory We could we we dump it and alpha-fi it and allow you to use it with gdb Or we write it to the spare image slot if you're not using an image slot And then kernel level support for stack guards memory tracking and all of the things you want running in the kernel while you're doing it And you want that to be done for you You don't want to engineer that yourself and then finally power management and power management is is largely hardware and Project-specific, but you want the hooks in the system that allow you to do the hardware specific things that you need to do And so really it's just finding the right places to hook into the kernel So I'm gonna probably jump through this just just given our time But I wanted to focus a little bit on the build-in package management solution that we have so we don't use make Which disappoints some people At the same time the reason we designed our own build-in package management system is because we wanted to be able to control the entire process of Installing and reusing packages To building a system to signing a firmware image and creating that entire system So we've built our own build-in package management system called new Newt does not yet, but will in the future be able to generate a make file for those who miss make But it does a couple of things one is it's composable So the idea is that if you use new packages just like No JS or go package manager or any modern system packages can be installed and reused So the goal is over time that incubator minute core or minute core becomes the core of the operating system itself But then people who want to do innovative things or want to have a faster release cycle can release Packages on top of that and people can install those packages all of that is versioned using get so we support tracking tags Upgrades installation of multiple packages one of the first areas. I think we're going to do this is is posix mapping So we've had customers who have asked us to provide posix APIs for our OS It's kind of insane to put that in the core because posix is way too heavy weight But some of these processors are powerful enough that that you can actually have posix on them So we'll probably distribute posix support separately and newt allows us to do that It also allows people to maintain their own internal code bases So at at previous companies what we've done is we've had a platform team Which is really responsible for maintaining the operating system and their reusable components across many products But then we stamped out individual products based upon that platform that we've developed This is the building package management system allows you to have the minute core and track to a specific version of my new Core to have your own internal platform team libraries and then to have per product instances of that and combine that all together In terms of build it's it's a very Standard build system we support parallel compilation. We support building multiple targets at the same time and having that We support GCC primarily as the toolchain we have not added IAR support, but the system itself supports multiple toolchains In addition to that one of the benefits of owning the build system is the artifacts that you generate So on every build as an example we dump the entire get revision history that's along with that build We create a shot of all of the libraries and everything in the system So that we actually have an accurate picture of the source that's been built and when it's been built in all of the History that that that is from that image so that when you compile and you build a production image You know exactly what was built and what where it was built and all of that's with the image We provide introspection features so the ability to not only see what the size of objects are But also to see what the size of various functions and symbols are we have the build tool actually go and do that for you and Then there is this enforced hierarchy that we rely on from our build system And so as an example the hardware support packages are built into board support packages Which define you know board level features where pins are what clock speeds are and then we have MCU support packages That the board support packages will rely on so nrf 52 nrf 52 nrf 51 Sam d21 that we rely on and The build system itself understands those dependencies and it understands the concept of a BSP in an application and has special rules for each of those and then system definition and Bundling of debugger support so one of the biggest issues we always have is that Debugger tool chains seem to be maintained separately from the operating system support that runs them So newt has built in support for connecting to a target Calling out to open OCD starting open OCD making sure that J link is bundled making sure we have the debugger Supported for every single BSP So when you actually go and use newt on that particular board You can debug it you can load code on it You can run it and you can take that same image that you're debugging and you can create a downloadable software image and flash image from it So I guess and I'll leave a little time for questions here. So on security. There's a couple of things we do We've talked about signed firmware images and secure bootloader We do have the ability to you to bundle security libraries and we do test security for the users of minute So that you don't have to go and test DTLS or test TLS or any of those things in addition to that We also provide API's for unique a device identification So, you know a lot of what happens when you manufacture these devices is you really care about having a unique ID Most system on chips these days actually provide unique IDs that you can leverage in the hardware So we provide API's for getting those unique IDs For generating private certificates using the unique IDs and random data and then storing that in the system So that if you want to develop a provisioning system against this you can do that In terms of initial hardware support So really we we targeted Nordic as our first platform So the idea was we really wanted to paint a picture of what the operating system should be and We chose the nrf 51 and 52 to do that because we really like the chips They're they're the most popular broad market Bluetooth chip. They have Very good support and very clearly documented API's for the chip, which is awesome And so it really allowed us to go and build the operating system. We wanted to build but we also built against the ST micro and Atmel platforms because we wanted to have a picture of how things looked separately as we were develop right for example The ADC between an STM and a Nordic. They don't look remotely similar, right? STMs have clock domains Nordic stone Nordic has this concept of a PPI where you can have multiple events get chained through the processor without waking up the CPU You don't see that in all of the other processors So being able to have multiple platforms that we worked on to begin with was really important Which is why we chose these two, but we really optimized for the vision on the 51 and 52 So what's next? Next is more boards and more processors. So we've spent an excruciating amount of time On our HAL APIs, which don't which is kind of miserable because you don't actually provide any additional functionality But you keep rewriting the same code over and over again But we were pretty happy with where the HALs have ended up We're pretty happy with how the board support and MCU Structure actually ends up looking so really the next phase I think on the project level is just to start expanding board support as dramatically as we can and really just implementing Hundreds of boards and processors and we welcome and hope for contributions We we think that there's a lot of if you're looking for kind of interesting problems I think in the MCU space the most interesting problems have to do with wireless networking And so we're definitely going to be working on a future wireless networking stacks and are looking for people to to work on with us we are planning on adding Ethernet support because it's easy to add and There are chips that do it SEM sensor APIs and sensor management is going to be another big area focus Kind of post 1.0. So right now we have no APIs for sensors We just have the HAL and the driver infrastructure in place. So as we expand board support We're also going to be expanding sensor support In the operating system and having good APIs for all of those and then finally you decide, you know, this is not my project It's not runtime's project. It's the contributors project And so if you want to add things to it join the mailing list submit patches and you have an equal vote as anybody else So more information's at minute data patchy.org feel free to join them out the development mailing list That's where all decisions get made all discussions happen Nothing in the project happens without being discussed on dev so if you want to have a picture and hope exactly where the state of things are just join dev and jump in Are there any questions We're using the Apache license It's Apache to license for everything No, we're using embed TLS We import both tiny crypt and embed TLS We use tiny crypt for parts of the Bluetooth stack because it's a little bit smaller, but then I'm big TLS for everything else Sure, it's platform specific on the 51, which is the one we care most about Because it's by far the smallest We're about if you if you add it all up including Including this OIC support. We're currently pretty much overflowing the space But we will optimize that down. We're about without OIC support We're about 9 kilobytes of RAM it's a total of 16 kilobytes of RAM on the processor itself and We end up being about 90 K of code We we think we can get that down to about 70 K of code you have to strip out like Bluetooth security and a few things there But we think we can the footprint for kind of running the entire system with with OIC will be about Between 70 and 80 K and the RAM won't get much better, but we will be able to bring OIC in there That's without an IP stack. Yeah The IP stack obviously makes it much bigger hooks It's a couple of things. So there's a BSP power state call which essentially per board support package You implement power states and we define a few set of Predefine power states and then you can just define your per user power states from there So we have sleep deep sleep off on Suspend It is we provide the hooks, but the user is supposed to implement it So what the system does so the driver infrastructure themselves has suspend and resume in them Now the driver the guy who writes the driver has to of course implement suspend and resume and the idea is that One task could open and close a driver and another task in the system is the one that could be putting it to sleep And so you want to be able to suspend anything that's happening safe state So when you wake up the system again the the task that has the driver open doesn't notice that anything's changed So that the drivers have hooks for suspend and resume in them And we hope for all standard drivers to have implementations of suspend and resume The BSP power state call is it's up to you to actually turn the system into the various power states So it's really just a framework for you to call that And then we provide one other hook in the system We do clock domains for you. So, you know Ports are the how implementations map pins to ports when ports are unused. We turn off the ports We have reference counting on clock domains. So when the clock domain is no longer used We turn off the clock domain as well And then when you want to like move to for example a super deep sleep The only real support that we add there is we allow you to locate code in specific areas of RAM Because on a lot of these processors You can you know the Nordic for example has 64k of RAM on the 52 but you can go down I think to 4k in the lowest RAM retention state and What we do there is essentially allow you to have a function that basically operates It's the only function that gets called when you come out of deep sleep and you have a section of RAM That's retained and then you really decide whether to reboot reboot reboot the entire system So there's probably smarter things we could do But we thought kind of as a first-cut implementation like you might want to depen debounce a button press as an example So you have a little code that can come up Okay, that has the button been pressed three seconds if so cause a full boot if not go back to sleep And so those are the hooks we have today although if people want to improve that or if their suggestions were We think it's important I think it was the entire system It was it was engineering something that was Allowed you to quickly build the operating system components Absolutely, in fact, I think our bootloader was demoed at a recent concert Conference where it was the bootloader for Zephyr Certainly not out of the project scope We decided you know personally to focus on 32 bit because it just made life easier and everything seemed to be 32 bit But if somebody submitted a patch so long as it didn't increase code size on 32 bit, we'd be fine No, no, it's just it's been optimized for 32 bit, but Anything else? Well, thank you very much