uh thanks for coming everybody. Sorry for the uh delay there. It's early; everyone's waking up. Um, my name is uh Sam Fredman. I lead firmware engineering for Goliath. Goliath is a uh Cloud device management platform for embedded devices. Uh, we work on Zeper, which is why we're here. Uh, we also work on a couple of other platforms. Um, my talk today though isn't about gas; it's about microservices for microcontrollers, composable software architecture for embedded systems. Um, oh, also I wanted to mention this is my first conference talk ever, so thank you for being here for this momentous occasion for me. Um, all right, so if you've heard of microservices, you probably are wondering, like, Isn't that a cloud thing? Why are we talking about them at an embedded conference? Um, and it's true that as microservices, the term is like mostly known; it's a cloud thing. And it's also true that I chose that term to make my talk sound a little bit more interesting, but we're really talking about here are just really

modular software, uh, in the Cloud World, um, microservices are like very small individual pieces that can be deployed very quickly and very independently, and it's designed so that really large teams, like, you know, the big companies, don't need to coordinate thousands of engineers to release, you know, their web app every time they need to release it. They can release small pieces of it all the time, um, that's not usually a problem. Firmware, you have to update the whole firmware all the time anyway, and our teams tend to be smaller, um, but we can still gain, uh, a lot of the benefits from, or a lot of benefits from using, uh, a sort of microservices-like architecture. What it looks like in firmware is, again, just very small, very loosely coupled independent tasks, is, uh, we'll talk more about what a task is, uh, communicating through, uh, well-defined IPC mechanisms, and so the analog there would be like, you know, through a lightweight, uh, API in the cloud world, where just using IPC here in firmware, um, the benefits you get from that are

similar to the cloud world, you can move faster because smaller things are easier to test, they're easier to understand. Things that are easier to understand, they're easier to maintain, um, and they're more isolated. So, if you need to make a change into one part of your firmware, you're less likely to have that impact the rest of your firmware, um. That's just good software architecture, software practice, I think, for any software that you write, um. But the part that I want to stress is actually composability, and we're going to talk about that more here just in a minute. This is really why I think this architecture shines for firmware, um. So, what is composability, right? You can think of it basically, you have a bunch of Lego bricks, a bunch of small pieces that you can assemble to create something bigger. Just like with Lego, if you have, you know, just a very simple brick, you can combine them to create, um, very complex, very beautiful things, right? It's the same way of thinking of that for your firmware, right? You want to break things down into the

smallest pieces so that you can pick and choose them. The reason they need to be small is that having smaller pieces makes them more reusable. If they only do one thing, then you can pick it up and use it. You don't have to worry about, you know, is it going to bring in a feature I don't need? Is it going to have a dependency on a piece of hardware that I don't have because it's trying to do too many things? This little guy in the corner, we call him Echo, he's pointing right here because this is why that's really important for firmware in the cloud world. When you deploy your new web app, the old version is basically gone, right? It's deleted. No one's ever going to use it again. All of us who make embedded devices know that's not how firmware works, right? Once you deliver a product into the field, that product needs to be supported until it's no longer being used, right? Even if you can update the firmware, your users may not choose to update.

it and uh as you release new hardware versions, right? Adding hardware, changing hardware, removing hardware, adding features, removing features. You still need to support the old versions of your product. Having uh composability allows you to use the same code because what you're doing now instead of rewriting your firmware, which I've been part of a lot of teams who have changed one little thing in their hardware and rewrote the entire code base from scratch. Instead of doing that um, you're now just adding a piece, adding a software module, adding a task, removing a task. Uh, the configurability of it, the composability is what allows you to reuse your code faster, better, while also getting all of the other uh benefits that we talked about earlier, including you know, better testability and maintainability. Um, all right, so what does that actually look like? Um, we talked about tasks a little bit earlier. Tasks are these independent actors in a system. They need to communicate through IPC. Uh, one thing that I mentioned, lots and lots of small tasks, which if it might have made some of you think like

why I don't have memory for like a thousand threads running. Um, so we're also talking a little bit about event tasks, which are a way of having really small pieces of independent software functionality, but without using up all the resources of like a heavyweight thread for them. Um, so tasks, like I said, they are fine-grain, many, many small tasks. You want your tasks to be as simple as possible. They should really just do one thing and should think about them as we call, I'm calling them business functions here, but essentially either a feature or hardware support to do one of those things. Um, and they should be loosely coupled, um, which is something you've all heard before. The way I like to define it is, uh, no public interface, so there are no header files for tasks. You cannot call into them. They have no APIs at all. Um, instead, everything, all communication is through IPC, excuse me, uh, through indirect IPC. So this means you, you know, they're not exposing a queue that you put things into, but instead there's some

