Simplicity SDK for Zephyr

Hello, everyone, and thank you for joining us today. We are going to talk about the Simplicity SDK for Zephyr, and more importantly, what it means for you as developers building on Silicon Labs hardware. Zephyr has very quickly become one of the most influential open source RTOS platforms in the embedded space. It's not just growing, but it's reshaping how teams think about scalability, portability, and long-term software strategy. In today's session, we'll cover three main things. What Zephyr actually is, beyond just the name, why it matters both technically and strategically, and third, how Silicon Labs is making it easier, safer, and faster for you to take Zephyr from evaluation to production. 
  
I'm Ananya Tungaturthi, the Associate Product Manager at Silicon Labs, and joining me today are our panelists, Matt Gordon, Julien Tiron, and Johan Hedberg. Our panel has deep, hands-on experience contributing to Zephyr, whether it's upstream development and architecture decisions or productization and tech support of Zephyr-based solutions. We also have a super strong support group of Zephyr experts answering your questions via chat throughout the session so that you don't have to wait till the panel to ask your questions. 
  
Speaking of asking questions today, throughout the presentation, feel free to submit your questions using the Q&A button at the bottom of your screen. Our technical experts are standing by and will either reply to you directly or save your question and answer in the live Q&A at the end. While we can't guarantee that we'll be able to address every question, we'll do our best to answer as many as possible. So let's jump right into it. What is Zephyr exactly? Zephyr is an open source RTOS governed by the Linux Foundation and backed by more than 40 member companies. 
  
The governance structure is focused on ensuring vendor neutrality and long-term stability. Silicon Labs is now a platinum member of the Zephyr Project, which represents the highest level of contribution in the community. So when we talk about Simplicity SDK for Zephyr, we are going to talk beyond external support layered on top of an RTOS. We are talking about deep upstream engagement and influence at the governance level. Recently, Abid Zen Xavier, Staff Product Manager at Silicon Labs, became the governing body chair of the Zephyr Project. 
  
This is a significant milestone for us, and it reflects both on our deep technical involvement and our long-term commitment to the Zephyr ecosystem. This not only gives our customers confidence, but also shows that we are aligned with where Zephyr is going and are actively helping to define that future. Now let's look at how Zephyr is structured. At the core is the main Zephyr repository hosted under Zephyr Project RTOS on GitHub. It includes the kernel, device drivers, configuration files, build scripts, and development of environmental tools. 
  
Zephyr also uses Vest, which is a meta tool that manages multiple repositories and modules. Beyond the core repository, Zephyr integrates different things, whether it is built-in stacks like Bluetooth, TCP/IP, power management, and NVS, additional modules like OpenThread, TLS, secured boot and file systems, third-party HLs, and silicon vendor drivers. What's powerful here is that Zephyr is modular. It allows developers to compose exactly what they need. Another critical aspect of Zephyr is its development model. 
  
It follows a professional open-source project process, including code reviews, continuous integration, long-term support releases, security audits, safety considerations, and things like Bluetooth qualification. There are clearly defined roles, contributors, collaborators, and maintainers. The community is very strong, with over 3,000 developers contributing, and this scale itself ensures continuous innovation and robustness. Now let's talk about the whys, because these are what drive innovation at Silicon Labs. 
  
Why Zephyr matters for developers. With our Simplicity SDK for Zephyr, you get familiar Silicon Labs hardware abstraction, pre-validated board support packages, optimized drivers and peripherals, and known Simplicity Studio workflows. This dramatically reduces friction when you're moving from bare metal, Gecko SDK, or any other proprietary stack. You get faster bring-up and a smoother transition into Zephyr. For our customers, the value is equally compelling. Firstly, there is lower adoption risk because you are not completely relying on community-only support. 
  
