VS Code and Yocto Project by David Reyna, Rob Woolley

So my name is Rob Wooley, I'm from Wind River and David Drayne and I will be presenting today using Visual Studio

code

with the yakto

project

, so this is just a quick summary of what we're going to go over. We'll start with an introduction and talk a little bit about what Visual Studio

code

is for anyone who's not familiar with it and then I'll start giving a bunch of demos because I think seeing really is believing and we'll show how you could use Visual Studio code yourself to perform different tasks within the octa

project

such as creating recipes with Fitbit, debugging bitpake, working with SDKs and even doing remote development and then we will conclude with a conclusion, so first of all, why do we start?

On this trip, when we were walking around the office we saw that many of the junior engineers we were hiring were using vs code on every desk and when Covid hit, one of the things we really wanted to focus on was how we can improve. working from home because it is very different than physically being in the office, especially for embedded developers, so we asked ourselves how we could adopt modern cloud native tools and we also asked if we can develop applications using SDKs because there is a whole world of people who They are application developers. and they've never built their own distro from scratch and we'd really like to attract those people and tap into all those people building apps and lastly we also wanted to do this presentation to show what's possible for the community and see if there's interest . in building tools in the community for vs code, so what is visual studio code?

We'll start with him. It is available for Linux, Windows and Mac OS from Microsoft and it is really a new idea to replace things like Eclipse using more modern technologies and that technology is electron, if you are not familiar with electron it is built using the chromium web browser and node.js and it's actually built with html, css and javascript, which is great because you get the flexibility of all these web tools and it's really easy to extend. and the people coming into your university have the skills to do it, this allows for code completion, debugging, refactoring, navigating your code and everything else you would expect from an idea.

One of the other really compelling things is that there are already many useful extensions for embedded development. in the visual studio marketplace and more recently at microsoft they only added support for linux arm v8 and arm 64, sorry not for development machines so you could run visual studio binary code on your raspberry pi and your chromebook to do your work, that's all. Very good, but if you're a tool developer, you might want to know what's going on under the hood and why this is different from the setup you have now with vim emacs or your favorite idea, one of the things that makes Visual Studio The different code is this introduction of a language server and debug adapter architecture, which means that instead of having all these fragments coming from different projects or vendors, it is actually possible to interconnect them through the ide and make everything work together, and this is very powerful because it means you can create your own language server in node.js and link it to the vs code interface and everything just works.

The tools themselves are written in typescript, which is a strongly typed language that transpiles to javascript for the most part. The setup is backed by json so it's very easy to modify and the source code itself is available under the MIT license which is important to us because we want to make sure we can use a tool and invest in a tool that will continue to work . will be available to us, but there are binaries available from Microsoft under a Microsoft license now, if you really want to be completely free and open source, there is the vs codium version, which are binaries that are completely compiled from the source code of the license mit and even has its own completely open marketplace that you can pull extensions from and lastly if you develop an extension where you won't be stuck in vs code eclipse, it uses the same extension model and you can share extensions with vs code as well I'll start with the first demo that really shows what the bitbake extension in vs code provides to allow you to develop recipes in obvious code.

To get started, we'll simply launch vs code and go to show terminal here now. I already checked pocky and what I have. What I'm doing is running code minus r dot to reuse the window and now I'm going to the command palette and I'm configuring some workspace settings mainly to ignore some of the directories where there are a lot of files so the code doesn't. does. Don't go out and try to scan them next, we'll install the bitbake extension from the vs code market, which is quick and easy, and we'll also add Python, so we'll come back and we want to get the oeonet building and the extension actually uses this particular directory in front of Compiling bits of code and here we are going to open conflocal.conf.

Now the important thing is in the configuration before we specify that we are using qmu arm64, so I just want to make sure that the local conf matches and now I am uncommenting this line which actually drops the extension and actually runs the backend language server. This part might be a little cryptic. What it's actually doing is the npm code generates these shell scripts and these shell. The scripts are using baking in several big tools to trigger and query the recipes and layers and other things that exist in the build and you can see at the top that I ran in the terminal below, it's triggering a little bit of baking and parsing all the recipes and trying to understand what's going on and this is the normal progress.