other, uh, in a process, uh, mechanism that allows these threads to communicate with each other without actually knowing with whom they're communicating with. And we'll get into that in a minute, uh, and then these tasks, because in order to ensure that they can be added and removed at will, um, they all need to sort of be on the same footing, right? You can't have um a main task which is trying to coordinate those tasks because then you'll have to change your main task every time you add or remove a task. Uh, doing Hardware initialization in the task itself becomes difficult because you know if you have three tasks that are using the same driver and one of them sets it up but then that's the one that you want to remove. Now you have to figure out where else to initialize that driver. Um, so the uh I guess these are a lot of like prohibitions which I think is uh maybe the main takeaway from how to think about this. It's how do we keep everything really self-contained. How do we keep everything as concerned with its

one function as possible so that when that function is no longer needed, we can remove the entire software component, or similarly, when we add a new software component because it's only concerned with its one function, we don't really need to make changes or the minimal set of changes to the rest of the firmware. Um, and as I mentioned, uh, tasks, uh, we have this event task as well. So all threads are tasks, but not all tasks are threads. Um, for IPC, there are a couple different ways you could do this. I, uh, prefer pubsub, or, and this is not like a product, so I've capitalized it. Um, this is just generally a, um, a communication paradigm that you can think about. Um, I'm sure many of you are familiar with the basic concept, but, uh, you have topics and devices published to them, or sorry, tasks published to them. Tasks can subscribe to them and receive messages. The important thing about it is that the focus here is on identifying that data, so naming the topic like accelerometer, you know, or temperature, or

GPS or whatever um sensor data is like the easiest one to think about. So, probably going to over-index on that um and what the form of that data is rather than on how modules are interconnected um. There are going to be more concrete examples later, I promise. Right now, it's a lot of talking um and and that's the important thing, right? So, modules are communicating without knowing what the other party is and that's important because now you can remove, change that party, add a new one without needing it. It's also important to note that this is many to many and that's also important for like when you want to add a new feature that can like hook into an existing data stream, right? Like that's just naturally supported um. This removes the intertask dependency. So, we mentioned that there's no public API. The reason why that's important, right, is again because like if you stop compiling in a function that another module is calling then that you're going to fail to link um. So, these TPS don't communicate with each other, their

dependency is on Pub/Sub, so Pub/Sub has to be there. Whatever your Pub/Sub bus is, needs to be there in the system. But that's pretty much the only direct dependency for the system. Another advantage of this, and again I want to stress that for me, the main point of this is composability and being able to port multiple firmware products with one set of code, but there are a lot of other benefits too. One of them is removing developer dependencies, development dependencies. So if you are developing a module that communicates to and from Pub/Sub, right, this kind of gives you a built-in abstraction barrier where you can easily inspect or inject data in order to test a module before the rest of the whole software is ready. And what's great is not just doing that when you are in development, but in testing later too, because these injection points basically don't go away. They're part of the actual core system. You can use them throughout the life of the product. So where I've

used this in the past is like if you have any kind of UI on your device, and that UI is triggered based off of events. Those events are Pub/Sub messages triggering your screen. It's really easy. You a little CLI command that can just like fire off a pub/sub message and trigger any screen you need, any animations, things like that. Similarly, with pulling off data, you can just write a really simple application that just like opens up the accelerometer topic, reads it, prints it, and that becomes really easy to interact with. And then finally, the last tasks we be talking about are events. I think there's another corollary to the cloud here, which is Cloud serverless functions are pretty similar. So, I'm calling them threadless functions. It's multiple tasks, they run one thread. These are essentially callbacks that execute in response to a pub/sub message. So, you register them against a particular message. They run on a shared thread, so they run to completion, right? And it's important to note that