Second, what we prioritize in the semiconductor industry, faster time to market. We provide validated reference designs and production-ready integrations. The third one is long-term maintainability because we align upstream with Zephyr so the product isn't technically stuck on a proprietary branch. Finally, there's no vendor lock-in, so you can retain flexibility and your ecosystem choice with you. Why does Zephyr matter for Silicon Labs? For Silicon Labs, Zephyr strengthens our platform strategy. 
  
It extends us beyond proprietary stacks, attracts Zephyr-native developers, and positions us as an open ecosystem-friendly vendor. We believe customers should have the freedom to choose the right development model for their product, and Zephyr enables that choice. Like I mentioned just now, I think it always comes down to choice, and this slide really breaks down what we mean about that in practice. Firstly, we want to meet developers where they are. Some teams are deeply comfortable in low-level embedded development. 
  
They want full control, deterministic timing, and minimum overhead. Others are structured as RTOS-based software teams building complex connected systems. Our aim is not to force either group into a single workflow, rather to support you wherever you choose to go. Second, this gives you the ability to optimize for performance and for system scale. If your priority is maximum efficiency and tight control, then bare metal makes perfect sense. If you're building future-rich IoT devices with multiple stacks and services, Zephyr helps you scale that complexity faster. 
  
You pick based on your product requirements, not because of the ecosystem and environment constraints. Thirdly, this approach helps to reduce adoption risk and lock-in concerns, so you don't have to commit to one model forever. You can start simple and scale your software complexity over time on the same hardware. That lowers your architectural risk and protects your long-term roadmap. Finally, this flexibility helps accelerate time to market across different use cases. Some products need deterministic real-time devices, others need full connectivity stacks and rapid feature iteration. 
  
Instead of forcing one development model across the entire portfolio, we let you choose the fastest path for each product. Like you, we don't want today's session to be the end of our conversation about Zephyr, so we have several upcoming engagement opportunities where you can see Zephyr running on Silicon Labs hardware in real scenarios, not just at a conceptual level. These sessions would go deeper into hands-on demos, development workflows, and how Simplicity SDK integrates with the upstream Zephyr. 
  
So if you're considering Zephyr or even just exploring, I strongly urge you to register and join us at Embedded World Nuremberg and the Zephyr meetup that we're hosting at Rennes, France. Our panelists, Julien and Juhan, will be there too, and you can catch them there and have some great conversations about Zephyr. So without further ado, now that we've established this background, let's turn to our panel and talk about all things Zephyr. So I'd like to welcome our panelists for the day, Matt Gordon, Julien Tiron, and Johan Hedberg. 
  
Hi, everyone. So before we begin, let's just go around the table and talk about your backgrounds in software development and what makes you excited about Silicon Labs and the continued growth in the Zephyr ecosystem.  
Matt, can we get started with you? Yeah, sure. So, my name's Matt Gordon, and I'm the product manager for RTOS' and software platform at Silicon Labs. And I have been in the RTOS space for, I guess, over 20 years now, really starting on the software development side with Micrium, which was a proprietary RTOS provider, and then kind of moved over more towards the product management side. And so now at Silicon Labs, I manage the different RTOSs we support, which includes Zephyr. And certainly excited to see what Zephyr has to offer moving forward. It's a project with a very strong foundation and a very strong user base. And so I think it really has the potential to become a de facto standard in the embedded space moving forward. Definitely. Thank you so much for joining us. 
Julien, can you go next? Yeah. So I'm Julien Tiron. I'm a software R&D manager at Silicon Labs based in Rennes, France. I started my career in the embedded wireless development at STMicroelectronics, working on Bluetooth solutions, and then I joined Silicon Labs seven years ago to work on Wi-Fi. And through my experience at Silicon Labs, I worked on our different wireless solution, like our wireless stack, like Wi-SUN, Z-Wave, and now working on Zephyr. And I think, yeah, bringing, let's say, the wireless expertise of Silicon Labs to the Zephyr ecosystem and bringing the Zephyr ecosystem advantages to the Silicon Labs hardware platform is a strong combination. Thank you so much.  
We also have Johan joining us today. Yes. Hello, I'm Johan Hedberg from Finland. I've been doing open source basically my entire career, most of it or initially on the Linux side, and then 10 years ago, I got pulled into the Zephyr project, actually even before it was launched. So I've been there since the very beginning. And on the wireless side as well, I implemented the original Bluetooth stack for Zephyr, and I've been the maintainer for that part since the beginning. I've held a bunch of other positions within the Zephyr project. I was the release manager for the most recent release. Now I've been at Silicon Labs for the past couple of years, basically helping ensure that we will have the best-in-class Zephyr support for our hardware. Thank you so much. 
 
 So super stoked for this today, and let's jump right into the panel. So let's begin with you, Julien.  
