WEBVTT 00:00.000 --> 00:22.680 Okay, good morning everyone. Welcome to our talk on every level of us. Please let me know 00:22.680 --> 00:28.000 with the mic starts to set for if I'm not holding it. If you can't hear me anymore anyway. 00:28.000 --> 00:34.360 So this is Kaspar. He's giving the second part of the presentation. I'm Koon. I'll be doing 00:34.360 --> 00:43.160 the first part and warm maintainers of every LOS and part of a set of contributors. So 00:43.160 --> 00:49.640 every LOS is our operating system. It's a library operating system for secure memory 00:49.640 --> 00:54.480 safe, low power, internal things and it's written in rest. So some of those things you have 00:54.480 --> 01:01.400 seen from the previous start might be familiar. So in the start I'll be giving a bit of 01:01.400 --> 01:08.680 context showing a bit why we like rest and the embedded ecosystem. So what's every LOS actually 01:08.680 --> 01:14.480 is all about and then Kaspar goes into getting started with every LOS doing some hello 01:14.480 --> 01:19.760 world to networking and we'll wrap up. So first we're in the embedded 01:19.760 --> 01:27.840 that room. So we're doing microcontrollers, limited processing power, slow power, low 01:27.840 --> 01:34.720 memory and we have our single memory space. We don't have our MMO to do virtual memory. 01:34.720 --> 01:43.160 We might have an MPU to do some memory protection but that's about it. Sorry. So our 01:43.160 --> 01:51.400 firmware for bare metal, we don't have an OS that's what we have to provide here I guess. 01:51.400 --> 01:56.280 We need to do threading networking, heap allocations maybe if you need that but we need 01:56.280 --> 02:02.640 to do that manually because we don't get that. We don't like allocations. We like our 02:02.640 --> 02:08.920 deterministic behavior, avoid the panic related to being out of memory on our low memory 02:08.920 --> 02:18.160 systems and memory fragmentation becomes an issue. So we don't want allocations. That's 02:18.160 --> 02:26.040 why we get to rest and the ecosystem. And with rest we can go on about memory safety. I think 02:26.040 --> 02:30.320 you all know about memory safety and rest by now so I will not go into that. I'll go into 02:30.320 --> 02:36.120 other parts of rest and why we want rest. Because rest comes with a lot of other things. 02:36.120 --> 02:41.720 We get to create the shared code from Crate so you have a repository and it's well integrated 02:41.720 --> 02:47.480 into build system. One of the advantages we have here compared to for example C. The 02:47.480 --> 02:52.600 trades that we get interfaces so that we can actually have interoperability between the 02:52.600 --> 02:59.280 different grades. The no SDD feature that's in the language so that you can signal that 02:59.280 --> 03:05.880 you do not do allocations. You do not use the fancy types of the language. It keeps 03:05.880 --> 03:12.520 things simple and well suited for embedded. And there's the Async part that was already shown 03:12.520 --> 03:17.160 in the previous presentation a bit. I'll see you quite a lot more than we'll probably be 03:17.160 --> 03:23.520 talking about it. But it provides Async for the Async forness cooperative multitasking. So 03:23.520 --> 03:28.280 you can actually schedule multiple things on a single stack. Minimal memory overhead. 03:29.280 --> 03:33.200 But at least features together we also like about rest because this actually fosters 03:33.200 --> 03:37.280 a lot of collaboration between different projects. 03:41.280 --> 03:45.280 So what do we get in practice from this ecosystem? Because we had to language features just 03:45.280 --> 03:51.080 now. But what we get for example is the embedded help trades. They provide a set of generic 03:51.080 --> 03:56.280 interfaces that can be used like they can be implemented with peripherals and it provides 03:56.280 --> 04:03.280 like a common interface into those peripherals. So it all looks the same from the user. 04:03.280 --> 04:10.280 For example, driver craze. If you're embedded help trade for Asprety, you write it right 04:10.280 --> 04:16.280 for you just assume that there's an embedded tell implementation on the other side. 04:16.280 --> 04:21.280 And you can write your craze assuming that if you drive for separate from the actual operating 04:21.280 --> 04:28.280 system. And then there's the Async from the frameworks such as embassy. 04:28.280 --> 04:33.280 They implement these interactions that you need. And embassy implemented for the SGM for 04:33.280 --> 04:43.280 the two of the NFNPICO. I think by now a few more. And it provides us with a low memory 04:43.280 --> 04:50.280 async scheduler. So yeah, I can go on and all about this. But the message here is that the ecosystem 04:50.280 --> 04:59.280 of craze around embedded. It's growing and it's great. So you start writing your firmware. 04:59.280 --> 05:05.280 And then at some point you need to find a craze for your artifacts. You need to multitasking 05:05.280 --> 05:11.280 you want networking. And you have to figure out what's out there. And where do I get it? 05:11.280 --> 05:19.280 And maybe even you need something real time. You need actual intrapaste trading. 05:19.280 --> 05:23.280 And it's possible to do this. You can all gather it up and do that. But it's 05:23.280 --> 05:29.280 curating that integrating everything at time consuming. So that's where we get with 05:29.280 --> 05:34.280 a real mess. Because with a real mess, we decided we can integrate this for you. 05:34.280 --> 05:39.280 Make it easier. We have the embedded help rate. We picked the embassy. 05:39.280 --> 05:46.280 Execute our integrated multi-CP with embassy net. And integrate that for you so that you 05:46.280 --> 05:52.280 can use it. And don't have to look around what's out there. So with everything else, 05:52.280 --> 05:58.280 we essentially we started with a scheduler. Classic trading. It's a preemptive scheduler 05:58.280 --> 06:05.280 priority based separate stacks. Classic multi-treading. And we think the embassy executer 06:05.280 --> 06:11.280 put that on top of a thread. And yeah, that runs inside a thread. It's the 06:11.280 --> 06:15.280 kind of async scheduler that we've seen also from the previous presentation where you 06:15.280 --> 06:19.280 can do async programming. And in that way, we support both preemptive 06:19.280 --> 06:23.280 scheduling so that you can have your intrapaste or real time. But also that 06:23.280 --> 06:30.280 our memory asyncfulness scheduling. So that gives us already quite a bit of an 06:30.280 --> 06:38.280 operating system together with those grades. And we want to build on top of that. 06:38.280 --> 06:42.280 Also contribute back to the ecosystem, but also have high level 06:42.280 --> 06:46.280 affections. And one of those examples is what we have is a sensor 06:46.280 --> 06:51.280 abstraction. This means that you have your development board and 06:51.280 --> 06:56.280 their sensors on it. And we want to make it that you don't have to worry 06:56.280 --> 07:01.280 about the exact type of temperature sensor on it. It's just a temperature sensor. 07:01.280 --> 07:04.280 So what we did with the sensor abstraction is you can enumerate the 07:04.280 --> 07:09.280 available sensors on your board. Read out what is there in terms of 07:09.280 --> 07:14.280 sensors. And we provided generic interface into the sensors and 07:14.280 --> 07:18.280 measurements. So that you just can prep whatever sensors out there and 07:18.280 --> 07:23.280 it should work. On the other side, we want to have a way to easily 07:23.280 --> 07:27.280 describe what is on your board. Provide a machine-readable 07:27.280 --> 07:32.280 description of the board currently at YAMO. And this contains the 07:32.280 --> 07:36.280 information on the board, like the microcontroller that's out there, 07:36.280 --> 07:41.280 which peripherals are needed on that board. And the supported features of 07:41.280 --> 07:47.280 that board, does it support network interface. And yeah, this is 07:47.280 --> 07:51.280 done in an format that you can read and the machine can read and it's 07:51.280 --> 07:57.280 not rust code itself. So hopefully that makes things easier. 07:57.280 --> 08:03.280 Yeah, one thing we ran into was that cargo is great in terms of build 08:03.280 --> 08:09.280 system. But cargo will build, will try to build things for you. 08:09.280 --> 08:13.280 You can just enable the features. And if it conflicts, cargo at 08:13.280 --> 08:16.280 some point will tell you with a panic or an error message that 08:16.280 --> 08:20.280 it's conflicts. And one of the things we want to have is that we can 08:20.280 --> 08:24.280 tell you before we start to compile is this going to work on my 08:24.280 --> 08:28.280 board. Does my board support everything needed for this format to run 08:28.280 --> 08:33.280 or the other way around? If I want to run this example, which kind of 08:33.280 --> 08:37.280 boards can I use that are supported by aerial OS? 08:37.280 --> 08:42.280 So for that, we have our own build system that's wrapped around 08:42.280 --> 08:46.280 cargo. It's lace. It's a YAMO-based declarative built 08:46.280 --> 08:49.280 configuration. You can select a required module, 08:49.280 --> 08:53.280 for example. That's working for this one. It abstracts away the 08:53.280 --> 08:56.280 board specific things which features need to be enabled for 08:56.280 --> 09:00.280 specific board, which architectures this board. Lace handles that 09:00.280 --> 09:03.280 for you. You just say, I want this board. I want that working. 09:03.280 --> 09:07.280 And lace will stare at the cargo build system and try to build 09:07.280 --> 09:12.280 it for you. One other thing we did with lace is abstract away 09:12.280 --> 09:15.280 the specific flesh commands. So if you have your board, you just say, 09:15.280 --> 09:22.280 well, lace built flesh and it will flesh the board. And the thing is that 09:22.280 --> 09:28.280 with lace, if you do this normally on with cargo, you have to 09:28.280 --> 09:31.280 park up and talk to them all and you need to add all the specifics of 09:31.280 --> 09:37.280 your board. With lace, we can abstract that away. So I think it's 09:37.280 --> 09:41.280 time for your part. You can demo all these nice features for us. 09:41.280 --> 09:46.280 Thank you, good. So demo is not as sophisticated as the one from 09:46.280 --> 09:51.280 Alexis. I'm going to show you how to get started. Create a simple 09:51.280 --> 09:55.280 blanky with rust. Then attach a sensor. Show you how to add the 09:55.280 --> 09:59.280 ice-creams, and the center driver. Network it up to some TCP 09:59.280 --> 10:03.280 standing and then port it to another board because that is something 10:03.280 --> 10:08.280 we can easily do. All right. And this is how I did this demo on. 10:08.280 --> 10:10.280 It's not going to have 50 to decay, but it doesn't really 10:10.280 --> 10:15.280 matter, which what we're using. All right. So first step, get a basic 10:15.280 --> 10:19.280 blinking LED on this board. We need to create a project from the 10:19.280 --> 10:23.280 template. Define the LED pins and then toggle that in the loop. 10:23.280 --> 10:27.280 And you will see code. But this is also what you don't see. 10:27.280 --> 10:30.280 Right. So here you can see first step. We are also using cargo 10:30.280 --> 10:33.280 generator to generate our template. But you don't see here 10:34.280 --> 10:37.280 anything board specific. Right. With this, you generate the generic 10:37.280 --> 10:41.280 areas of application, consistency of those three files. 10:41.280 --> 10:47.280 We have a main or else cargo terminal with no board specific in 10:47.280 --> 10:50.280 here. And everything is really basic. If you remember from the 10:50.280 --> 10:54.280 talk before, well, it's just the info log. And then we can run 10:54.280 --> 10:57.280 this. Now, we're using Lase to run this. Here's the first time 10:57.280 --> 11:00.280 I specify the board, the Nordic board. This would run 11:00.280 --> 11:03.280 on all the board set area supports. And you would get this 11:03.280 --> 11:07.280 heli-word output. So now we have a basic template. And now we 11:07.280 --> 11:12.280 make a board specific. Because we define an LED pin. 11:12.280 --> 11:16.280 Legacy in line one, we can see we define like a 11:16.280 --> 11:20.280 LED pin. Line five, we get an output. And then 11:20.280 --> 11:24.280 7 to 10, a basic loop with a timer. If you want to use 11:24.280 --> 11:27.280 timer, we have to enable the timer feature on the areas 11:27.280 --> 11:32.280 grid. And with that, we have a blink. This is LED 11:32.280 --> 11:35.280 off, LED off. 11:48.280 --> 11:52.280 Next step, we want to add a specific temperature sensor. 11:52.280 --> 11:57.280 OK. Up next step, I'll add another unit for example. 11:57.280 --> 12:01.280 This has a setting. And so as well as A intensity 1 and 12:01.280 --> 12:05.280 with the бук C5. Same kind of check everyone health 12:05.280 --> 12:07.280 classes are a problem and an interpreter gives us one 12:07.280 --> 12:08.280 top speed minus movements. 12:08.280 --> 12:11.280 And we need to somehow get the highschool 12:11.280 --> 12:14.280 size plus pins, right. And visualize the driver and 12:14.280 --> 12:17.280 print the sensor data. So we don't want to write 12:17.280 --> 12:19.280 the driver, so we find something on the internet. Unfortunately, 12:19.280 --> 12:22.920 So here, if you remember this, no, it's not here. 12:22.920 --> 12:25.280 Line 7 has our LED defined. 12:25.280 --> 12:29.320 I now added here that we want to use to TWSPI0. 12:29.320 --> 12:31.160 I express the peripheral and the two pins 12:31.160 --> 12:36.000 we're using in line 89, pin 26 and 27. 12:36.000 --> 12:38.600 That's the board specific stuff. 12:38.600 --> 12:43.960 And with that in place, we initialize the I square C. 12:43.960 --> 12:47.680 Sensor here, like line 9, it's just like a contract constructor. 12:47.680 --> 12:49.120 We want to do a bit of configuration. 12:49.120 --> 12:50.320 Line 5 to 7. 12:50.320 --> 12:52.320 You can see it's something that we do in Arial. 12:52.320 --> 12:55.880 Like line 7, it's a constant function that figures out 12:55.880 --> 12:57.800 like a frequency from a range. 12:57.800 --> 13:00.800 Because you realize that these MCUs, they have like 13:00.800 --> 13:03.360 specific in a range like they don't, 13:03.360 --> 13:05.040 you can't do an arbitrary frequency. 13:05.040 --> 13:07.200 You have like a front, you can do a 100k. 13:07.200 --> 13:10.280 So usually, the exact frequency doesn't really matter. 13:10.280 --> 13:12.520 And if you want to purchase stuff across the board's 13:12.520 --> 13:13.600 arranged is fine. 13:13.600 --> 13:15.720 So this is what we're doing here. 13:15.720 --> 13:20.400 Arial knows which frequency it can do on the specific board 13:20.400 --> 13:23.440 we're compiling to for and then choose to like the highest 13:23.440 --> 13:24.680 of those. 13:24.680 --> 13:27.680 This is like one of our portability tricks. 13:27.680 --> 13:30.840 So with I express the initialized line 14, 13:30.840 --> 13:35.480 the initialized driver, one line, very nice. 13:35.480 --> 13:38.720 Line 18, we get the measurement, line 22. 13:38.720 --> 13:42.160 We print it using the logging and then we 13:42.160 --> 13:44.040 do loop again and do this. 13:44.040 --> 13:48.800 So if we execute this, I'm not as brave as a lexat 13:48.800 --> 13:49.840 onto demo life here. 13:49.840 --> 13:52.000 But this is the output you can see. 13:52.000 --> 13:54.200 It's was a bit colder in the office I built this demo. 13:54.200 --> 13:56.400 It's 19 degrees. 13:56.400 --> 13:57.560 Yeah. 13:57.560 --> 13:58.840 All right, let's move on. 13:58.840 --> 14:01.640 We want to network this up. 14:01.640 --> 14:05.240 So we need to do some TCP sent, integrate an domain loop, 14:05.240 --> 14:06.960 and then settle with the build system 14:06.960 --> 14:11.080 to enable the networking. 14:11.080 --> 14:12.760 Yeah, I was laughing when I saw a lexat slide 14:12.760 --> 14:14.640 because he also did some TCP sent. 14:14.640 --> 14:16.040 If you would have it side by side, 14:16.040 --> 14:18.720 it looks almost exactly the same, right? 14:18.720 --> 14:23.800 Even let the static IPv4 address hard coded in. 14:23.800 --> 14:25.240 Don't do that nowadays. 14:25.240 --> 14:29.160 What you don't see here is what he had to do. 14:29.160 --> 14:31.080 It's like a setting up of the network stack, 14:31.080 --> 14:34.760 whether the Wi-Fi and the connection everything. 14:34.760 --> 14:38.000 Because here for the array of metrics in the line 3, 14:38.000 --> 14:40.160 where you get a network stack, and actually 14:40.160 --> 14:42.600 the system and the build system know how to configure this. 14:42.600 --> 14:44.880 So for the board, we're using the NFTK, 14:44.880 --> 14:48.080 the build system shows the USB Ethernet networking, 14:48.080 --> 14:50.280 and sets everything up and the network task. 14:50.280 --> 14:52.000 So for this implementation, 14:52.000 --> 14:54.120 really we just take the network stack 14:54.120 --> 14:57.120 and do the TCP sendings. 14:57.120 --> 14:57.960 That is straightforward. 14:57.960 --> 15:00.200 Create a socket, connect, write everything, 15:00.200 --> 15:03.000 flush it, and be done with it. 15:03.000 --> 15:06.800 Yeah, and I worked around, I worked around the buffer 15:06.800 --> 15:09.320 lifetime issues by just having it look into the function. 15:09.320 --> 15:13.600 So this reconnects every time realises the buffer. 15:13.600 --> 15:17.160 So with that report with that function, 15:17.160 --> 15:18.160 back to our main loop. 15:18.160 --> 15:20.680 Now instead of printing to the logging, 15:20.680 --> 15:22.520 we printed to the buffer to string. 15:22.520 --> 15:24.120 Here I'm using a heapless string. 15:24.120 --> 15:27.880 It gets allocated here on the stack or in the future, 15:27.880 --> 15:30.080 but it's a pity bed. 15:30.080 --> 15:32.760 Anyhow, there's the buffer now, and we call our report 15:32.760 --> 15:34.240 function in line 6. 15:34.240 --> 15:36.640 And with that we send the stuff off. 15:36.640 --> 15:39.120 I have my favorite sophisticated server package 15:39.120 --> 15:40.040 on the other side. 15:40.040 --> 15:41.640 No, ah, first build system, sorry. 15:41.640 --> 15:42.480 Yeah. 15:42.480 --> 15:44.240 So now we first have to interact with LES. 15:44.240 --> 15:46.520 On the left side, you see we want to use TCP, 15:46.520 --> 15:50.120 and we added for the right, and for the string buffer, 15:50.120 --> 15:51.200 I use the embedded I always think, 15:51.200 --> 15:52.600 and heapless dependencies. 15:52.600 --> 15:56.840 That's ecosystem creates very nice to reuse. 15:56.840 --> 15:59.600 And here, first, we have to add this network select. 15:59.600 --> 16:03.440 This is not in cargo because LES needs to know 16:03.440 --> 16:05.520 if the board has network, and it does know 16:05.520 --> 16:07.080 which kind of network it is. 16:07.080 --> 16:11.640 That's why we have this extra configuration in LES. 16:11.640 --> 16:13.760 So now with the network select in place, 16:13.760 --> 16:15.600 this would not compile any more on boards 16:15.600 --> 16:18.720 where we don't know if there's a network interface. 16:18.720 --> 16:24.160 Anyhow, for set in place, we can get that data on. 16:24.160 --> 16:27.520 I omitted the whole host configuration of the USB 16:27.520 --> 16:30.080 Ethernet enriching a providing DHCP server to that, 16:30.080 --> 16:35.480 but you get to just like the node part is done with that. 16:36.000 --> 16:40.040 OK, so now what if I wanted to run this on a different hardware? 16:40.040 --> 16:43.160 Like, I'm going to put this to the rest part of Tico. 16:43.160 --> 16:44.800 The only thing that was actually board specific 16:44.800 --> 16:49.160 was where the pinouts and the choice of ice-craft C peripherals. 16:49.160 --> 16:52.600 So by changing those four lines, here I added like a whole new, 16:52.600 --> 16:56.280 using config, like, waspondition compilation. 16:56.280 --> 16:57.960 A whole new case for compilation. 16:57.960 --> 16:59.480 So it also works on the previous board, 16:59.480 --> 17:00.920 but if I wanted to put it to Tico, 17:00.920 --> 17:03.520 those as the four lines I would need to change. 17:03.520 --> 17:07.200 And with those four line changes, it works on this, 17:07.200 --> 17:08.320 actually I didn't follow through with it. 17:08.320 --> 17:10.040 It compiles and it probably runs. 17:10.040 --> 17:11.840 It didn't solder the fixed, right? 17:11.840 --> 17:13.960 But the idea here is four lines, 17:13.960 --> 17:17.520 and it runs on a completely different mic controller. 17:17.520 --> 17:22.080 And that's it for getting started. 17:22.080 --> 17:22.960 What are we doing next? 17:22.960 --> 17:24.520 We're about to release version three. 17:24.520 --> 17:26.120 The version O3. 17:26.120 --> 17:28.760 Oh, yes. 17:28.760 --> 17:31.040 We're like filling with a change box still. 17:31.040 --> 17:33.440 That adds integration of Bluetooth low energy. 17:33.440 --> 17:35.960 Using the troubled stack, we now have native board 17:35.960 --> 17:38.080 with networking, also coming in, I think, 17:38.080 --> 17:39.600 probably before the recess. 17:39.600 --> 17:43.440 And we have more Yamil to describe the actual boards, 17:43.440 --> 17:46.000 move stuff out of the rust code and into Yamil, 17:46.000 --> 17:49.440 because that's much easier to handle at scale. 17:49.440 --> 17:52.360 And after that, we're going to take the secure software updates 17:52.360 --> 17:53.600 and better power management. 17:56.880 --> 17:58.800 OK, so wrapping up, up. 17:58.800 --> 18:01.040 And what everything else does is like what you've seen 18:01.040 --> 18:04.480 for with the ESP stuff, we try to get all these little things 18:04.480 --> 18:07.400 that people have to care about to get started, 18:07.400 --> 18:08.880 do it one thread, right? 18:08.880 --> 18:11.160 So you can actually concentrate on the business logic. 18:11.160 --> 18:14.240 So we integrate the rim of the rust ecosystem 18:14.240 --> 18:16.720 and make it easily approachable. 18:16.720 --> 18:18.840 And we think that that makes a better rust really easy 18:18.840 --> 18:19.480 to get started. 18:23.120 --> 18:27.200 So now you're thinking, why did they use IPv4 in 2026? 18:29.040 --> 18:30.760 And hopefully, you're also thinking that this locks 18:30.760 --> 18:33.800 awesome, and you want to try it. 18:33.800 --> 18:34.800 Thank you. 18:34.800 --> 18:35.800 Thank you. 18:35.800 --> 18:44.600 APPLAUSE 18:44.600 --> 18:46.400 So if you have questions, we probably meet outside. 18:46.400 --> 18:48.000 Oh, we have questions, time for questions. 18:48.000 --> 18:50.200 We have time, OK. 18:50.200 --> 18:51.200 Seven minutes. 18:51.200 --> 18:52.800 Wow. 18:52.800 --> 18:54.600 You have to answer the question you have to mind. 18:54.600 --> 18:56.200 OK, I can do it like this. 18:56.200 --> 18:58.760 OK, that's good. 18:59.560 --> 19:03.160 OK, thank you for your call. 19:03.160 --> 19:06.920 And now the question, here is 2026. 19:06.920 --> 19:09.600 Next year, CRA will take effect. 19:09.600 --> 19:12.640 Next year, the CRA cybersecurity resilience 19:12.640 --> 19:14.280 will take effect. 19:14.280 --> 19:17.880 And it requires that you should ship your software 19:17.880 --> 19:21.520 in secure configuration by default. 19:21.520 --> 19:27.000 And my question is, all of the hardware you support, 19:27.000 --> 19:29.320 actually supports MPU. 19:29.320 --> 19:30.680 Why are you not using it? 19:34.960 --> 19:38.360 Yeah, so there's two things. 19:38.360 --> 19:40.920 Why is the architecture not split in the OS 19:40.920 --> 19:44.000 and the application like talk to us? 19:44.000 --> 19:46.560 That would be one way to use the MPU 19:46.560 --> 19:48.120 have like a hard separation between it. 19:48.120 --> 19:49.560 Because this is a library. 19:49.560 --> 19:51.680 So the application gets compliant. 19:51.680 --> 19:53.360 And the network stack and everything 19:53.360 --> 19:54.760 is just a building block of one application. 19:54.760 --> 19:56.560 It's one application, one address space. 19:56.560 --> 19:57.720 This is how it works, right? 19:57.720 --> 19:58.760 It's like one application. 19:58.760 --> 20:02.000 What we don't do is we split the OS and the application 20:02.000 --> 20:06.720 because we like this architecture. 20:06.720 --> 20:09.160 We'll do that before. 20:09.160 --> 20:12.240 Like for example, talk to us, and... 20:12.240 --> 20:14.680 OK, you like it. 20:14.680 --> 20:21.600 And how will your security assessment look like 20:21.600 --> 20:24.000 that you will defend this, that it is secure? 20:24.000 --> 20:26.440 Because you target IoT specifically. 20:26.440 --> 20:27.480 So it's networked. 20:27.480 --> 20:32.560 It will potentially transfer some critical sensitive 20:32.560 --> 20:35.560 information. 20:35.560 --> 20:37.440 Do you believe it is secure? 20:37.440 --> 20:40.360 Actually. 20:40.360 --> 20:41.720 Should we talk about this outside? 20:41.720 --> 20:45.920 Yeah, because it's very wide, right? 20:45.920 --> 20:46.520 By good question. 20:52.840 --> 20:54.560 We need to really question what's coming, right? 20:54.560 --> 20:56.400 Yeah, yeah. 20:57.360 --> 21:00.880 Do you plan to support DVI-3 at some point? 21:00.880 --> 21:02.080 Sorry, I think you get it. 21:02.080 --> 21:03.440 Could you repeat that? 21:03.440 --> 21:06.880 Do you have any plans for DVI-3 support for desk 21:06.880 --> 21:07.440 or something? 21:07.440 --> 21:09.080 Yeah, we're not doing DVI-3. 21:09.080 --> 21:12.560 DVI-3 mixes like policy and configuration and stuff. 21:12.560 --> 21:14.760 What we're going to do is just parse the DVI-3 21:14.760 --> 21:17.800 of ZFIA out using LLMs and convert it to our format, 21:17.800 --> 21:20.800 which we think is better. 21:20.800 --> 21:22.080 No, DVI-3. 21:22.080 --> 21:24.280 Because DVI-3, I mean, it's great on Linux 21:24.280 --> 21:26.080 because it does runtime configuration, 21:26.080 --> 21:28.680 which we don't need, for example, ZFIA doesn't use. 21:28.680 --> 21:31.840 And if you don't use the runtime configuration 21:31.840 --> 21:34.520 at the option of compiling to something 21:34.520 --> 21:36.720 readable at runtime, device-3 itself 21:36.720 --> 21:38.720 is not a great description format, right? 21:38.720 --> 21:40.520 So we don't want to use this data format. 21:40.520 --> 21:42.760 But these days, we actually try it nowadays. 21:42.760 --> 21:44.920 It doesn't really matter what format the machine 21:44.920 --> 21:46.960 readable stuff is in, right? 21:46.960 --> 21:49.280 So seriously, we're like, yes, like our own stuff, 21:49.280 --> 21:50.880 which is called the structured board description, 21:50.880 --> 21:52.680 which is super simple, Yamil saying which LED 21:52.680 --> 21:54.080 which color which pin. 21:54.080 --> 21:57.360 And we can easily pull that out of the ZFIA device piece 21:57.360 --> 21:59.280 or generate it from the data sheets using LLMs. 21:59.280 --> 22:01.920 So the actual device cannot does a method this days. 22:11.720 --> 22:12.720 Any other question? 22:12.720 --> 22:13.720 There's one question. 22:13.720 --> 22:15.520 Oh, sorry, we're going to do this. 22:15.520 --> 22:24.760 Do you implement any memory protection? 22:24.760 --> 22:27.800 I'll say a bunch of runs on size codes, 22:27.800 --> 22:28.920 a new dialog wrong. 22:28.920 --> 22:31.400 Can you do implement that for tasks 22:31.400 --> 22:34.040 or any sort of task restarting for Panics 22:34.040 --> 22:35.680 or anything like that? 22:35.680 --> 22:37.040 Yeah, similar question to this. 22:37.040 --> 22:40.840 So what we do is we have it in a branch. 22:40.840 --> 22:42.960 We actually using the MPU to protect our stacks 22:42.960 --> 22:43.960 because we have multiple stacks. 22:43.960 --> 22:47.200 So we use, we have that zone for that declaration, 22:47.200 --> 22:48.120 but it's a library. 22:48.120 --> 22:49.720 So it's not different process. 22:49.720 --> 22:51.640 This is all one rust thing. 22:51.640 --> 22:55.320 So we cannot easily have a threat in a different memory space 22:55.320 --> 22:57.600 or differently protected that just work. 22:57.600 --> 23:00.360 What we could do is have like a separately compiled thing 23:00.360 --> 23:02.040 and just a completely different architecture. 23:02.040 --> 23:04.080 Talk to us that we don't do this. 23:04.080 --> 23:05.160 Just a different architecture. 23:05.160 --> 23:18.160 Do you support matter, threat, zig-be, or only. 23:18.160 --> 23:20.760 It's integrated yet. 23:20.760 --> 23:22.920 We make our espaciously embassy. 23:22.920 --> 23:26.120 So the APIs embassy, I'm pretty sure that the RS 23:26.120 --> 23:28.920 met a embassy example would run basically unmodified 23:28.920 --> 23:30.160 on our unreal. 23:30.160 --> 23:31.520 And we have it in a roadmap to just 23:31.520 --> 23:33.360 integrate and make an example out of this. 23:33.360 --> 23:36.080 So in theory, yes, of course, but it's not integrated 23:36.080 --> 23:36.960 as well as it could be. 23:47.120 --> 23:49.960 Do more questions. 23:49.960 --> 23:51.360 OK, thank you. 23:51.360 --> 23:52.000 Thank you.