 Hello, nice to meet you. Thanks for joining our today's session. My name is Carl Gaua. I'm an engineering manager from on micro and today with Anders who would talk a bit about enabling new, I mean enabling KFR family in Zephyr. I mean the story of adding the whole support But first we start with Anders explaining why we actually doing that Okay, so my name is Anders Persson. I'm the director of mass market in Silicon Labs And I manage community training partnerships, but above all that also the tools ecosystem Which is the most fun part to be honest Is it anyone in here that doesn't know Silicon Labs? You okay, so we're doing wireless ship set. So if you didn't know that that's good to know So yeah, we are pretty new with Zephyr and we are taking baby steps I was looking at presentation from ST and I saw that they had 130 supported devices 130 supported boards we have to right now. So we are in the very start So yeah, we Can it be interpreted that we are behind and I always wanted to give you a little bit of the backstory on R tosses from Silicon Labs So this is not the main theme for today, but we we Heavily support free R toss and the meek room always and for you who didn't know that we purchased the meek room always some time ago and And We integrated it into our stacks, etc We had the choice to go for either free R toss or the meek room But the decision was made to we need to own because it's going to be such a critical part of our development So we need to make sure that we own the IP Was it the right thing or wrong thing I let you judge that At that time Zephyr was not even on the map. So what we did we integrated these R tosses into our tools because if you're going to develop with one of our chips today You practically need to have our tools which called simplicity studio five and in there when you are in you have a very easy way to integrate our toss into a bare metal Bare metal project, etc. We have a lot of examples and now when we also having our Wi-Fi chip sets. We are also integrating a lot of the AWS functionality into that so That's where we come from And that's where we started our journey for Sephir So we joined the Sephir project in 2021, but we started talking about Sephir long long time ago and in the early days it was Well, it's always requested from the customers, but you can imagine yourself that We have stack development teams in the company doing Billy SIG B Matter open Fred you name it and they're very proud of what they're doing and we from marketing came and said Hey, can we run someone else's Billy stack on our chip? I was thrown out of the room So but we we pushed and pushed and we got to the point where we started to Get a lot of pressure from our customers that this is the right thing to do. So we wanted to Start our journey and we had in our development teams. We had a Port here a port there and we tried to get it consolidated into one and Then we went to the separate project and we submitted it and they laughed a little bit said no this quality shit Sorry guys redo it That was a little bit of a humbling moment for for our development teams But to be fair to them, they are not experts on our tosses in their professional life. They're doing stacks so I've been working with that micro for a very long time and I said why are we gonna do this? This is not our core business. Let an expert do it And let's do it externally So we got in contact with that micro after we joined as a silver member and We'll let them start the development of Sefer and I think how long did it take before you committed the first one three months? I Think yeah, yeah three months done boom So our guys were very impressed and that's why we are working with a partner for doing the separate stuff So we have our first packages available right now All is built on the EFR for the two family series two Which is the mainstream devices today and on the platform that we are developing It's all based around Cortex M for the free And it's a it's a portal course in Sefer together with all the peripherals and we are using the Sefer Belly stack in all implementation. So we use in the hi layer to use that one Our target is to support all the peripherals so making a full-flown Implementation of Sefer on these ones Right now it's per board. It's not per family So it's really the board that we are supporting and there are a lot of explanations to that I let smarter people than myself talk about these explanations because Yeah, so the ones we're supporting right now. It's the bg-22 Thunderboard the XG-24 Development kit that's a little bit more expensive, but it also has a lot more Sensors, etc on there, but it's pretty simple to move to another explorer kit or your own design, etc And the latest one that we just released is called the bg-27 It's the bigger brother of the bg-22 That I'll leave over to you. Thanks Okay, so maybe let's start with some Background why we're here and what we do in in Zephyr. So We've been with the project for quite some time. We are platinum member of Zephyr project Like commercially we provide support for for Zephyr and generally speaking Doing things like you know enabling new platforms, but also things around it and and Providing software providing services for that. We also maintain risk five part of Zephyr So if you're contributing something there, it probably goes through us and We may be those guys who comments on your poor request and asking you to do things. Sorry for that Besides work on a core Zephyr itself. We also work In the ecosystem around that around Zephyr and around open source software and one of the two of those examples of of that work is Zephyr dashboard This presentation is basically uploaded to to the schedule so we can download it and click those links so that Zephyr dashboard is a place where you can go where we present results of our like huge CI building every single platform in Zephyr bunch six of examples there and trying to run it in in Renote our open source simulator to get Information if the binary actually works and then if it gives the results Renault Opedia is something above it It collects the data about existing hardware existing platforms and allows you to easily Browse through it and and see if there is a platform that you would need to you'd like to use if it's supported how it is supported and and so on so on so As Anders said within this project we worked on Extending Zephyr and adding Silicon labs platforms to Zephyr. So how do you do that? There is quite like an obvious and generic steps That you should follow basically can just read more or less about it in the documentation or like our you know in books But basically you have to figure out where to add this board So you have to figure out how to make it as generic as possible So we don't copy the code you don't you know have like our two targets doing exactly the same thing or Copying like startup code and things like that Zephyr often uses something called hardware abstraction layers. This is like Often separate repository with some low-level drivers from the vendor so if you are adding a new functionality you often have to take care of this low-level stuff and update it and If you update it you may break something in existing codebase. So then again testing And besides adding your platform, you have to fix the old ones because you broke it and of course update documentation and Possibly enable people to program to flash the device because Zephyr comes with a lot pretty handy tool called West and if you want to flash a device you just call West flash and it's supposed to just load the program But if your new device needs some Programmer that is not in supported you have to add it. So that's the theory looks pretty pretty Okay so when we started Working on this project this particular project as under said there was already work in progress poor request with some codes adding the functionality, but the code required some care So basically we had to Go through it figure out like what's there first of all Updated to follow the standards Zephyr standard like holding guidelines and then so on second of all divided into smaller chunks because it was like a huge poor request adding All the things at once take care of licensing so we'll talk about it in a moment and since the poor request Where it was open Before we actually started It kind of deprecated in a few places like API's internal API's after API's got bumped So of course that the poor request the working progress poor request didn't follow so if you want to see how it looked like we extracted from the big Tank of code as more one the link there actually points you to the initial poor request the first one that that was adding the very very core stuff For the first board we we start with that was the effort BG effort 32 BG 22 SoC and the Thunderbolt board so This is a typical Initial poor request to be honest like it adds pin control driver because it can I need it It adds some timers and so on configuration for the boards It adds you are driver because you know at least you would like to have a hello world working with with the first poor request that that kind of That's kind of useful if you if you have the board and So we did that and we follow like a standard procedure of like You know review update the review updates Update the the code that reviewers pointed out fix the issues push rebase and so on and so on and Eventually it got merged So we could proceed with with the rest of the stuff, but before I jump into rest of the stuff I wanted to tell a few things what happened there and and what else you we had to Take care of and then figure out so since that wasn't Like just hope this work. It was a you know work for a ceiling and devices Silicon labs To add new devices We had to take care about few things so once we landed the first first stuff people started using it and people who started using it were already ceiling labs Customers, but also new people that just you know Found the code and said, oh, yeah, awesome finally I can use Zephyr with this board. So let's do it and of course those people started to have a Bunch of requests what should be added how it should be added or maybe How things should be tweaked or hacked so it works better with with their code but at the same time we had to fulfill the contract and and the agreement with silicon labs and basically Work according to the plan and basically plan for the next boards the next families and the next The next chips in this family, so we couldn't really you know Listen to every single request and just immediately implement it But rather carefully explain, you know, what's where why it's like that And and so on so on so That that required some some some additional work here The other thing we had to take care of I mentioned that before is licensing. So as I said many Vendors many many Coatings many platforms in Zephyr from many vendors uses something that is called hardware abstraction layer. So this is typically code base that is delivered from some kind of a software development kits from the vendors so it is either extracted or published somewhere on On github and then imported to Zephyr project. So main Zephyr actually Uses that links against and builds it and links against it so once If it is used only with proprietary Software from the vendor or some Bermuda software from the vendor The licensing can be custom can be proprietary because typically you have to accept the proprietary license to use the rest of the But if you want to use it with Zephyr, you cannot really have a proprietary license there because the whole Zephyr project has its own permissive License and the rules in Zephyr say that you cannot really Merge into Zephyr anything that is not on OCI approved License so Here in how when we carefully analyze it. So we figure out that some of the files there that we need to use are on Silicon Labs Eula so when user license agreement So we had to basically do the audit there go through all the files figure out what's where what is needed and then of course Run it through legal teams Realizes that and then three C. It wasn't really hard per se To figure out what is where and what is wrong But really really really necessary and really important in the end because if you build product on a Code that is on the wrong license You may have problems in future. Yeah, so so that was a really important step But getting back to the technical work If you start working on a new platform You Have this first step where you basically add some first code. Yes, so so to run it So at some point you get it compiled you get all the configuration in place You you get a binary you load it to our board and nothing happens So what now of course you can grab some the buggers if you have one Like hardware the bugger connect it to the board run gdb and just figure out What the hell is happening there? But fortunately that's not only a way you can use simulation and actually we have a open source simulation framework called re-node You might have heard of it. If not You can visit our booth or talk with us who can show you So basically that one at the point where we are we were working with with this board was actually supporting EFR32 family so we could use it to run The code and within simulation is super easy to figure out like It doesn't work because for some reason stack pointer is allocated outside writable memory for example, yeah, or things like that or like a Linker script put something in wrong places or you know interrupts are Registering correctly and think all those things so basically with With simulation super easy to to figure that out and there is one Thing that you have a for free in the end once you run everything in in simulation Actually re-node is used as a part of Zephyr test system. You can Contribute your tests so when you start working on additional features you Automatically have regression tests for for for the base stuff and if you want to try it out It's super easy. Basically you copy those two Comments and with the internet here if you use in Wi-Fi here It takes around two minutes to download everything and you get EFR32 EFR32 BG22 Simulating Zephyr console sample Running on your machine. Basically, this is the binary Exactly the same binary as you could if you have the board you can upload it to the board you will get the same result so Feel free to try You can as I said before you can download the PDF PDF from of this presentation Just copy those two lines if you have Linux this will work with Linux Only I haven't tried to be honest with with any other system Okay So I mentioned before that besides Zephyr itself the core work in Zephyr We also built and maintain like environment around and one of these Projects around is a it's we know dashboard. So since we had already Simulation ready like simulation platform simulation framework that supports the board So once we added the board the you know support for the board it immediately popped up in In renew sorry in dashboard. So if you follow the link there, you can simply see like the whole page for EFR32 BG22 and you know with all the tests there with traces for those tests with Binary is that you can download and run with you are outputs recorded and so on so on so pretty cool And that kind of was for free because you know We already had the rest once we contributed Zephyr support it popped up and Since we if you if you attended the Keynotes yesterday and Michael's presentation Michael showed one of the projects we also work on this is like our hardware Visualizations visualization stuff and since we were working with with silicon labs Boards we thought like why not grab their Files and run it through the flow We'll see what happens and that won't happen. This is a visualization of the board Like automated automatically generated from from From the Gerber files using the flow that we use For generating our open hardware portal with components like 3d components that are free available like open source Available you can you can download them that was just a side task, but it's pretty cool I mean you can use it either for like the generating documentation automatically for example in Zephyr, but also for Generating some marketing materials like you know animations of those boards and so on so on but that's enough topic like Pretty cool. I mean, it's actually nice. I just want to brag with it. So getting back to To the main topic Once we had the base support we could start on Adding the rest adding the rest of the of the functionality and there is a lot of other stuff to be added like you know drivers for peripherals for radios and so on so on so again you cannot really get like one PR adding The base stuff and the second one I think the rest because the first comment you get please split it and it will get from many many Many many maintainers because if you suddenly open a PR to many subsystems GitHub will automatically ping maintainers of every single subsystem and they would tell you oh come on please split it so You have to You have to you have to do it like one by one It's kind of overhead but but you know, that's the only way to go and the only way that is actually Maintainable in the end. Of course with adding some New drivers you may need to add something to the hardware abstraction layer and every time you merge one You may need to rebase the others because they may cross be cross-dependent. So That's the theory how it works in practice If you want to take a look. This is the example of the flow for we did for bg-22 so, you know a bunch of PRs adding the drivers or Extending the support one by one you will see there like rebases comments and stuff like that. So we can just follow The links and see how it works. It's not that we had to write all the drivers Some of them were already there. We just may need to need it to tweak them enable them sometimes, you know add new pinmox IEP I and and stuff like that, so You can you can simply follow those those links and and get them with so many Poor requests sometimes cross-dependent You can be hit with Zephyr Recycle's So Zephyr follows pretty well defined Recycle if you want to know more about it You can check the documentation. You can also click this link here and see the dates of the next releases one was Unreleased was like week ago or two weeks ago something like that so Releases are not Problem per se in in merging things unless you want to have your specific piece of code in certain release The problem here is that every release Is preceded by something called feature freeze where no new features are merged. So only poor request fixing stuff or you know improving the stabilization or Coverage test covers and stuff like that, but no no new features And you know adding new platform is a new feature. So you won't be able to land that And but if you have a timeline you need to feed in because you know your customers Require certain certain features at certain point of time you have to plan for that It is well documented. So you just know the schedule and know what went to start Also attending the meetings especially TSC meetings effort is see meeting. There's a public meeting is Helps you to actually get up to date with with what's happening and where to start Okay, I wanted to talk specifically about Wireless support here because wireless support was actually one of the biggest thing Things here the rest is a microcontroller with certain peripherals that are needed there You need to have you know ice-cold see to have spy and then you are you know interrupt control and stuff like that but The cool thing about the year for 32 Family is Is that it's super low power? I would talk about power management in a moment and it has a radio and the radio provides absitude to you know to To basically, you know connect wirelessly to two to two other devices So this one supports be easy be threat and some proprietary protocols But here in this project be a It's a bit of low energy was the highest priority Zephyr order it has open source be a least which is pretty cool and others actually mentioned about it, but many vendors including silicon labs have their own They own stocks they own radio drivers things like that and those are typically Provided as a binary blob. So we don't have the code. You just have a binary blobs. There is a way to lend it I will tell you about it in a moment in Zephyr But we wanted to like Lend us Minimal amount of binary code in Zephyr as possible. So since there is a open-source Billy stack We just needed the low-level stuff. So we did like some some research how we can lend only this and figure out that we Yeah, we can lend only the library for a low level for five stuff and just use open source Billy stack and if you want to Lend add additional binary to Binary blob to Zephyr. There is a path for that. It's well-documented So you can read read Fruit in the documentation. So basically you need to Open on an issue open a PR Pointing to that explaining, you know, what's the binary? Where is the binary? What's the license? What it does? Escalate it to TSC. So Do the voting and then you can lend it Later once the binary is there updating it is way easier. You just update it But adding new one at this point looks like that and once you have it You can You know, let everything and then the support is complete You have You have all the plot the whole the plot the whole platform there in place So once we did it Silicon labs could tell the customers like everything is there. Just try to use Zephyr right now. Yeah, you can grab Zephyr You will have the whole functionality there in place and that's true. So people who typically earlier used some of the Customers they were Explicitly asking for Zephyr. So they were convinced yet. They wanted to use Zephyr, but some of them not some of them were using Bare metal for the whole life. So You know, it starts hearing typical questions of how does Operating system like way complex more more complex operating system like Zephyr compared to my simple bermeter application. Yeah, so Typically questions about code size Portability and power efficiency. So in terms of code size It's really hard to compare. I mean Zephyr is highly configurable. It's not that easy to actually Do Apple to Apple comparison between Zephyr and bare metal. Yeah, especially if you're using Binary Blocks, I mean binary blocks are basically grabbed and linked. So you cannot do much about it Within Zephyr, but it also cannot do much about it in in bare metal. So basically you get what it is and then link with what it is there So code size is tricky when it comes to portability Zephyr is super portable I mean you can even build it for to run on your local machine like a native x86 Linux PC and Test your algorithm. So, you know, Zephyr wins like on every single front here, but power efficiency is something that Is the hard question. Yeah, is Zephyr's power management as Good as my super handcrafted Bermeter power management and especially, you know, when we when we talk about those BG EF-32 second serious chips They are known for being super power effective. Yes, so so super low power and and and so on so That's a very very Valid question. So We started looking into that and then so, you know, preparing answers for for people who ask that so Contrary to your bare metal Implementation Zephyr power management flow is kind of generic. I mean the same flow applies to every single Every single border every single target there. Yeah, so it works in a way that The scheduler checks if there is something to be something to happen And if it's not we just go to the deepest sleep state as we can Yes, so so we just try to save as much energy as As we can and Certain pieces of code set of drivers or set of certain subsistence can mark Contel the power management code that Please, you know, do not go into deep sleep while I am transmitting for example. Yes So the lowest possible mode right now is just you know, like I link nothing else. Yeah, you cannot go to sleep Yeah, you cannot like Disable CPU for example. Yes. So This is how how it is how it works in the end. Of course it has to have like a custom implementation for for certain family or certain So sees or like even Single chip So there is a place to implement your custom code if you have something more sophisticated This is the place or you can simply you know call like I you know Turn off everything turn off clocks and then to wait for interrupt Okay, so we started looking into that and the first test was like a super tragic We run Bermuda application was drawing something around with Bluetooth beacon Example so Bermuda was drawing something around 100 microns and Zephyr was drawing like 20 times more So that was super tragic, of course it wasn't Exactly Apple to Apple comparison. I mean we were running beacon here and there but with different stacks and so on but still 20 times differences like Not acceptable So the first issue was kind of obvious the default configuration was really even enabling power management. So With in Zephyr, we were just running full steam ahead That explains a lot So we enabled power management config in the default configuration for the board and we dropped down to around 170 microamps, which is Way better, but still twice as much as As as the Bermuda application so that's Figuring out that took a bit more time than figuring out that okay, we didn't even enable power management in the original in the original Configuration it turned out that The Bermuda Implementation actually does something that we called Partial wake up so it can go to a very deep sleep, but then wake up to like a Power level or energy level to instead of you know, enabling the whole CPU and so on Do like a checks on the radio and if there is something to to process Wake up the rest. Yeah, so We ported that to to power management to Zephyr's power management and get the same results Like, you know the differences was The differences were like single microamps. So, you know, probably, you know test equipment errors so There is some more work plant and some next steps plant. I think under who told more about it What are we doing next we have just started as I said We got our first two ports out I've been very excited of what we have heard here at the conference I think cloud is given to be added to our implementation For some reason someone asked me yesterday. Where's the wise and implementation in suffer and Last night the guy for wise and said why aren't we doing a wise and implementation in suffer? So I guess we have the hands raised to do it and Matter I see as a given it goes along with The open source concept. So that is an easy one Well, sorry, I said easy one. I'm a I'm a marketing guy. It's easy for me But someone else gonna do it as you know, but I think that's a pretty given one as well our Wi-Fi SOCs needs to run And suffer as well and that's the port we're working on right now And of course we need to do more boards and all our devices seen there So that's a little bit of a bigger job than it sounds It's not just not to add boards because that's a repetitive way of doing it We need to get our database that describes all the SOCs and boards Implemented so that we can generate all boards all target devices, etc So I think with that and right now we are working with ant micro on this We will continue working with ant micro on this. I do foresee that we internally will get more Resources added to help ant micro to get all this done But I do not foresee that we are going to take it over and run all of the porting, etc Ourself, so this is a tool for us And our expertise is more on on creating stacks and other things so So I think with that we can close the presentation and start seeing if there are any questions Yeah, there is first one there So Why why can't we program the the radio directly through registers? Why why do we have to go through a blob because you're not the only one doing this? ST is doing this and you know if I we are doing our own IOT protocol Directly on to FSK on those two four and eight six eight and it's just annoying I Share your annoyance. I have spent two years trying to get the Ray library open-sourced I'd be super honest with you guys and We when we did our transceiver is the SI 44 60 series These have I think it's 200 registers that you need to get some kind of track of to be able to Get them to do what you want and that's pretty simple in this new radio We are getting closer to 2000 registers 32 bit The radio is original designed for 802 15.4, so pretty slow data traffic And you know in 802 15.4. I send something maybe I get a reply you reply tomorrow Billy is a little bit more strict. So there is a lot of code in the Ray library that are Making sure that we reaching the timer requirements of Billy and then there is a lot of other funny things that engineers like to do and They don't want to document it of course, so They Let's say that it's a question of investment. Do we want to open this then we need to start? Document it and that's going to take some time on the other hand We also see that now we're talking about series 2 series 3 will be totally different It will not have a ray layer at all So that the radio will run on its own core Totally separated and you will have your application core like in the Wi-Fi chipset We're doing now so the question is worth doing that investment Me personally think so because we are still foreseeing At least another five six years where series 2 is the high runner that People will design with and then we see another five years where anyone designed with that the family of devices continue doing their designs, so Yes, I I hear you I will forward it. I will use it as an ammunition internally, but I Let me say that I fighting big powers here I think you have time for one more question one more make make a good one now That I would didn't say that was a bad one Along the same lines So I did a little bit of work with the Zephyr Bluetooth stack, and I know that there's the HCI layer, but then there's also the split level split low level stack When you refer to Zephyr's BLE stack or you're referring to the split low level stack or to the HCI layer To HCI Yeah, yeah, just that's the interface we're using for for doing the BLE and So that's a big discussion you have about the BLE because if you're using our BLE stack you will have a lot of other functionalities like AOX HADM and all these things, but We have we might integrate our stack into Zephyr later on if there is a need for it But where we wanted to start was to use as much as possible of the Zephyr project because otherwise it doesn't make Really sense So since we're out of time I will be up in the end micro booth If there is anyone that wants to fight over a few of the kits that we have it is the XG24 up there Because I know you all want to test our solution right now They are up in the booth if you have more questions Let's meet in the booth and talk about it and thank you very much for Attending our presentation. Thank you. Thank you