What do you think an ideal developer journey looks like for someone who's building today with Simplicity SDK for Zephyr?  
Yeah. So basically, as you start your development journey with Zephyr on a Silicon Labs platform, you will have two options to get your software. Obviously, as Silicon Labs, we offer and we upstream our development into the main Zephyr project, so that's a great place to start using Zephyr. You can use the latest and greatest on the Zephyr development branch to play within the ecosystem, but we also offer a downstream repository where basically we ensure the quality of software through our standard quality process, and that we can provide added support when you decide to go in production.  
So the first step when you will want to start your development is to select an hardware kit or a target you will start developing for. And for that, Silicon Labs offer different options in term of hardware kit. So starting from our radio board plus main board option, where you would get the full-fledged and full debug capability on those board, where you have an Ethernet port to connect your J-Link debug probe. You also have power consumption monitoring capabilities. For a more mid-range solution, we provide our dev kit that are small boards that still retain an onboard USB debugger and a few sensors around our wireless SoCs.  
And finally, if you want really to optimize your cost, we provide our explorer kit hardware that really focus on the bare minimum with our wireless SoCs, USB debugger, and a few push button and LEDs. So that's the first step. Then you will want to go fetch Zephyr, so install Zephyr on your machine and start using West, which is the swift army knife of Zephyr that will help you build, flash, or debug with Zephyr application on every hardware platform supported by Zephyr. And then browse through the sample application, find the best sample application, the closest to your final application. That will be a good starting point for your development. Something that you will want to check out during your developer journey through Zephyr is two topics, so the device tree and Kconfig, that are two of the foundation of the Zephyr development. So the device tree describes the hardware you will have and its initial configuration, while Kconfig allows runtime configuration of the Zephyr kernel and the different subsystem you will use in your application. And once you go through those steps, you will be ready to start developing and playing with Zephyr up until you go to production with that software. Thank you so much for that insight.  
So for those of you who want to explore this developer journey further, you can find it on our website under Simplicity SDK for Zephyr.  
And speaking of the developer journey, Johan, I'm curious, how is Simplicity SDK for Zephyr essentially different from the upstream?  
Sure. I think I would approach it first by looking a little bit on what's the same with upstream. So, the basic approach that we've taken is an upstream first philosophy, where we try to work in the upstream by default. And that means that we've ensured best possible integration with existing tools and solutions that Zephyr offers, and have all of our code there that makes sense to be there. This is also a very practical thing for us because it's a way to reduce the maintenance overhead over time, making it easy for us to move to new Zephyr versions as they are released by the upstream project in the future. We've also taken advantage of the West meta tool in Zephyr, which allows for a decentralized multiple repositories approach. And we actually have our own manifest repository downstream, which builds on top of the main Zephyr tree. And most of the changes are encapsulated within that repository.  
So the actual Zephyr main tree itself doesn't really have many modifications. Now, looking at the differences, I would say those come from two main fronts. The first one is level of technical support and also the support channels. So those can be assumed to be pretty much the same for our downstream SDK as they are for any other Silicon Labs software product. And the other one is quality assurance. So, we're not able to control every single change that's happening in the upstream Zephyr. So as we prepare to make a release, we need to have something that we can fully test and control the changes that are going into it. So, we base the downstream SDK releases on upstream Zephyr releases. But after an upstream Zephyr release happens, we do additional testing to make sure that it works perfectly or as good as possible on our hardware. So that's where the quality assurance comes to play. There are some technical differences that you will today find downstream, in particular related to hardware crypto integration. So there are some aspects why we've done that in the downstream tree.  
We're also working on making sure in the longer term that that will be available through upstream itself. But for the best possible experience with our hardware, that's where you would find it. But in practice, maybe 90% of what you get, you will get with a pure upstream experience as well. Got it. Understood.  
So just circling back to what you said about technical support, Julien, what does technical support look like for products that are built on Simplicity SDK for Zephyr?  
Yeah. So Johann touched on the topic a bit through the upstream and downstream comparison. We offer, obviously, different way to support those two solutions. 
For the upstream, what the Zephyr project did is that they set up a Discord server with dedicated channels for each topic, and you'll find in those channels a SiLabs channel where our team, so our developers and also our support engineers, are available to answer questions. One upside also is that you can be helped by another member of the community in that Discord. Obviously, the first step as well is to go through the documentation. So both on the Zephyr side, there is a good amount of documentation around the Zephyr project. 
And then you can also go on the Silicon Labs side for the hardware-related documentation or data sheet, but also our documentation space for software, docs.silabs.com, where you'll find Simplicity SDK for Zephyr specific space where we have documentation on how to get started, specifically with our Simplicity SDK for Zephyr. And in addition to that, we also use the standard Silicon Labs community forum. So if you go to the community.silabs.com, you'll find a Silicon Labs forum where you can ask question, whether it's Zephyr-related question or Silicon Labs hardware-specific question. 
 And finally, for larger customer, we offer a dedicated and private support platform where those developers can interact directly with our support teams. Awesome. So a Discord server community, and for our bigger customers, we also have a private technical support platform. Yeah, exactly. Amazing.  
