 Hello! Thank you very much for being here. My name is Maxim Masalski. I welcome participants of the Open Source Summit North America 2020. I hope you all stay safe and healthy and I'm pretty sure most of you are now working from home. I'm a software engineer in Intel Corporation. I'm working in the team responsible for the development of the Zephyr Real-Time Operating System and its QA process improvement. Today we'll talk about Zephyr Arthos, its juicy features and my experience applying that system for the robotic development. For my tutorial I will use a small robot and arm-based evaluation board called Microbeat. Please take a look at that agenda. First I will talk about Zephyr project review. Also we'll cover key points of the Zephyr Arthos. Then I will move to the part two which covers robots, Microbeat board description, how to develop an application for the robot using Zephyr Arthos. And finally we will make a tutorial how to program a line follower robot using Zephyr Arthos. Let's start our tutorial from a brief introduction of the Zephyr project. What is Zephyr Arthos? It's a small scalable real-time operating system optimized for resource constrained devices across multiple architectures. To my mind Zephyr is at the bleeding edge of device real-time operating systems. When I said small I mean image footprint weight. Minimum configuration to print just a hello world message is around two kilobytes and the maximum configuration is up to eight kilobytes. You can agree with me that it's impressive characteristic for the Arthos. So Zephyr can run comfortably in eight kilobytes of RAM and can even run in a minimum of two kilobytes of RAM. It's an open source real-time operating system. To host source files we are using github. The software is a perfect choice for simple connected sensors, LED variables, MADEMs and small wireless gateways. It's a Linux foundation hosted collaboration project. It's permissively licensed under Apache 2.0 license. As I said before it's managed on github. That's our project link. We built our Arthos to be secure and safe. So develop with the security in mind. Great community support. We are like international developers family. Our Slack channel has more than 1,600 people. Every day I join with new members, many conversations on Slack and github. If you would like to receive any support you can be sure that you can receive it. Also every week occurs open daily meetings where everyone can join and discuss testing issues, issues about performance and so on. The growth architecture with broad system on chip and development board support. Therefore supports more than 219 boards of different architectures like x86, ARM, ARC, Nios 2, extensor, POSIX, RISC 5. That means no need to develop support for your board by yourself and it can really save time. This diversity of supported boards gives developers and product manufacturers multiple options to solve the embedded Arthos challenges with Zephyr. If your board is not supported out of the box adding new board and support for it quite simple. We have special documentation and you can follow it and find all necessary information about it. Vendor Neutral Governance. It's driven by Technical Steering Committee. For now Platinum members are Intel, Nordic, NXP and Oticon. Silver members are Adafruit. The company produces electronics for DIY makers. Maybe you heard about it. Also a company called EndMicro both found with IO, Layered, Linaro, Sci5, Synopsys, Texas Instruments. Complete, fully integrated, highly configurable, modular or flexibility. Developers can create a solution that meets their needs. The most powerful part of Zephyr that is configurable options Kconfig. It allows you to set up Zephyr on the fly. About that option I will talk later more. Product development ready using long term support includes security updates. Zephyr is growing fast and it's changing fast too. So sometimes it will be challenging to use the latest master on the production level. Rebasing really can be painful if you know. But with the help of the Zephyr long term support releases your product development could be more stable and predictable. Please take a look at the table. There are important key points which can play a big role when you decide what are tools start to use for the project. First column called developing with Zephyr. If you want to develop with Zephyr, use GitHub, create a pull request to the master if you want to add a new feature. Our SDK supports Linux, Mac and Windows. I'm using Linux Fedora and I want to develop for Zephyr. For hundreds of boards I develop sample applications that can help you to understand Zephyr better. You just find necessary board from the list. That is list of supported architectures and for each architectures there are many boards. As of June 5th Zephyr total has more than 41,000 commits, more than 687 contributors, 37 repositories and more than 16,000 pull requests closed. Impressive numbers. I'm sure when you're watching that presentation that numbers are growing and changed a lot. Now please take a look at column called architecture. There are key points. First is modular and configurable. Zephyr has two types of threading cooperative and preemptive. Memory resources are statically allocated. Zephyr has integration of device driver interface, stack overflow protection, thread isolation, kernel object device driver permission tracking, native and optimized IP stack, Bluetooth mesh and Bluetooth low energy support. You can see there is a table where you can find all Zephyr architecture structure. We have kernel, kernel services, schedules, power management and platform, then OS services, application services, like this. Let's move on and our last column called small Linux browser. To my mind from the Linux developer side, Zephyr RTOS can be called the small Linux browser. Zephyr is taking the best practices from the Linux. The Zephyr kernel and subsystems can be configured at build time to adapt them from the specific application and platform needs. The configuration is handled through K-config, which is the same configuration system used by the Linux kernel, like make menu config. The goal is to support configuration without having to change any source code. You can write kernel configuration settings in dot configuration file for permanent use or use terminal or graphic user interface to choose kernel configuration options. In the picture below, you can see an example how the graphic user interface of the Zephyr kernel configuration looks like. You can choose any options and then build a kernel with that option. Also, I can add that Zephyr has a Linux coding style, device tree used for board definitions, integrated Kimu support. No need to have special hardware to get started. You can use Kimu to run your application or sample application. That is key points of the Zephyr RTOS. Now we are going to program a robot using Zephyr. I decided to test Zephyr in real conditions and develop a simple device that can provide an experience to use Zephyr for robotics development such as motor control, sensors reading and finally control of the robot. For that project, I decided to create a line follower robot based on Zephyr RTOS, microbit development board and small robot car. You can see robot car, microbit board. We will flash Zephyr on it and it's connected by Zephyr. Here is the board and the robot chassis. How do you write code for your robot? Before I had experience programming Arduino boards and creating robots based on them, I wanted to level up my robotics development skills and started to use RTOS to have a new experience in codec or robotic devices using Zephyr. I think Arduino is a great platform for the development of prototypes, but if we are talking about production development, definitely it's not the best choice. Most common Arduino boards are 8-bit microcontrollers, but Zephyr supports more powerful things like X86, ARM ARC and etc. As I mentioned before, I wanted to see how Zephyr can challenge that task. I want to notice that rare ARM Arduino boards are supported by Zephyr like Arduino Do It and Arduino Zero. Recently, I found that four Arduino were developed an extension to develop with Arduino API using Zephyr RTOS as a base system. You can find it, open that link. Unfortunately, I didn't check that, but you can try if you know Arduino well. Just using Arduino language for programming instead of directly using C and Zephyr APIs here. But we will go and use Zephyr RTOS to build a robot. It can be difficult for Arduino developer, but I think it's a chance to level up your DIY robot development skills. Let's start our tutorial. I want to introduce you a micro-bit board. As I said before, Zephyr supports various boards, more than 200 of different architectures. I decided to use a micro-bit board, which is an ARM architecture. Initially, it was created in England to use by kids during coding classes in schools. I used that board to teach kids coding, and one time I found out that micro-bit supports Zephyr. I took it from them, and now my kids are reading books and not studying programming, because now it's my toy. Joe, I bought one more for myself. It's inexpensive board. I think maybe the cheapest one you can use for hardware experiments with Zephyr. You can code that board using scratch, may code, or even Python. And because it has NRF 51 chip supported in Zephyr kernel code, finally I can run Zephyr RTOS on it. That is technical data. Size 4 by 5 centimeters, or 1.6 by 2 inches. It has two programmable buttons, button number one, button number two. Three digital analog input-output rings. That is zero, one, two rings. You can connect something to them, and that is power ring to connect power supply. 25 individually programmable LEDs. That is LED matrix, which you can program, and it can draw different images, digits, characters, and etc. 32-bit Cortex-M0 CPU with Bluetooth low energy. The board has accelerometer, compass, temperature sensor, and gyroscope. 20 pin edge connector. It's here, 20 pin. You can connect additional expansion boards to them. And micro USB connector. It's here. Two flash program to the board. I think it's enough to create your own robots. And we can use Zephyr APIs to read data from sensors, using GPIO trig pins of that board, send I2C comments from that board to the connected devices, have a lot of fun. Really, you can use any board to run Zephyr. Now the market has a lot of boards made by STM or NXP, or real board to any other company with built-in sensors, buttons, and LEDs. Unfortunately, if you want to build a robot, like in my case, the easiest way is to use Microbit, because it has many expansion boards for different purposes designed to use in your DIY project. We will talk in the next slide about expansion boards. As I said before, Microbit was initially developed for kids. So many additional platforms were designed to be connected with Microbit, robot cars, drones, wiped robots, robotic arms, etc. To my mind, it's okay if we are talking about creating DIY robot during your free time or just trying to program a robot if you never did that before. I think the number of boards and robots for the Microbit are the same as the Arduino ecosystem has right now. With the Microbit, you can build your own drone, robotic arm, various car chassis, and wiped robots. And you can program them also using simple coding languages, like scratch, make code, or if you want to move forward, use Zephyr and see language to program your robot. I already ran some samples from Zephyr Source 3 for Microbit, like Bluetooth mesh sample. I think the Microbit for Bluetooth mesh demo is the cheapest way, have many boards connected in one network, because the price of one board is really low, and I don't know any other evaluation arm board cheaper than that. I decided to move forward and create my own sample and merge it into the Zephyr Source Code 3. As you remember, my idea was to create a line follower robot and to program line following function of the robot using Zephyr. So our robot will follow that black line and program will be written in C and be powered by Zephyr Arto's. That is video of my final project. Now I will talk more about line following robot. For the robot, I used simple two-motor robotic chassis with two line sensors on it, that is line sensor and motor. You can see a photo of that robot. Line sensors are underneath somewhere here. Size of the robot is three by three inches, it's a tiny robot. To control motors, a robot has I2C drivers, that is I2C driver for each motor. There I will use Zephyr capabilities to bind I2C device according to its address and send appropriate control commands. Line sensors are binary sensors, so they send value low or zero if detected dark surface and value high or one if detected white surface. For them, I will use Zephyr GPIO control capabilities. The manufacturer of the robot provides a line following program for that robot. That program is written in make code language. It's a graphical language created by Microsoft and designed for kids to teach them programming like scratch programming language. Background of that graphical language is written in JavaScript. Then I started to think about how to port that program to C. So we have make code program, it looks like LEGO bricks, you can see. Easy to code but for our task necessary to understand how that program is interpreted to be executed by the robot. Need to investigate what drivers and principle of motors control, need to investigate what drivers and principle of line sensor data reading. Here you can see that blocks and their implementation in JavaScript. I contacted a manufacturer and asked them what driver model and method of control PWM or I2C and model of the sensors they are using. First we have block for motor. It sets speed, then you can choose left or right motor by choosing M1 or M2 and direction of rotation clockwise or counter clockwise. Here is code in JavaScript but still not enough necessary to dig into code sources. That is locked to read data from line sensor. You can choose sensor left to right and that's all. Returns value 0 or 1. Here is JavaScript code. For kids that blocks are black boxes but for me it was necessary to dig in and understand how they are implemented to the code in my Zephyr application. I continue reverse engineering of the make code program. The robot manufacturer provided me their library on GitHub. Then I investigated blocks implementation in a low level code layer. I found they had all code definitions in TypeScript file and there I found all control code for motor and also code for reading data from the sensor. Motor driver information. I found out that motor driver uses I2C bus. Also I found out in that TypeScript file all necessary I2C commands to control motor driver. As Zephyr supports I2C and communication with I2C devices I can control motor driver by knowing its address and control commands responsible for setting motor speed value and motor rotation direction. That is line sensor information. Robot has two line sensors. Line sensors are binary. They use infrared LID to emit light and then measure the amount of the reflected light and we can and line sensor can detect if it's white surface or it's black surface because if white surface light will be reflected a lot and it will not be consumed by surface but if it's black surface light will be consumed by surface and will be just a few reflected light. You know that black car in hot weather becomes more hot than white. That's because it consumes all falling light on it. So using Zephyr GPIO I can read data from the sensors. Also I find out necessary pins to which microgrid board is connected and that is pin 22, pin 23, one pin for each sensor. So basic idea will be to keep a black line between two sensors and it will be enough to let the robot follow the trajectory of the line. I think it's time to start creating an application with Zephyr RTOS. First of all let's talk about the Zephyr application structure. Zephyr's base directory hosts Zephyr's own source code, its kernel configuration options and its build definitions and so on. The core of the RTOS is here, Zephyr project slash Zephyr. I created an application directory called line follower robot here. Inside the Zephyr source code base directory to make it possible to add my program to the GitHub because I want to create a pull request and merge my code in Zephyr source tree. My directory will contain all application specific files. So we create an application directory, line follower robot, then I created source directory to store source code and additional libraries if needed. Then I want to show you how we'll set up our application. Kernel configuration options will be within the project.conf file and cmakelist.txt will be in directory line follower robot. It will be used to generate build files. Also I created a readme file because I want to generate a documentation using Doxygen and after my code will be merged documentation for that application could be visible on docs.zephyrproject.com web page. It will be later visible there. You can refer to the official Zephyr page where you can find a more detailed description of the application development process. I'll create application directory, place all source files there. Readme file with sample description after merging my PR to master will be on official documentation web page. And as you can see my program already merged and you can find readme here by opening that link. Building an application. Zephyr's build system is based on cmake. The build system is an application centric and requires Zephyr-based applications to initiate building the kernel source tree. The application build controls the configuration and builds process of both the application and Zephyr itself, compiling them into a single binary. The default build tool in Zephyr is vest. Zephyr's meta tool which invokes cmake and the underlying build tool, ninja or make behind the scenes. So Zephyr build system compiles and links all components of an application into a single application image that can be run on simulated hardware or real hardware. Like any other cmake-based system, the build process takes place in two stages. First build files, also known as a build system, are generated using cmake command line tool while specifying a generator. This generator determines the native build tool the build system will use in the second stage. The second stage runs the native build tool to actually build the source files and generate an image. To learn more about this concept, refer to the cmake introduction in the official cmake documentation. As I said, Zephyr has a vest meta tool which invokes cmake and you can choose two variants, use vest and command vest build-b, board name or use cmake and ninja. On Linux and Mac cost, you can choose between the make and ninja generators. It has build tools, whereas on Windows you need to use ninja, since make is not supported on this platform. I am using vest build to build my application, but you need to remember that vest by default is using ninja under the hood. We have source application, we have build process, two variants, but vest build still uses ninja under the hood. Then we receive build directory contents, like zephyr folders with which stores kernel image file. Then we have two options, running in an emulator, also we can use vest build-run on ninja run or running on a board, vest flash or ninja flash. If necessary, we can use debug. Setup zephyr application, before you can build your application, you need to make a setup of it. I will talk about files which I described before, like project, conf file, cmake lists and sample.yml. The most important is project configuration file. To set up current application necessary to enable vital configuration options. For example, to control I2C device motor driver and read data from the sensors necessary to enable them in that file and add proper configuration options. For my application, I enabled I2C, GPIO and console output. That is cmakelist.txt file. cmakelist contains all required commands to build application. The first line sets the minimum version of cmake for the project, which is major version, three minor versions, the tidian page version one. Providing the version number allows for a future support for your build environment. The second line finds and loads settings from an external project. Search pass for zephyr specified by the hints. Current zephyr base variable is home, in my case home slash maximum zephyr project. The third line is the project command that sets the project name. The fourth line generates a list of files that match the globing expressions and stores it into the variable app sources. The fifth line specifies sources to use when compiling a given target. Our target is called app and applied a private keyword. We'll populate the sources properly of app target. sample.yaml file. That file is used by sanity test system to detect test cases. Zephyr Arthos has special script called sanity check. That script can run all tests and generate a test report for each board. So QA team can review that report and see what tests failed and what tests passed. That sanity check is our testing system in Zephyr. It's written in Python. That file is necessary to have if you are writing tests for your Zephyr application. So sanity check can read that file and detect test cases in your source directory. That is important files for Zephyr application and its setup. After setup the Zephyr application, let's move on and create main.c file. There I will put my robot application code. Firstly, I added the copyright and license description. Number two, add correct headers to use necessary API. I included necessary header files. The most important is Zephyr.h. No Zephyr application could work without it. Then I added appropriate header files according to my needs. sys-printk for console output, drivers-gpio to make it possible work with GPIO pins of the micro-bit board, drivers-i2c to write control commands using i2c bus to control motors speed of the robot. Device had a file to add an i2c device and bind it with the micro-bit board. As you can remember, robot has a standalone i2c motors driver. Three, then I defined the i2c slave address. I found out it from the reverse engineering of the make code program for the robot. That is a dress. i2c control in my case will work using method master slave. The master is device micro-bit board and the slave device is an i2c chip of the motor driver. Also necessary to add correct defines for GPIO settings. External edge connector pin mappings to nrf51 chip GPIO pin numbers. Micro-bit is using the chip so I set correct pin mappings for GPIO pins connected with line sensors. Also I found the numbers from reverse engineering of the make code program. And the last one create device data structures type struct device. It is necessary to create device driver instances of the appropriate type the GPIO and 4i2c device. Device driver model. Let me make a short introduction about the device driver model available in Zephyr. The Zephyr kernel supports a variety of device drivers. Why that driver is available depends on the board and the driver. The Zephyr device model provides a consistent device model to configuring the drivers that are part of the system. The device model is responsible for initializing all the drivers configured into the system. Each type of driver for example SPI i2c are supported by a generic type API. In this model the driver fills in the pointer to the structure containing the function pointers to its API function during the driver initialization. These structures are placed into the RAM section in the initialization lever for the order. Standard drivers. Device drivers that are present on all supported board configurations are listed below. Interrupt controller. This device driver is used by the kernel's interrupt management subsystem. Timer. This device driver is used by the kernel's system clock and hardware clock subsystem. Serial communication. This device driver is used by the kernel's system console subsystem. Intropy. This device driver provides a source of entropy numbers for the random number generator subsystem. Device data structures. Struct device. The config info member is for it only configuration data set at build time. For example base memory mapped input output addresses. Interrupt request line numbers for other fixed physical characteristics of the device. This is the config info structure. Best to the device pointer init macros. The driver data that struct is kept in RAM and is used by the driver for the per instance runtime housekeeping. For example it may contain reference counts, semaphores, scratch buffers and etc. The driver API struct. Maps generic subsystem APIs to the device specific implementations in the driver. It's typically read only and populated at build time. Subsystems and API structures. Most drivers will be implementing a device independent subsystem API. Applications can simply program to the generic API and application code is not specific to any particular driver implementation. So more comprehensive information about device drivers in Zephyr. You can find openings at official documentation website. Come back to coding Zephyr application. I'm continuing coding of the control program for the robot. Now it's time to write a function to read line sensor data. Code will call that function when interrupt will happen. Function to read line sensor data called line detection. That function assets a pointer to the device driver instance. In my case a GPIO driver instance. A pointer to the GPIO callback function and number of pin to read. Inside of the function I will read raw data from the pins and will write them into a separate array left line data and right line data. And some debug print key. That function will be called as a callback when interrupt will happen on pins connected to the line sensors. To make that I created a new structure of type GPIO callback named line sensors. Then I got device binding for GPIO according to the specifiers pin cell at an index using macro DT GPIO label with input DT alias which gives a node identified from alias SW0. The same API and action I need to bind I square C device. Then I configured GPIO pins of the board for input. Using API GPIO pin interrupt I configured to generate an interrupt when signal will change from low to high and from high to low. So it will be like this. Interrupt or if from high to low it will be generated and interrupt too. As you remember line sensors in the current robot are binary so they can send only high or low values to the receiver. Receiver is a micro bit board. Depending on your task you may configure GPIO pins to react only if signal changes from low to high or vice versa. Then I initialized callback for GPIO using a bit mask for pins that is GPIO initialization using a bit mask for pins and added previously developed function line detection function. Here is GPIO need callback line detection function to read sensors data. Then I added that callback to the application using GPIO at callback API. Next slide I will describe motor control functions and later I will explain about whole program line follow. In this slide I will describe function to control motors. I wrote two functions one function to control the left motor and second function to control the right motor. As example I will use function to control left motor. Function to control the right motor is absolutely identical. That function accepts the speed of the motor as an argument. Value of that argument can be from 0 to 255. According to the motor driver chip control commands found from the source code on github from 0 to 255. The function accepted negative value of for example here. That means rotate motor into the opposite direction. Before sending i square c command necessary to make a package and set up unnecessary values. For example buff 0 stores channel address left or right. In our case left because left motor. It has address value. The buff 1 stores value which is responsible for the rotation direction of the motor. So clockwise or counterclockwise. If less than zero that means rotate motor backward. So that is its value to rotate motor backward or rotate motor forward. Move robot forward. Assault value stores the speed of the motor rotation. As I accept int I convert it to hex. After the array has all values in place it's possible to send the amount of data to an i square c device using the API. i square c write. This routine writes a set amount of data synchronously and that is address of i square c driver. That's how works function to control motor. After having all necessary functions we can create main function called linefollow. There will distort a linefollow algorithm for the robot. Line sensor sends value zero if black surface detected and value one if white surface detected. Here is a code example of the line following algorithm using two line sensors left and right. The best idea is if both sensors detecting black line detecting black line both the robot is moving forward moving forward speed 200 just value not miles per hour or kilometers per hour. Then if not if the right sensor detected white surface and the left sensor is still detecting black surface that means the line is turning left. That picture you can see if right detected white left detecting black surface necessary to turn left. So we are turning left left motor has speed zero and right motor has speed 200. As a result robot will start turning left. Accordingly the solution is made if the line is turning right the same. If robot is turning right here is an algorithm for it left control 200 and right control motor put value zero. Also there is some additional branches like this like this inside that main if closes to detect some exceptions one and two. Now that our main function to control the robot if both sensors are black go forward do something changes turn left turn right after creating an application for Zephyr necessary to build it and upload Zephyr binary to the board. First you need to set up Zephyr environment to develop Zephyr application. Zephyr supports Windows, Linux and Nikos. Just follow that guide and set up your Zephyr development system. After you completed all the steps from the guide let's try to build an application. Connect microbit to the computer using micro usb cable. Then we will use west build command as you can remember you also can use CMake and Ninja. Now we will build an application running in my directory home maxim Zephyr project Zephyr. I write that command west build this attribute minus p is pristine so the little build which was made before minus b is board no case bbc microbit then samples both bbc microbit line follower robot is our application directory and press enter and we will receive the executable file in our case Zephyr elf file but Zephyr also builds dot hex and other formats like DTS or bin they are all available under build Zephyr directory then we will flash our image to the microbit board using west flash the same command you can you can replace it using pyocd as you know west is just a meta tool under the hood there are other commands that like ninja flash after we flashed image successfully necessary to turn on robot and put it on the track it will follow the trajectory of the line please watch that video and see how the robot is following trajectory of the line with Zephyr of course that example is very simple and someone can call the sandbox yes it is that is a simple example of how Zephyr can be used in DIY reporting and utilize with juicy features Zephyr Arthos is still developing and growing every day it helps Zephyr repository receives new PRs improvements in bug fixes if you want to be on top of the edge and utilize the latest Arthos technologies for a project welcome to join Zephyr join Zephyr project here is a quick summary of resources to help you find your way around my advice after you read official Zephyr documentation here if there are some questions the best way to use our slack channel you know I recently came into the software development from the DIY robotics development many years ago I used the Intel Edison boards in my robots as you remember Intel manufactured that kind of board and now I'm developing Zephyr Arthos which is going to glove millions of devices across the globe I think it's a good starting point for everyone who wants to try himself in the robotics programming or programming of the IoT devices good luck and thank you for your attention I hope that you like my presentation so there is a time for QA I will glad to ask you questions about Zephyr or Zephyr plus robotics I received some questions already about what model of robot I used so in case if someone didn't notice okay phone is muted good let let let me see new questions from Jeffers and Rodrigo Will do you see Zephyr being used also for 3d printer I think yes why not because all in all we can consider 3d printer like a robot so it's not a problem to control stepper motors using Zephyr just need to communicate with stepper motor drivers using I2C and it should be quite easy to implement this I think you need to try and then you can share your results on github or your project can be on Zephyr web page next question from Todd what is like to develop a driver for a peripheral where you need to access registers you can use ASM for Zephyr to access registers so for that question I can't give you a comprehensive answer so better for you to ask that question on slack because mainly I didn't develop drivers for Zephyr directly next question Mahendra Taylor what is the one thing about starting with Zephyr that you can say you wish someone has told you when you started I think dig into code more don't be scared of some obscure things try to understand how kernel works I think it's main things which you need to study when you start to use new operating system for a project so just don't be afraid to make your hands dirty use samples run samples dig into code see pull request and try to understand and maybe you can contribute some new features for that project like this Everett Garcia asks about level of OTA programming via bluetooth or wi-fi answer on that question I don't I will tell you directly and you can ask this on slack definitely someone can answer as is right now so a slack community more than 1000 people so every question can be answered maybe within one minute quite fast next question Mahendra Taylor can you have your application folder outside Zephyr folder yes of course you can because as we're using CMake and CMakeList.txt file so we can find you can find your application everywhere right so in my example why I developed a application inside of Zephyr 3 because I wanted to be merged with upstream code that's why I developed it inside Zephyr directory so my answer yes you can have application folder outside the Zephyr folder question number 15 Dennis Chakwanta sorry if I pronounce names or she names a little bit wrong how efficient is it with Raspberry Pi for Raspberry Pi how efficient it I didn't run Zephyr on Raspberry Pi but I think it supports to run Zephyr on the Raspberry Pi's ARM chip I'm not sure about any KPIs and how it can be efficient difficult to answer a question hmm can't answer it directly to say you something maybe again just try to ask on slack and maybe someone tried run Raspberry Zephyr also Raspberry Pi so any any new questions let me see if I didn't miss anything I had a question about a recommended IDE you can use Eclipse IDE I'm using Veeam or VS Code new question from Andrew Taylor is debugging done using a graphic user interface yes you can do that gdb debugger allows you to have a some kind of graphic user interface of course it will not it will not look like in Microsoft Visual Code but we can say that yes it can be considered as graphic user interface using gdb oh thank you thank you yeah it was not easy because my internet speed is quite low so thank you for your support it's I appreciate it thank you well no no questions if no questions are you going to make a source code available for a question from use of isa yes my source code is available because it's already merged in the master branch it's already upstreamed uh so you need to go to the github Zephyr Arto's project link and in samples for BBC micro bit board you can find my code it's already upstreamed I can I will to give you a link so it can be easier for you to find there is a link not sure if I can share it with everyone but I will make reply public yeah here is it link to source code how painful was the upstreaming process um it depends on what you're trying to upstream it depends if it's a kernel feature if it's a driver or it's a sample uh Zephyr community and Zephyr code maintainers they're welcome to any sample code for the boards because the best what we can do now for Zephyr is to make samples for any boards like x86 architecture arm architecture um risk architecture because if we will have sample for the board developer can easily can try out and see what samples are created and can create his own design or his own code so for my for my code it was it wasn't so painful it wasn't so painful but if I'm upstreaming some kernel feature or something like this or test test for Zephyr it can be painful because many comments about how to create this yeah not not not not painful yeah let's answer like this no we had 20 20 uh questions and we had more than 100 viewers for the presentation I really didn't expect that uh great results if any questions I'm ready to answer them for that presentation well no questions I can tell you one story for that presentation I wanted to use a small drone like an example but I didn't have enough time to program drone make it fly for using Zephyr to us but definitely for next presentation I think the best uh example will be create a drone small drone which will be powered and controlled by Zephyr Arthos uh I think it will be a great use case for that uh new question from 19 Johan sorry if if I pronounced your name wrong uh what's the scheduling algorithm for the Zephyr Arthos about scheduling algorithm I can I can give you a link to our docs document there is description about scheduling algorithm for uh Zephyr so in shortly so the kernel scheduler it selects the highest priority ready thread to be the current thread so when multiple ready threads of the same priority exist uh scheduler chooses the one that has been waited waiting longest I think I replied on your question thank you for the question it's good question good question I will give you a link so you can read more here is link for you we have 18 minutes to go and I see that there are 32 people still there so don't be shy to ask questions about Zephyr Arthos I'm there to ask for them about the link I send it in the comment I will now reply again if it is there try this your number 23 I replied there I attached link one more question how can you find out what configurations are available and you don't have linux background you can using Zephyr as I said in my presentation there is a kconfig file where you can specify all configuration options necessary for your application by default all configurations are like turned on so if you need to specify and make your Zephyr image file dot hex file smaller you can choose necessary options the best thing what I can do is to provide you link for the documentation because Zephyr Arthos is an open source project and it has great documentation about everything and about kernel configuration options too and I think it's the most powerful feature in Zephyr because no any other Arthos for now they don't have such feature as I know because Zephyr even has a graphic interface to configure kernel like in linux it's really powerful thing and very convenient for a developer that link one more question from Andrew Taylor in the application do you use multiple threads no I'm not using multi-threading in my application I'm using a single thread with interrupts when signal from the sensor comes interrupt interrupt request is coming like this it's made to read sensors that dead so we have 25 questions answered five more questions and it will be 30 so I think if no questions coming but there's still 28 people we can finish our session I really appreciate that you joined my presentation and learned a new about Zephyr Arthos and how it can be used for robotics purposes I want to say thank you for everybody stay safe and healthy and I hope to see you in contributors of Zephyr Arthos on github so you're welcome just install Zephyr and have a try thank you very much bye bye