This is where you'll see the normal progress bar where all the recipes open, so we'll give it a moment while it progresses because that progress bar takes some time. I'll talk a little bit about what the bake bit extension gives us so that the bake bit extension knows the format of the bake bit recipe and can highlight the syntax for you, but it can also know what layers you're using the recipes that are present as well as several bitbay classes that are present and you will see later how that information can be used to make it easier for the developer and you can see on the left side the project window. it's updating as you create different scripts and run through all these different executables so this is what you were able to find in three layers, 780 recipes and now if we go back we can show how this can be used so I'm going to start by adding a package to the image that we want to create and just for fun I'm going to choose vim so look here I get it from a dropdown and you know vim is a recipe and now we'll do the same thing with inherit.

I'm going to enable build statistics and you can see that it identifies build statistics as a class and allows me to auto-populate the rest, so that's interesting, but what about recipes? Let's go to the metaskeleton and pick up. Hello world, you can see that you have syntax highlighting and if we right click on this and go to the definition, we can show the bb class file corresponding to that, which is quite useful if you are developing bb classes, so that's it cool, the bit bake extension is really good if you're a developer and you want to develop recipes and build things on your distro, but what if you're actually working on bitbake, you're working with Python and you really do need to be able to debug and know what's going on under the hood we can also use vs code for that so this time we are going to open the bitbake folder because we are python developers and we want to focus on the bitbig tool so the first problem is that we have all the bitbake libraries and vs code no It doesn't know anything about them because they're not in the standard Python path, so what we're going to do is create an environment file so we can tell vs code where those bitbake libraries are.

Now that we have that file, we're going to go to settings. .json and we'll quickly add two lines to tell vs code where to block now, this is a bit confusing for the Python extension has created this configuration called python path which is not to be confused with python path. We just configured the Python path. There's a point here for the Python interpreter, but the final file will include that env file where we set the actual Python path and now. We're going to set up a release so we can run a little big, use the existing Python template, and we'll just customize it to run bitpick.

Now the trick here is that we are not in a complicated environment yet, so first we are going to set the arguments for the bitbay command to the minimal core image, we are going to set the working directory to the pockey build directory and we have to set the python path here as well so that when we run the bit bake command you know where to find the libraries you need when we said before that was actually for source code analysis and linting via intellisense but here this is for execution real from bitbake now because we haven't gotten an environment from a code vs. perspective.

We'll point it to a file that actually has the environment variables that you would get if you ran oe init build and I'll just use a quick one-line trick to put in the variables that were updated in that build. in the file and this is what it looks like. Notice that I was able to open the file with the envious code from the terminal now that we have everything we can go into debug and run and start debugging bitbake, so here it is starting up. You can watch Bit Bake. and one of its threads in the call stack window and we can pause it and take a look at what bitbake is doing, see where it is, poke around in the variables and let it go again.

This part is interesting because it has parsed all the configuration files. I'm actually going to shutdown and start the big server, so I'm waiting here just for that moment when it starts the server and starts firing the different workers, so it's only going to take a second or two just to check for some result. to make sure it didn't fail and there we go so it's actually running tasks and you can see all the big bit processes there so now here's the problem when the bit bake server was run, bitbake actually does a double branch which removes the pi development debugger so we need to connect to those new python processes using the process id so I used a quick template and this is where I thought about using pgrep and realized it is not necessary , you can simply start it and it will do it. tell you what processes are available and we can choose the kitchen and now we will pause the kitchen, so this is what the kitchen was doing at the time and you can see that the debug console is frozen because the kitchen is not advancing anything big.

The worker events come back to the UI and when we release it again you can see the UI refreshes again so we can disconnect from that and stop bitbake now because we abruptly stopped bitbake. I'll just make sure the lock file is clean. and it's super cool now you're unlikely to be debugging bit bake, but you could use foil to create some useful scripts to talk to bit bake just like the bake layers command, so you can use the same settings. just switch the program to bake layers and run show layers and you can use this trick to create your own custom applications that talk to the baker bitbig server and it worked correctly and exited so the debugger just told me it exited , so that's it.