So Matt, I have a question for you. There are a lot of options available to developers today, and when it comes to picking which one we want to choose, what application requirements or architectural constraints do you think have to be considered when you're driving the choice between Simplicity SDK for Zephyr, any other RTOS options, or a bare metal approach, for example?  
Yeah. So I think RTOS choice or the choice between RTOS and bare metal designs can be a somewhat controversial topic. And definitely, there are a number of factors that generally go into the decision that developers make on their choice of an RTOS. So, I would want to be careful here, but I think, just kind of painting-- Well, maybe to go back to what you showed in the introductory slides. Certainly, our goal at Silicon Labs is to be flexible and to help our customers use the software that makes sense for them. 
 So we do support a number of options. We have our Simplicity SDK where we support bare metal designs. We have FreeRTOS as an option there as well, and now we have Simplicity SDK for Zephyr, where we can support Zephyr projects. So, there are some technical considerations, and this is kind of painting the offerings in very broad strokes, but I would say looking first at our Simplicity SDK, that's been our default software offering for years, and so it represents years of software development work, years of optimization for our hardware. 
 And it supports all of our wireless technologies. So it's our full-featured offering. It happens to be our optimized offering, again, something that we supported for years. So certainly for developers who are using certain technologies that we do not yet support in Zephyr, or that have needs around performance that we might not be able to meet at the moment at Zephyr, I would direct them towards Simplicity SDK. Also, again, if there's just a preference or a history, "I've used bare metal before, I'm comfortable in that," or, "I've used FreeRTOS before, I know the APIs, I want to use that," you're certainly welcome to do that. 
 And then on the Zephyr side, as we've discussed, big advantage here is the openness and the portability, that you have this community-driven project, vendor neutral, supports a wide range of hardware platforms. And so that can be beneficial for a number of reasons. So we have that option available now to developers for someone who prioritizes openness and portability. At the moment, we're limited on the Zephyr side on the wireless technologies that we support, but we'll be looking to expand that going forward. So, we think that'll be less of a limitation in the future. Nice.  
 
