 First of all, I'm very glad to be a speaker. But as we say in France, we hardly are saying one new French speaker will not come away from French speaking, and we lie. So I am a middle-aged developer, a writer and teacher, and I work for a company in Paris, which supports my DCS, and I wrote some books. And the last one is... This one in French. A quick story for your tour. It's quite an old project, started as an open embedded with open service. Because this book was not starting up at this time, it's much better made. And it varies on the recipient. The recipient is auto-pros-compiled, it's for target... Why? And there is a tour named with made, which is kind of g-made, much better than g-made, but it's quite extensive. As well as open embedded recipient, and it was inspired by the portage from Zhentun, and with any Python. And the real-to-project itself started in... in 2010, by Zhentun, with open embedded, including lots and lots of projects from the... including open embedded, it made 4 key references that is true. GXC and the real-to-to-documentation flashed out the page before. Before your tour, there was no documentation. The documentation for open embedded was... everywhere there was a computer to be done. So, well, there was a very nice book with 4 and 3 pages, and lots of books around the project, so... It's quite complicated to use, but you can find all the variables in the documentation. It's not like Android, because Android is quite complicated to modify and write to have no documentation, except some books from before, but quite nothing from Google. So, there is an excerpt of the documentation with the real-to-documentation, so when you get your help, you get these two variables, and you can add any variable you want, and you can add a variable for your own application or extensions. For example, we talked about Xenobite, which needs a layer, a specific layer because it's quite complicated if people bear with the original preemptive. So, some technical principles, based on the recipe, you can extend the recipe, we'll talk about it in the next presentation. You can use classes, you have configuration files to use files, everything should be in the meta, in the layer, actually, and there is a very few numbers of the midnight targets, that was not the case, so it was a real problem. And with Yokto, you have only two new targets. We have one graph, one in DC-Border, generally it's 96 and an end-prooter. I didn't know the end-prooter. And if you want to add a new platform as a Raspberry Pi, you need to add a meta-spec, meta-layer. So, if you want to provide Yokto for the P3, for example, you get the voting submission, actually it's your food, it's going to be on this graph, you can get the meta-spec-ride failure, but we have to give you a tree. So, if you add a meta-spec-ride failure, you define the machine, and then you build a C4 image, which is called much a micro, and you create a micro-spec, and so you have your program on board. It's quite simple. Now, if you want to use your time, it's much more complicated, because actually there is no official support for P3R30 in Yokto, but it's quite difficult to use, and I don't know if it's really useful, but you will see why. So, there's a lot of talks about your use and your time, I suppose. So, there are two ways, the P3R30 project, which is a single kernel patch, very easy to install. And Xenomai, which is a co-carnal approach with the cobalt, and it's a kernel patch, which is for high-py, and so on, like we do, etc. And for Xenomai, there is a user-space part, and for P3R30, you can use the standard user-space part. It's a big difference. With the new Xenomai 3, you can work on top of P3R30, installed naturally, but I think it's from the specific version from Nex, which I was more of a Xenomai solo, and now it's collaboratively in the main language of Xenomai, but most of people are used to it, because it's much more efficient. So, P3R30, do you share with Xenomai much? P3R30, I was a fork for our Xenomai mix, 3, when it was 3, now it's 10, when it was 3, it's okay. By part of the Xenomai, it's a fork of P3R30, by Fiji Jérôme, who is a French developer, a very famous French developer at the ecosystem. So, the 2nd Gardner is more complex to you, but it is much more efficient. At least it's about subtext, it's more efficient, you can do more on it, depending on the configuration or the touch. But it's difficult to use because the hardware support can be a little bit tricky to set up. There is a specific Gardner interface for the driver, which is called RTDM, because it's a specific Gardner, it looks like a Linux driver, but if you have a Linux driver, it was a Linux driver to RTDM. And there is... its application design could be some difficult because of the regression program. Actually, on Xenomai, there are two domains, two domains, one for Linux, and one for Xenomai, for the real-time. And if you call some system calls from Xenomai, Linux system calls from Xenomai, you will lose the real-time capabilities for the real-time problem. And if you have a big program, it could be very tricky to do. So, RT and the systems. The octo and the root are the systems. It's very easy to build RTDM in root because if you build it in root, pre-empt RT is a single Gardner patch so you are just to have to configure the kernel and to say the Gardner patch is here with the configurator, graphical configurator. And Xenomai and RTDM support have been available for a long time, so it's quite simple to install. For the octo, there is a dedicated kernel recipe for the Linux and octo kernel, which is for Linux and octo RT. With a dedicated image, core and great RT, with a dependent on Linux and octo RT, it's just this... There is only one dependency on the kernel plus adding RTTest, which is a set of tools for testing real-time. But if you check the recipe, the compatible machines are the two immune systems, which is not the choice for real-time. So, you can save just for our tests, for our testing, and it's a great channel for preempt RT, but it's not ready for using real-time. For Xenomai, there is a support in NITAR, the SDK from DeX, which is quite old. And so, it's not very useful today. And it's dedicated to the SDK, which is a specific distribution from DeX instead of Kotlin. Well, so, in the octo, you have a very interesting functionality, which is exactly the recipe. So, you update the recipe, the PD, which is a PD apple, and the most simple example is a splash tray. There was a before splash tray with open and middle logo. And in the new NITAR-P, there is the same recipe with a PD apple and a new logo, which is the octo. So, it's quite simple to change files, to add files, to define new functions. For example, this recipe, extended recipe, activates the IPC bus on the Raspberry Pi, because it doesn't activate the IPC bus. So, we can use this system for pre-empty. Pre-empty is very simple, because you can just to patch a calendar. So, we create a new, a new area, with the address name, and you add a recipe for the calendar, with an extension of the recipe. So, you have to define, of course, the path of the patch. Thank you, patch. Configuration file, which is always a very complete file, you will stand out in the octo calendar. And it will be a plan with only lines, which are these ones, except the whole page, because it's not dedicated to both. Pre-empty can have branches available from some walls. So, you don't have to write a patch, you don't have to get to commit for the active branch. For example, the bigger one, there is a branch for pre-empty. Pre-empty. But it's much more complicated for Xenomite, because you have two parts of Xenomite, so we have to develop for specific player. This one is not really a specific player, it's just an extension of the kernel. Just one word about beta with deep write. There is a logic scanner, of course, in beta with deep write, but it's not really compatible with extension. So, you have programs you want to write fragments or extensions. So, I wrote a new CD for sort of readings, rather by kernel. But it works only for in-creep and the standard kernel works for all type of pre-empty file. So, Xenomite is difficult as you have to patch a kernel with a specific script which is for pre-empty kernel. It's a patch that it sets the settings between 5 so you have to develop for Xenomite. And you need to understand that this file is very difficult but you have to do that. So, there was a bit of Xenomite very awesome. It was really a big part of this. So, I got the current bit of Xenomite and I create a new reading Xenomite that will occur only for a day-by-day read. And the user space PCB which is auto-proof-based quite simple. The most difficult part is to have a specific function to patch the kernel to run a feedback kernel before configuring the kernel. It's only for provide, of course. And this function is executed with a kernel with a hard task. So, the best way is to show you the code because on slide it's not that really does. It's simple. ReparKern execution. So, you run the standard procedure for installing the feedback patch to the kernel. You call ReparKern. And you say to your code to be great then you will execute ReparKern after the new patch after patching to the kernel So, it's quite simple. Quite simple. And a difficult part in Xenomite is to get the right patch because if you have a specific code with a specific kernel from USB you need to get the right patch to run with Xenomite. So, you have to adapt the patch. So, the recipe is the most difficult part of the work. The most difficult part is to get the right patch to work with. To configure your image in the local code file or you can create and communicate in that recipe. So, you need to use the pre-creditor or the command from Yoko. So, you say, pre-creditor of your first batch kernel in Xenomite. The recipe is the name of the document kernel. The default kernel. So, you say to force the default kernel to the Xenomite kernel. And then, you have to install of course the user space part which is Xenomite. The recipe is just user space store. I can show you the recipe but I'm going to show you how to get the conflict and some options that you can use. For example, you have to install the recipe and call the product but I think it is easy. And you can build a specific image of the kernel. Just one thing about the recipe. The recipe is quite specific because the default kernel is built by the Bluetooth. And I use the fake Bluetooth of your that is not officially your type and the previous type. But it doesn't work with Xenomite. I don't know why it should be a problem with real time. So, you have to force the standard Bluetooth of the Xenomite. So, you have to force the default of the Xenomite and you have to force it. If you use the graphic screen the graphic screen is ok but I want to use the graphic screen most of the time. I like how it works. Ok, so, what to do because I didn't test on the recent version of your code and this is to test on your code but most of the time it is done by a user you can get the recipe from Xenomite you just have to change the batch just to modify the recipe to match your kernel definition and it should be it should work I have some questions I don't know that but I can say that I use my Xenomite simple one to other things that I can show you a simple demo Xenomite will be very simple just to show Xenomite and Xenomite will be different because most of the time we have an association where you can start the Xenomite program on the code on the console and start the Xenomite program on another connection Xenomite is a tool to generate memory output from the system I think the logical trend is sending data between the processing so I will sell the the disk so you can see the wasp 4 microseconds so when you start the average you can see the wasp 5 microseconds and if I change if I change for 3m30 I just have to change the crash so you can you can start the cycle test in the RT test the wasp case is on the 5 microseconds to do the way to test to start the average you will stop the average the wasp case to be more than Xenomite but it's quite simple to use quite simple to install when you develop applications it's very simple just write a language, write a code and an application this Xenomite you need I didn't talk about it but you need to be decayed your tool is decayed so you have to develop a specific driver depends on what you need standard real-time and real-time if you need a hard real-time you get if you have been developed by Xenomite and actually my favorite was Xenomite and Xenomite was an amazing driver it was not a software project most of the time and lots of machines I used to have machines with cameras we had a project in Lyon I remember it was a camera we checked and we needed to do that it was based on this so the problem is we have time on this but the problem is network so we switch to Xenomite and we have a real-time camera and there are also projects in this project I can't say a lot about this we have lots of questions but we have lots of questions we have problems for example for brakes test is that the real-time because the real-time you can use but you should need real-time to use Xenomite