they are not tasks, so um, you need to be careful, think about them, maybe not quite as uh, you know, as uh performant as interrupts need to be, but kind of in that vein, right? They can't block for a very long time, right? Any sort of oper like that is going to prevent other events from running um, and so actually this is probably a good point to talk about like how do you choose what is an event or a thread um. Generally, anything that needs to like directly interact or wait on hardware is going to have to be a thread like uh, most flash rights are going to uh, you know, they can take a long time, so you don't want to do those network operations, even some sensors you need to read from um, you know, in maybe like a polling manner. If there's any kind of delays in there, tend to be threads, and then more like pure business logic tend to be events um, and again, these events, things you would use for events are probably not things that would have been their own thread or

their own task in uh like a traditional system that that you might have built before um because we're trying to really create a lot more tasks than you would normally see uh in order to create uh the small little Lego blocks and keep everything composable and again concrete examples coming all right this is uh the Zephyr developer Summit so how do we do this in Zephyr um zebus is I think still relatively new maybe about a year old um it's really great this is zephyr's implementation of a pub sub bus the uh um terminology that they use a little bit different than what I was using before um topics are channels um messages can have data associated with them which is great um the uh threads uh okay sorry so you can have what they call thread subscribers which are subscribers which are the thread tasks that we talked about um it's not shown here that they can actually have a couple of different kind of messages you can either like receive a copy of the actual message into uh your own queue or you can

receive a reference to a message as far as like the architecture part of this. It's not really so important. Um, they also implement what they call listeners, which is what I was calling events earlier. So, that's really nice. You don't have to implement your own event thread or anything like that. Um, that's already built into zbus. Um, and this takes a lot of the work and complexity for you. Um, I highly encourage you to go listen to the Z Tech talk on zbus. Um, I think it was actually phrased or like positioned as kind of like a debate, like should you use zbus, should you not use zbus. Um, all the different Tech talks are great. This one's particularly relevant for this talk. Um, the last thing, or sorry, the next thing is iterable sections. This is maybe a little bit like non-obvious about how important this is. Um, I mentioned before that there's no public interface and there's no main thread coordinating which tasks they're running, right? So, how do these tasks actually get put into the

system um essentially including a task is the same thing as compiling it, right? If you compile a task, then it gets into your build, and it will run. The way that works is using iterable sections in ZR. What this is, is basically um, you place a struct into a particular Linker section at build time, and then the Linker grabs everything from that build section and puts them packed into um, you know, into an order, and that essentially creates an array in Flash. And then Zephyr has um, facilities to like iterate through that. What this means is you can create basically modules, can register themselves, they can place themselves into Global arrays uh, without there having to be any kind of like central registry in your source code um, just by compiling it. The linker or make Ur is that's place there. So, Zephyr uses this for registering channels for zbus, for registering The Listener events, it uses it for um, task or for thread creation um, and uh, again, the importance of this right is that it allows, it prevents you

from having that central piece of code that is orchestrating everything. Things you need to change every time that you want to create a new version of your firmware. Instead, all you do is you set a K config option or maybe change something in your CMake file to include or exclude a component, and that becomes the entire building of the application, right? And then the last part of it is system initialization. So this also uses iterable sections, but I mentioned before, you can't rely on any task to do the initialization because you may remove that task. Zephyr has a really robust initialization system, which a lot of different levels. One of the things where in other systems actually this can get pretty hard is if you don't have a main pass to ensure that you know like you initialize things in the right order. You know, maybe your display needs the power regulator, you know, initialized first, things like that. If you're just kind of relying on like which threads run or like, you know, it can be pretty difficult. Zephyr has initialization

levels. They have initialization priorities within levels. All of this, again, done through those like section strs that get placed in the Linker, um, and this allows you to, uh, pretty, uh, fully specify the initialization order and what hardware and libraries need to be initialized, initialized, um, in those libraries and, uh, and dri themselves, so your application doesn't need to do it, uh, so by the time all of your tasks run, they're all ready to run, and they're all able to, uh, um, leverage the full capabilities of your system, uh, and again, this is important because if you remove a task or if you add a task, uh, you uh, could be changing your station, which could cause complexities when you're building the various products on your one code base. Okay, real-world example. That was a lot of talking, and I apologize. It's not how I like to, uh, do my presentations normally, um, but hopefully, this will make everything feel a little bit more concrete. Um, I want to talk about a cold chain asset tracker. Um, this is actually a cold chain. This happens to be a reference