And speaking of the wireless industry, we all love to talk about security. I think we're always trying to build secure devices and systems. So where does security fit in with the Simplicity SDK for Zephyr story?  
So I think security, obviously for years, has been a priority at Silicon Labs. We have-Secure Vault, which is an offering for many of our devices, where you have features like crypto accelerators, the secure engine, and this is what has helped us achieve various levels of PSA certification on different devices. 
 And so just at a feature level, we're trying to support as many of those features as possible in Zephyr, so things like secure boot and hardware-accelerated crypto. But I think, taking a step back, it was very reassuring when we started getting involved in Zephyr to see that security is also a priority for Zephyr, and it's very much a foundational part of the Zephyr project. So, Zephyr has a dedicated security subcommittee. They've got very well-defined processes for dealing with security incidents. 
 So there's a product security incident response team, a PSIRT, which something we have at Silicon Labs as well. And Zephyr's actually a CVE numbering authority for security vulnerabilities, which is very impressive. So, it's a project that has been following best practices in security for years. And in many cases, actually goes above and beyond what's required by the relevant governments and regulatory bodies. So I think that's key as we move forward on Zephyr, is that with Silicon Labs Zephyr, you have two organizations that are very much focused on security. 
 So I think there'll be a lot of opportunities for us to collaborate in the future on different security features and initiatives. Of course, and Secure World is something that we all always talk about. It's one of our biggest offerings. So that's amazing. Johan, I have a question for you. We always talk about ecosystems and compute ecosystems becoming more and more complex day by day.  
 
So how can an RTOS like Zephyr simplify development for these complex SoCs?  
Sure. So, ever since the beginning, Zephyr has aspired to be a so-called keys included solution, where you get all the necessary tools, subsystems, libraries, protocol stacks that you need to create a complete product. 
And in fact, that was one of the, I remember, the original mission statements, how we wanted to differentiate the project from the competition, is that you get all of that as part of the project itself. You get all the standardized driver APIs, which allow you to move between different kinds of IP blocks of the same driver class. All the subsystems in Zephyr are built on top of that, so you automatically get platform-agnostic subsystems and protocol stacks, thanks to that kind of layering and architecture. 
You also get all the community support, which comes with a large project. So, many companies, hundreds of engineers, who have been looking at solving these solutions for many years. And there are a bunch of tools available in Zephyr to manage complexity. I mentioned the multiple repository model through the manifest repository and the west meta tool. That's one way that you can take advantage of, depending on where you get the different components for your software project for. Then Julian mentioned Kconfig, the build-time configuration language, which we actually took from Linux because it's been proven through many, many years to be a very well-suited solution for this problem. 
And then perhaps I'd say the most powerful tool in Zephyr, which Julian also touched upon, is Device Tree, which is the language used to describe your hardware and its architecture. And it's really Device Tree which allows Zephyr to scale to the, not just the number of platforms it supports, but also to the high level of complexity of each individual platform that Zephyr supports. I know there's a pretty high threshold and a steep learning curve with Device Tree. People often stumble on the kind of build time errors you get when you have some small issue with your Device Tree definition. 
But there also, the project has done quite impressive improvements recently. There's, for example, a tool to analyze and to explain many of the common errors that you can get with Device Tree these days. So, it's a big project and it, simply by its nature, had the necessity to come up with solutions for complexity. And, yeah, all the things I mentioned are part of that. So far we've talked about our offering, the tech support that we're giving, and where we position ourself, and how we coexist with all the bare metals. 
  
But looking ahead, I'd love to know your views on what's coming.  
 
So Johan, what is happening in the Zephyr space today that you are most excited about? 
 There's lots of technical things, improvements coming in the project. But I'd like to touch more on the, I guess you could call it the social side. So, I mentioned Zephyr is 10 years old. Actually, this year is the 10-year anniversary of the project, and it was at Embedded World 2016 where the project originally launched. So there's going to be a whole bunch of things commemorating the 10 years, and Embedded World, just in a couple of weeks from now, is going to be the kickoff for all of that happening throughout the year at various Zephyr-related events. 