Pretty cool now, if you're not creating bitbake recipes and you're not debugging bitbake itself, you might be interested in using SDKs to develop applications, so for the next section I'll start by showing how you would create an SDK using pocky. If you've never done that before, just do the normal quickstart setup with cloning the pocket repository, if you want Windows SDK I recommend you clone the mingw meta layer and add it, and also add some useful tools inside the image and then just run these commands at the bottom to build it for Linux and Windows now, even if you have these SDKs versus code, you don't know anything about how to use a Linux SDK and that's where these JSON configuration files come in, so that the The first is the Settix configuration json which is your project level configuration file and I use it to point out where the root of the SDK is and let it know what the various triplets are, then you have the one that is specific to c and lets Intellisense know. what you need to do and you can configure things like include paths and other things so that your code completion works with the SDK header files, not your system header files,and then you have tasks to do things like run the compiler and run make and lastly the startup json which allows you to start things like gdb to debug.

If you want to see the full examples you can check out this github repository where I have uploaded numerous examples of different setups that you might be interested in, so let's see how they work. I actually got used to it so we started with the vs code and I already installed a pocky SDK and then I also added a kernel image and the ext4 image of the root filesystem and we'll see how that comes into play later. and here is the clone of that repository that I mentioned before where we have a simple make file in the hello c example and I even added a pocky specific branch for qmux 8664. so let's open that, here is our simple hello c and here are those json which I mentioned before where we set up the various configuration data, so this is a pretty basic example that I'm going to add so you can see how vs code uses this information, so let's go ahead and add string.h but notice that I haven't closed it and there we go, it warns me with that little red squiggle that I made a mistake, I fixed it and now we can find string.h as it exists in the SDK. with full breadcrumbs, let's go to the studio, standardio.h, and you can see here that we have a schema for these header files, so if you're looking for one of your favorite C functions, you can find it.

Let's start coding. Now I'll just add a few lines to this example and you can see that as you do your work, the vs code gives you different suggestions of things that might interest you. Let's get rid of this one and use the other one. on the stack, I see that different red squiggles keep appearing to warn me about different things, but then once I resolve them naturally, it just disappears and is relatively unobtrusive, so we'll use the string char func function to actually look for the w in the string and you get a pointer to that and you can see that as I use these functions it pops up with helpful descriptions of what they do as well as the function prototype information, which is always nice when you can't remember what parameter the target was. and what was the source, we're going to copy Stonehenge into the string at that point that we found with string char.

You may have noticed that the lines on the left side are actually using get to track the changes we're making in green. it's a new line and the blue is the lines that were modified so here we go we compile the c file by itself but I also have a make file so I'm going to clean up using the make file and then run a build task to do a full build using the makefile, so we have our hello executable. Now let's see what we can do with it first. I'm going to start qmu using the vs code with the startup definition I have, which appears in our terminal log right now.

I have configured qmu on map1234 from the outside to port one two three four inside the virtual machine. Let's start the gdp server here. Now we can use our gdb launch to load the greeting from the outside into the pocky running inside the virtual. machine and start debugging it so that we have our call stack, we have all the local variables and we can start step by step through this and as you can see we have the printf coming to the output of the qmu launcher hello world and Hello Stonehenge, There we go, we're done. The gdp server will stay open for additional connections but I want to terminate it so I have a startup that tells it to close and shuts it down and that's it so that's interesting but those are things you can get in vim and emacs you know has done for the last 20 years.

What vs code actually brings to the table is different, so the only compelling feature that really sold me was this understanding of remote development as something built right into vs code, so what this allows you to do is connect to some container. remote virtual machine and when it connects it automatically installs the vs code server inside that remote OS, at that point it's like you're using everything locally. You can browse your project files, you can run extensions, you can even install extensions on the remote server that you don't even have locally, this is very powerful. I've used it to access build machines.

I have 128 cores and analyze builds. I have used it to access cloud resources on AWS by attaching them to containers and more, the three main remote extensions are remote containers to attach to docker containers so you have a reproducible sandboxed development environment, there is remote ssh to connect to those build servers or cloud instances for cases where you need additional computing power and remote wsl where you can use the windows subsystem for linux to give you a linux development environment on your windows machine. This is what it looks like. I don't actually need to demo this because it just works. no problems, there is nothing to prove when you use it, the only sign you have that you are connecting to the remote machine are the things that I have highlighted in red and this is very powerful, extremely useful and like I said, it installs itself .

When you first connect, most extensions I've tried will work with this out of the box, some of them that are doing more advanced things need help working remotely now, if that's not all else there is to it deal with the code. What it actually allows you to do is leverage the cloud for some additional features. The first thing that's interesting is this concept of development containers, so you can define a development container json file and point to a container image in Docker Hub that you want the people developing your project to use as the sandbox environment, for example.