design that my company Goliath makes. But I mostly chose that because I know there are no copyright issues with this photo. So, it's not important that my company makes it. What this is, is it's a little GPS device with a temperature sensor and a cellular modem. And you put it in your frozen food shipment, you know, in the back of a refrigerated truck, and it ensures that throughout the process or throughout the shipping of your food, it never goes above freezing so it doesn't spoil, right? So, this is a little block diagram here on the right side of that screen. The sort of rounded rectangles are tasks, and the U diamonds are Pub sub topics or zbus top channels. This is obviously simplified; there would be a lot more going on in the system normally, but for the purposes of this, I think this is a good example. So, the GPS thread, these are actually all four of these tasks right here are threads.

in this contrived example, uh, because I mentioned, right, like if you're dealing with hardware, you're generally going to need a thread, something that can block. So, the GPS task is publishing to the position topic. The sensor's task is publishing to the temperature topic. Both are being consumed by the network thread, um, that's one of the simplified things that would probably be a couple of different tasks, but both are being consumed by the network uh task in order to upload that data to some, you know, uh, cloud database where you are tracking this, or maybe a visualization tool, uh, and then also to display. So, we can display um, you know, that data locally, uh, so that's sort of the base. But let's say, uh, you know, your product manager uh, comes back to you. They say, Hey, we talked to the customer um, their TTI of like, you know, the driver's in the front. They're not looking at the screen. They have no idea uh, when the temperature rises. We want to add a new feature that plays an alarm whenever the

uh, the temperature rises above a set limit. Uh, so we can add a new task. This task is actually going to be an event task, or again, a listener in the zbus nomenclature. Um, what this task does, it just uh, runs every time there's a temperature message, and it compares that to uh, some threshold, right? And if there, if it passes that threshold, um, then it publishes the message to the overtemp uh, topic. So I just described to you the entire task, right? You can imagine that's probably like four lines long, um, just to like emphasize that like task should be really, really small. That is a feature, that's a piece of functionality, um, that's all it should be. It's in its own C file, it has no public API, it's just that one function, um, but it is a task because it is that independent piece of functionality, and it's not going to take any extra resources on your system because it's going to run on that event uh, processor thread. Uh, so it publishes to the overtemp uh, topic, and then um, that over

attempt topic will uh is oh something I should have mentioned about this. So, the arrows that show the data going, you know, like position pushing data to the network, it's sort of describing the flow of data. But remember that these tasks subscribe to that data, so they're actually calling into zbus or your Pub subsystem to say, Hey, I'm interested in position data, right? Um, so the display, we do have to change the display a little bit because we are changing the display. We're adding a new screen, so we have it register onto the overtemp topic, and uh, we create a new screen that puts up, you know, maybe one of those little warning uh symbols. We also add a new audio task, um, which, you know, maybe plays a tone or a buzzer or something to audibly alert uh the driver. Um, so that's great. Uh, that's how thre we had to change the display a little bit, but we changed it because we actually are changing it, not because it needed to be changed in order to support some other um change, right? We're the

sensor three is now sending data to the alarm task, but we didn't have to change anything in the sensor task. We didn't change a single line of code there, so that's kind of like where this architecture shows its value. But I think it's even better when you delete something. So let's say, you know, the product manager comes back and they say, Hey, you know, like these are really expensive. We don't need a display. The driver's in the front. He can't read it. Why do we need a display? Let's delete it. Let's save some money. That's it. You delete it. Like, you just delete the display task, and the rest of your firmware will still run. The all these topics no longer subscribed to by the display task, so they're no longer getting data. You no longer have to... So yeah, it's just... It's not running anymore. I actually spent quite a while trying to see if there was like more to talk to on this slide, but I think that's like kind of the point.

right is once you've separated everything into these very um distinct pieces of functionality and uh once you've ensured that they are loosely coupled you can remove things and it doesn't affect anything else right. I've had the experience in the past of trying to remove a a screen uh you know like like a piece of the UI and uh when I hit build the file system recompiled so somewhere there's some weird dependency where the file system is depending on the screen um. I never figured out what that dependency was uh but when you build it up like this and through this system um that doesn't happen anymore um. So that was it pretty quick we have about I think 10 minutes left uh are there any questions yes I don't know if we have a oh m in the mic yeah hi um thank you for the talk um just a question on how would you manage um like dependency initialization especially if you have to initialize services at different times uh sorry could you repeat the first part of the question yeah how