So I'm excited about that, and the meetup that we are arranging, Silicon Labs is arranging in Rennes later next month. And then there's also going to be the Zephyr Developer Summit later this year. It's going to be, I think, in the late autumn this time. And, yeah, it's going to be fun going to those events, so that's what I'm looking forward to. Of course. We all are, and we're all super excited for Embedded World because that's the kickoff for everything coming up. Matt, I have a question for you from something that you said earlier. 
  
You dropped a little Easter egg for us when you said we are looking to expand into other technologies. So could you maybe shed some light on how Zephyr is going to spread across our portfolio, and what developers can watch out for?  
Yeah, certainly. So I mean, when Silicon Labs first joined Zephyr and first started getting involved in Zephyr development, I think kind of the overriding idea was that we would join our wireless expertise, our wireless technology, with the code base that exists in Zephyr, open portable RTOS. 
And so we started focusing on BLE and Wi-Fi, and I think that was primarily because that's where we saw a lot of the initial interest, and that was where we had a lot of shared code that we could reuse. But yeah, certainly the expectation is as we move forward, we will expand to some of the other wireless technologies that Silicon Lab supports. And so, I don't want to get too much into the specifics on our roadmap here. There are still some plans in flux and some dates being established. But we are certainly looking right now at 802.15.4 specifically, bringing some of those technologies in in a meaningful way into our Zephyr offering. 
  
So, yeah, again, the idea is to leverage our wireless expertise and make it as easy as possible for Zephyr users to take advantage of some of the wireless protocols that we support. Awesome.  
 
So my last question before we sort of go around the table. Julien, are there any upcoming features or releases that developers should specifically watch out for in the upcoming months?  
Well, I think one of the big focus for us in the upcoming year and after, beyond that, is the support of Zephyr on our Series 3 hardware platform. 
 So with the release of the Simplicity SDK for Zephyr earlier this year, we have a strong focus on our Series 2 hardware platform. And, yeah, the next year will be focused on the Series 3 support with platform that have more compute and that will also be able to leverage more of the Zephyr ecosystem and middleware. So that's where I think Zephyr will have an even more, a bigger impact on Silicon Lab's strategy because of the additional compute that coming with our Series 3 hardware platform. The fact that we are using a 22 nanometer transistor node and that we have more compute to offer to those embedded platforms. 
  
So I see that we're already getting a lot of questions live from the audience, but before we get to those, I just have one last question to ask all three of you. Maybe we can go around the table starting with you, Matt. If a developer wants to try Simplicity SDK for Zephyr from today's session, where would that be?  
Yeah. So we didn't really touch much on the details of getting started, but, for Simplicity SDK for Zephyr, we do have, I know Julien mentioned earlier, the doc space, docs.silabs.com. 
So we've got dedicated docs there for Simplicity SDK for Zephyr. That includes getting started material. Zephyr, I think, is pretty well known to have a very good getting started procedure, just generically for the project. But there are a couple of minor modifications we make to that, and that's in our documentation in the docs.silabs.com space. So, yeah, that would be the recommendation is head over to the doc space, check out the getting started guide. You can also go to the actual repo in GitHub, where we have our code stored. 
  
But, yeah, the getting started guide would be the best way to move forward. Perfect.  
Julien, can you go next?  
Yeah. So one of the important aspect, I guess, for a reason to try our Simplicity SDK for Zephyr is the fact that it's fast-tracking embedded development, and especially if you are looking for more advanced application like video or AI ML application in embedded systems, leveraging the complex and vast Zephyr middleware ecosystem is where I think you will get the most value out of that SDK. 
  