For example, if you launch a Python application, you can provide a corresponding container image where you know that all the tools exist to build that application and run it so new developers can get started in minutes. An extension of that is Github Code Spaces which is currently in beta, so imagine you can log in to github, you get a big green button, you click on code spaces, and then instantly in your browser, it launch the code in your browser using the container image you provided. that new user and you don't even have to install anything on your machine, you could be up and running with the octo project in a minute or two and lastly, another useful feature that you might be interested in is live visual code sharing and this. is what I'm using here on the right side, my co-op student vikram and I were talking about some work we were doing with build statistics and some python we were writing and he can actually share individual files like it's a google doc . we can review it and we can both type it or point to things and we can see each other's cursor and this was incredibly easy to set up we just log in to our github accounts and we can continue so I'll do a quick demo just showing how a few can be used of remote functions, in particular wsl 2 remote, to do development, so this is my windows desktop and I'm going to start by just launching vs code and I'm going to clone that github repository.

I mentioned before and I'm going to tell you to go here now, the main branch is really intended for Linux development, so the first thing I'm going to do is go and check the branch with the specific configuration to use the Pockey SDK on a machine with Windows you can see I had to set rm equals dell and then if we look inside these json configuration files I mostly just had to point to the correct directory, escape the backslash and also change the colon to semicolon for the route lines there are. One issue I'm pointing out here just where I had to duplicate some of these variables because they don't get passed between json config files, so we're good to go, you can see it here even though we're on Windows. we can find the header file from the SDK itself and we have our hello c and we can come up and we can run the build task and just compile it with the compiler to make sure it's working, as you can see at the bottom.

We are using document style cc percentage for variables. I'm going to run the create target just to clean things up. You can see that it's removing it with Dell and then run the build task and actually build through the build file that we saw before. that's not much different let's do something different now let's go to the command palette and enable wsl remote so i took windowver linux which is based on the octo project and made it a windows subsystem for the linux distribution so that you can see it in the background. it's actually rotated inside wsl, the green at the bottom left shows it's up and running, we can go to the terminal and we're actually inside the window for the linux wsl instance, now let's go find that hello file , there is a plan 9 file system that shares files from Windows to Linux and voila, we just ran the Linux executable that we compiled on Windows.

Let's put that output in root.output.txt. Now let's go to hack wsl dollar slash point to the winterfell linux wsl distribution, go to the root directory, double click and now hello world appears in notepad, so we don't just use the userspace generated by yakto, but as an added measure I decided to go and put a yakto kernel inside wsl. Also, this is a 100 percent standard Yacto kernel with a bunch of virtualization features enabled to make things like 9pfs work and turn out to be preemptive, so those are some of the things you can do with vs code to make it work with yakto. most productive project this is really just preliminary research and there is much more work to do.

I would love to work with the

yocto

project community with all of you to develop this further and see where we can take it. I would recommend that we adopt and maintain the spit bake extension. It hasn't actually been updated in a year or two. Expand it to take into account recipes and packages. If you were paying close attention, you may have noticed that the installation annex in the image was looking for recipes and I think technically those are packages that at that point provide appropriate identifiers based on context like that and maybe even extend it to provide recipe templates and support for recipe tools and development tools.

I also think there is a lot of value in being able to create new extensions for vs code to talk directly to baking using things like foil or xml rpc directly, you could create web based visualizations for things like the pi bootstrap graph that we would display in vs code or in a regular web browser and we can improve the SDK development workflow is even more for application developers and I also think there is great value in extending crops to take advantage of things like development containers so that people can start using

yocto

right away from github and lastly i would like to thank several people who collaborated with me on this, first i would like to thank martin bjorkstrum and eugen veens for developing the vs code bitbake extension and i would like to thank joseph rudolph, tim joshua and

david

for all the valuable comments they have given me. been doing this for the last few weeks and a special thanks to Animal Singh Men, who is an intern working for David and who helped port the original proof of concept he did with Winddriver Linux to Pocky.

If you want to try this yourself, check out that gif. hub link for instructions on how to try it at home using pocky or with Wind River Linux for Intel Raspberry Pi or Windows. If you're interested in trying it out but can't build the entire platform right now, you can find the preview version. SDKs and binaries created for Intel and Raspberry Pi in the following location on Winddriver Labs. That's the end of my presentation, thanks for listening and I hope you found it useful.