would you manage um initialization priority MH. So, for example, if you're the task you want to implement uh has several dependencies and you're not very sure uh when these dependencies will finish initializing. Yeah, that's a really good question. Um, so there actually has built-in support for this. There are different initialization levels. Uh, I'm not going to like get them all off the top of my head, but there are several different levels you can do before the kernel boots, several after the kernel boots, uh, some at like what they call the application Level, and then within that level, there's also um, you can set like a numerical priority, which I think is like 0 to 99 um, or some other, you know, quite large range where if you need more than that, you're probably uh, building a very complex system. Um, and so you set those uh, initialization priorities according to your system. A lot of them, you know, may not be in code you can necessarily like control, like there might be um, modules in that are like in the zeph.

tree itself a lot of those have uh cake and fig options that you can set in order to change the priority if you need to. Thank you. Hey, great talk. Um, for thought, did you think about mixing the system with linkable loable extensions so it could even like just have a small piece you can like push system or like small functionality? Yeah, um, in relation to this kind of architecture, I haven't uh thought about it till right now. I think um, I think that's actually a really great question because this can kind of enable that, right? Because it sort of um, uh, once you load that module, it can subscribe to these topics and that doesn't necessarily need to happen at build time, right? Um, so yeah, I think that provides um, I guess yeah, I think those would work really well together. Um, you'd have to be careful to like when you unload a module to make sure that you unsubscribe from all the channels that it was connected to. Um, but that's more of an implementation detail. You may not know the answer but um

performance of zbus for example. Uh, the products I'm re-architecting right now, we deal with sometimes, say, uh, 6,000 messages per second going out of the device. And so, we have to do all of the work to gather the data and collect it. So, we're dealing with a higher rate than that internally. Um, do you think zebus can keep up with that? Um, well, I won't give you a definitive answer because I don't know how fast you process it is and things like that. Um, I will say that, uh, there is some overhead. It's pretty small. Um, so, I mentioned briefly that, uh, there are two kinds of ways you can subscribe to zbus. And one is, um, where zbus will copy messages into your queue. And another one where it passes it by reference. I imagine if you're, you know, sending around 6,000, you're probably doing it by reference. So, that is pretty performant. Um, I've implemented, uh, a pub-sub architecture in the past where we used strings to describe the topic. So

you had to do some string compares, which aren't the fastest. They're not too slow, but zbus doesn't use that. They're using integer channel IDs that are defined at compile time to the linker, so that's pretty fast. So essentially, another thing that I would say, and actually I'm not sure exactly how zbus is implemented here, so take that with a caveat. The way I've implemented systems like this in the past is using linked lists. So if you have the performance there, it grows with the number of topics and number of subscribers you have. So if it's a high volume of messages going between a small number of tasks, that probably is not an issue. But if you have 6,000 tasks, then sending a message could take iterating through 6,000 subscribers. And again, I don't know how zbus is implemented. Obviously, there are ways you can speed that up, sorts and searches and stuff. So the reusable logic part

is is great. Um, I'm wondering how with like the iterable sections part, how that sort of handles um reusing the same task. So, say you had three temperature sensors and you've got a task which reads the temperature sensor and pushes it somewhere. If it's all sitting in the one C file, that doesn't like you can't create that three times, for example, right? Um, so most of the uh entries in interal section have like a name or so basically the way this works is there like a macro. One of the arguments of the macro is a name. Um, so you could actually like instantiate uh that struct that describes that test multiple times. You would, you know, it would be like uh temp one, temp two, temp three, but they would all have the same um, they would all use the same function. So, you could at least reuse that function call uh, and then uh most of these um aable sections also take like a context argument, right? Like a user void Star, right? And so, you could pass context in there to say like hey

you're actually reading from, you know, this temperature sensor, that temperature sensor, that's one big room for you. Hi, yes, I'm very new to Z, so I don't know all of its capabilities. Um, I was curious about your architecture concepts in relation to possibly multi-core usage. Is that of a play there, or uh, that is a great question that I do not have the answer to. Fair enough, but you wouldn't knock it out of the park. You wouldn't say it's a no or something like that. I correct, I wouldn't. Um, I most uh, like inter-core IPC mechanisms, kind of work with like hardware mailbox anyway, so uh, you could, I could definitely see uh, extending Z bus to like use that as sort of like a backend um, but I've never like, honestly, I've never really worked with like an SMP very much uh, myself. Right, when I've used two ques, it's been like this core does a very specific thing, so gotta, yeah, yeah, I work inc's all the time, so it's always how do you get them.