Julien, what are your thoughts on this?  
I'd say, for existing Zephyr users, try it out. You'll be positively surprised on the familiar experience you'll get because we've really put effort into integrating well with the usual tools and solutions of Zephyr. For developers who are new to Zephyr, I would say that it's an excellent way to try out the real-time operating system that has had really impressive growth during the recent years and see how well it works with Silicon Labs hardware. Thank you so much. 
  
And now I just showed a few questions from the Q&A chat, and feel free to just pick it up and start answering. So the first one here is Zephyr versus FreeRTOS, what are the advantages?  
Maybe I'll start with that one and, Matt, Julien, if you want to add something, let me know. But a big thing, as I said, with Zephyr is the fact that it's coming with an impressive set of middleware and a huge ecosystem compared to FreeRTOS. So I've worked here within the FreeRTOS ecosystem or with our SI SDK. If you want to bring a video middleware, you'll have some effort to port that to FreeRTOS within the SI SDK. 
With Zephyr, you have existing middleware where somebody else has made the effort to port it and to maintain it, that you can leverage out of the box. So that would be my first and main advantage. Okay. Yeah, I would just add that it's a little bit of an unfair comparison because it certainly is two different models. So FreeRTOS for years has really just been an embedded kernel, and it's a very solid embedded kernel. We support it. We have many customers who use it. Very low overhead, very efficient. 
But Zephyr is really a full software platform. It's drivers, as Julien said, the middleware, as we mentioned earlier, the tools. So it's, yeah, a little bit of a different model. And I think maybe if you're comparing kernels specifically, I think there are actually a lot of similarities in the models supported and, again, overhead, just kind of the basic task scheduling approach. But yeah, it's a little bit, I would say, of an unfair comparison in that you're really comparing a full software platform with an embedded kernel. 
  
Right. There is another interesting question here. How is Zigbee support?  
So this is kind of related to what I mentioned earlier about expanding into 802.15.4. At the moment, our focus on Zephyr is really BLE and Wi-Fi, so your best bet for Zigbee would be Simplicity SDK. But Zigbee is something that we have on the roadmap and that we're considering moving forward. So, as I said, I don't want to get into too many specifics there on the implementation and the dates, but that is something we are looking at as we move forward with Zephyr. 
  
Okay, got it. Another question that we touched upon a little, but where can I find the getting started resources for Simplicity SDK for Zephyr?  
So I think we touched on it quite a bit, might just be a good idea to reiterate. Julien, if you- Yeah... could take that. Yeah. So, as Matt said, I think the Zephyr project documentation is really where you want to get started because the flow described there is similar, whatever semiconductor vendor you use and whatever hardware supported by Zephyr you use. 
So I would get started here. Obviously, if you have a Silicon Labs hardware, you can also go to docs.silabs.com, and go through our own Simplicity SDK for Zephyr documentation. That's the two starting point I would recommend. Yeah. There's a third one as well, which would be the SI SDK for Zephyr main repository downstream. So there's a README there, which actually has links to both of those places that you already mentioned. Right.  
 
There is another interesting question: How does Zephyr enable better platform flexibility, and how does it improve the ability to debug embedded applications? 
So maybe we can take it one at a time. How does Zephyr enable better platform flexibility? I'm wondering, better than what? I guess we went through some of the tools that Zephyr has. I'm not going to enumerate those again. But that's one of the main design focus areas of Zephyr that the product has wanted to solve and wanted to provide good solutions for. I don't know, does somebody else want to elaborate? Yeah, I think that's just part of the core of Zephyr. That's kind of foundational to Zephyr is the idea of being platform agnostic and vendor neutral, and so it was really developed that way. 
  
And again, when you look at the traditional RTOS, this goes back to the discussion on FreeRTOS. Yeah, that is a portable kernel written in C, intended to run on many different architectures. You've got a porting layer for different architectures. But when you start getting into your UART drivers, your A to D drivers, GPIO, that's all going to be vendor-specific for the most part. As Julien mentioned, you may have middleware that might not be supported on FreeRTOS. You may have your own development environment, your own tools. 
So, like I said, I think the idea is that with Zephyr, this portability or flexibility, as you're saying, was just built in from the start. That was the intent—to have a portable software platform. And I would add, there was also a question that was answered in the chat, but that I found relevant to that topic, the debug capabilities and on that, if we compare the Zephyr offering and all the debugging tools that are integrated into Zephyr, I think there is also a lot of advantages from that point of view. 
For example, if you are a SystemView user, using SystemView and Zephyr on Silicon Labs hardware, first of all, you benefit from the license-free agreement we have for the SystemView software. And yeah, Zephyr supports natively SystemView, so that's one way to improve your embedded developer experience.  
 
I see quite a few questions on how VS Code ties into the entire workflow. Maybe if we can shed some light on that, because I see around four to five questions on that. Are we able to customize anything? Do we specifically need Simplicity Studio in the workflow, or is it something that we can handle over VS Code?  
Yeah. So maybe let me take one of those parts, which is, do we need Simplicity Studio? And the answer there is no. Again, as Johan mentioned earlier, our goal from the start with our Zephyr offering was to make this as familiar as possible to current Zephyr users. So, there's not a requirement to use Simplicity Studio. I think, in terms of VS Code integration, that's something we'd be working on. 
You're certainly welcome to use VS Code with Zephyr, but yeah, level of integration, ease of use for VS Code is something we will be looking to improve as we move forward with our Zephyr offering. Regarding VS Code integration, there's a whole bunch of generic plug-ins available for Zephyr. But since the question came up, I think it's good to mention, this is something that has been discussed within the technical steering committee of Zephyr. It came up in the recent face-to-face meeting that we had. 
  
And the idea is to put some effort into supporting some vendor-neutral plug-ins, and the main candidate there is the one from a company called AC6. So they have a plug-in called Workbench for Zephyr that you can install. So the project itself, in a vendor-neutral way, is aware of this desire in the community to have some better integration, and there's efforts in that direction. Yep. And as a last point to that answer on the, let's say, Silicon Labs or Simplicity Studio specific tools integration, that's also something we are looking at. 
  
There were some questions about our radio abstraction layer and how could it be leveraged through Zephyr. So that's something where there are some integration to do between our-- So if you are familiar with the Si SDK and Simplicity Studio, you are familiar with our radio configurator, and that's something that we're looking to better integrate within our Simplicity SDK for Zephyr. Got it.  
 
I see one interesting question before we move to more technical ones. What is the biggest misconception developers have about adopting Zephyr in production products? 
I think one that I've seen, or a question that comes up, is that, is it actually used anywhere? Maybe that question has disappeared now in recent years, but that's at least something that we saw over and over again. And with an open-source project, it's very hard to know where your software is ending up because we don't have any tracking of who's using it and for what purpose. Nowadays, you can actually find a pretty good, I would call it a summary, but a good set of examples of products using Zephyr on the Zephyr project website itself. 
I think there's maybe 100 or so products from many different categories showing what Zephyr can be used for. So that's one thing that comes to my mind, at least. There's one more question, probably the last one that we take today.  
 
Does Zephyr impact the power consumption compared to a bare metal approach? Are there any specific configurations that can enable it to have better power consumption?  
So I would say that's pretty specific depending on the semiconductor vendor. What I can say is that, so we did our first official release earlier this year with the Simplicity SDK for Zephyr, and that we are looking at improving our integration. 
And that improvements come both on the power consumption part by better integrating Zephyr onto our hardware platforms, but also in term of performances, by optimizing that integration, we are able to be closer to what optimized FreeRTOS or bare metal implementation would achieve. Okay, so that brings us to the end of the session. Thank you so much for joining us, Matt, Julia, and Johan, as well as all of our participants. Thank you so much for joining us today. You can please register for our Embedded World and REN Meetups, and I'll just pull up that slide real quick. 
  
So for anybody interested, you can scan the QR and get registered. Thank you so much for joining us today.