to work together, so yeah, it's interesting. Okay, thank you. Thank you. Hello, um, thank you for your presentation. Um, if I understand well, the pub-sub, you have a module or a task that is the publisher and another one that subscribes to it. So, every time a publisher publishes something, the subscriber will be notified and do something with that information. But sometimes, um, the subscriber doesn't want to be notified or the subscriber wants to get the information when it's needed. For example, uh, the over-temperature alarm that you mentioned. That could be a situation where, Oh, there's an over-temperature. I want to know the position where it happened. So, I'm interested in position now. I don't want to be getting events all the time. A new position is published. So, does uh, zebus support that as well? That's a really good question. Um, that was some slides I took out of the presentation, actually. Uh, I don't believe zebus supports it, and I'm actually not aware of like a built library in Z that does it. Um, although

anyone please feel free to correct me. Um, but what I usually refer to that is um shared State. Essentially, is what you're asking for there um. And you can do something similar where you create um a central module that can like hold shared State um. And where it you basically similar to zbus, you refer to that state by like an ID. So, you're like calling into this module and you're saying like hey give me the uh you know the current state of this identif um. Rather than like directly accessing the memory itself uh. There are a couple advantages of that. One is that this system can know whether or not that data exists or not. And that's important for like let's say you know you remove the task that sets location right. You no longer you just care about the temperature. You're not doing position anymore um. Well, you don't want to just you know display junk data right. You need a way to say well there is no position information actually um. The other thing is that uh it allows you to

uh abstract away concurrency protections so you can do all of the current concurrency protections, your mutexes, whatever kind of lock you're using, uh within that module. Um, so you don't need that in all of the tasks, uh, which in my experience, you know, some of the hardest bugs to track down are around concurrency. So if you can reduce the surface area of where those bugs can pop up, that's really helpful. Thank you very much. Hi, I actually have a follow-up on that question. Um, what that sounded like was an RPC between two modules, um, with a command and response, and I'm wondering, you mentioned not defining APIs for these modules, but typically a function-like API surface is a great way to define an RPC. Uh, can you speak to that, uh, trade-off of not defining an API for this or how you go about that? Yeah, um, so I will say, uh, to be, I was not trying to describe an RPC before, um, more of like a file system, which I hesitate to say because it's not really anything at

all like a file system but saying like give me the contents of, you know, food. Tex right more like that um for an RPC I think um you could do it like rpcs can be uh couple you generally still need to know sort of like who you're sending that request to um which can create a little bit more of a tight coupling um it's certainly less than if you're doing like a function call right um it also I think there's benefit in thinking of like the the data flow right rather than like the execution flow of of a function or of a of a program um and this gets into things like inversion of control right where it's like rather than um like asking something to happen you just say that like this thing exists and wait for somebody else who cares about it or not so um it's certainly I I would say rbcs are possible uh for sure I'm not sure that like in an embedded system though where where uh you can link everything together anyway that there's as much

benefit from it as you get in like a cloud system, where the main benefit of RPC is, you know, being able to, like, pretend that something very far away is actually very close to you. I think we're still running out of time, so perhaps one more question, and that's it. And I also look at the Discord if we have any questions there. Thanks. Um, we've implemented something sort of similar in an architecture with that, and we use sort of shared states to sort of share between different things. But my question was about the, I guess, the channels. Is there a way that a channel can know when you're publishing to a channel? You can actually know how many subscribers you've got, because if you've got dynamic tasks that are being switched off, you know, suddenly you don't need the temperature or the accelerometer data anymore. It'd be great to be able to have that sort of problem is about to go, Okay, well, no one subscribed to me, so I'm just going to go.

down into low power mode and wait until somebody subscribes again. Does Zephra channels allow for the publisher to know how many subscribers it has? That's a really great question, and I agree that'd be a really useful feature, but I don't know the answer. Sorry. Okay, right, thanks. All right, so I think formally that's the end of the session, but of course, I assume that you might have more questions. You can just ask them privately. I think we have a little break now before the next talk, so if we could just thank the speaker. Great.

Microservices for Microcontrollers: Composable Software Architecture for Embedded De... Sam Friedman

Zephyr is a small, scalable real-time operating system (RTOS) for use on resource-constrained systems supporting multiple architectures.  Developers are able to tailor their optimal solution.
As a true open source project, the community can evolve the Zephyr RTOS to support new hardware, developer tools, sensor and device drivers.