 Ok, så jeg er Håkon, dette er min præsentasjon om kogenerasjon C++ med GRC. Først vil jeg takke Martin for å klare dette ikon, jeg tror. Så, dette er min agenda. Først vil jeg snakke om GRC. Jeg tror ikke alle. Her har jeg tatt det. Så kogenerasjonen, hvordan det fungerer. Og så, hvordan det ikke fungerer. Det er ganske koget. Det er ganske koget, men stil, koget. Så jeg vil give en demonstrasjon om å bruke den. Så først om meg. Jeg er en student på Departementen av Engenering og Sermenetiks på NTNU i Trondheim, Norge. De har også spørgsmålet min trip her, så takk for det. Min involvment med SDR i genere startet i sommeren med participasjonen av ESA sommerkodet for NU Radio. My task was to work with GRC and civil cluster generation with the GRC. GRC is a graphical tool to build applications with NU Radio for SDR or DSP. You create flow graphs. It has been demonstrated in several of the presentations today. As opposed to some of you have seen it. It uses the GRC file format, which is YAML, and currently generates Python files until now because my task was to make it generate C++ files as well. So I'm going to start by showing you how it works. Really naive. Starts with YAML blocks. Each block of the flow graph has its own file, which is the YAML file. It contains several things, but mostly it contains the parameters, which are the options that you can decide when you're creating the flow graph. And then the template, which is the code. So when you're generating a flow graph, you're just taking the parameters and filling them in in the code wherever they're needed. Then this is fed into the Maco file, which then becomes a Python file. Just by filling in all the banks. So let's go a bit more top level. GRC creates Python files and can also, with my code, create C++ files. This generates, first of all, an empty build directory where the executable will live. And then it creates the CMakeList.txt and the source and header file. So here's an excerpt from a YAML block. And this is from the add block, from GR blocks. It's very simple. So the templates part, that's the Python code. And all the curly brackets with the dollar signs in front, that's where the parameters come in. And all that becomes this line in the middle here for the Python code. For the C++ code, it's a little bit more complex because you have several files and you have to declare types and so on. So with the simple templates, I have includes, which is just includes, goes in the header file. And you have the declarations, which is the declaration of types. Also goes in the header files. And then you have the make part, which is the make code. And that's basically just more or less the Python make, but with a semicolon at the end. So that's pretty simple. However, Python is a bit more simple than simplest. So we have a couple of things that we need to add. That wasn't in this add block. First we have the callbacks. It's just exactly the same as the Python code. And then we have link. Some of the blocks need to be linked at compile time. And we have to declare there, which ones are going to be linked to what libraries. So that goes in the Cmake files. And there's translations, which wasn't really a plan to include it, but it became necessary. First of all, Python writes true and false with a big f and t. That became a problem. Also the scope resolution operator is something that they don't have as a double colon in Python. So that was needed. So, what doesn't work yet? It's a matter of time, really. It will just take time and then it will work. There's a lot of code that has to be parsed for me and translated. So the hierarchical blocks are something of an interesting feature with GRC. You can put blocks or flow graphs inside flow graphs, so to speak. And that's a bit more complicated. So I haven't finished that quite yet, but I'm pretty close. The frequency sinks, all types of sinks, and sliders, and so on. They also have a lot more code in them than the standard trivial blocks. So it takes a bit more time. And UHD also is pretty large. And there's more than 500 blocks, I believe, just in the standard generator installation if you download it from GitHub. So that will take some time, but I'm getting there. So, now that we can use C++, we don't have to use Python any more. No. Unfortunately. At the moment, and I suppose it will always be like this, or what do I know, Python is easier for quick flow graphs and things like that in new radio. If you just want to sketch up something and run it real fast, it's a lot simpler. But for perhaps embedded applications and applications where performance is the essence, I believe C++ might be more interesting and more useful. So, I'm going to demonstrate GRC. OK, so here we have a flow graph. It's extremely simple. You have a signal source to a sort of block. Then you have two sinks, the waterfall and the frequency sink. The first thing I want to mention is, if you see here, for those of you who are familiar with GRC, you can see that the output language is something new. So, if you double click that, here you see the options block. So, this is where you put all the options that are specific for the flow graph globally. And you can see here, C++ is an option. That was just Python before. So, you can choose C++. You can disable the CMakeLists generation if you have your own CMake files, the CMakeLists, you can use that. You can also pass options to the CMake. And you can choose between dynamic and static linking. OK. So, two more blocks here. I haven't mentioned yet. It's the parameter block, which is command line parameters, standard with flags. And then you have the QtGui entry, which is just a tech line edit. So, you can just enter a value and it will change something. So, the entry block changes the frequency of the signal source here. And the parameter changes line width in the frequency sink, which is not exactly very useful, but it's OK if we're demonstrating. So, now we have this flow graph. We've saved it, then we generate it, pushing the button. OK. It says Generating. So, now we've created a new directory. And let's see what's inside there. OK. So, here we have the build directory, CMakeLists, and the source and header files. The build directory is empty for so long. But now we can press the execute button. There's CMake running. Now we have Make running. OK. So, this is generated completely right now from GRC in C++. OK. And now we can change the frequency here. We're at zero killer right now. So, you can set it to 3000. And then we see it changes both in the water full sink and frequency sink. So, it works. OK. And if we check the directory now, you can see that we have here the CMake files, and Make file, and the executable. And we can check if the executable is built to the debug info. And yes, it is. This can be changed by changing this, for example. So, you can add your own options there. Generate and Make. OK. So, now it's without debug symbols. The last thing I want to show you is this parameter here. CMake parameter. It says line width. And you can see here, you pass it as just width. So, if you go into the terminal again, you can try running demo for stem with the help flag. OK. So, we need to pass width. Let's pass 4. OK. And I will see the line width. It's significantly larger than last time I show you this. OK. That's all. Thanks. Any questions? Yeah. I can try. Can you please repeat the question? Yeah, sure. OK. So, the question is if I can compile the aesthetic. Honestly, I'm not sure if it works with QT. So, I'm clicking. But I'll see. Right. Current size. OK. 240. CMake. OK. Right. Yeah. That didn't work. I'm sorry. You need to install aesthetic vision. Yeah, sure. Yeah. That's right. Yes please. I do envision that all of this might also create a recursive filter. OK. So, the question is if I will be able to, in the future, I suppose, use feedback and, yeah, ignore radio. Bernst, I think that's out of my scope, really. I'm sure everything is possible if you spend enough time on it. Yeah. Can you just show the C++? I think that'll sort of clarify. Yeah. Sure. The answer is that it will generate C++ that looks a lot like the Python. It doesn't actually, like, put DSP into your C++. It doesn't standardize all the blocks. Because the schedule doesn't support the recursion like this for doing the same thing. Right. So, this is the header file. It's pretty short. Then we have the source file here. OK. Other questions? Yes? Can you just, not necessarily compile an executable, but show objects. Show objects? Yeah. To generate a program. Yes. But why not compile, generate a shell object.so? OK. All right. I see. So, the question is why not generate just the object and not the executable? I think you can pass arguments to CMake to do that, perhaps? I think so. Yeah. Yeah. I suppose, yeah. Yeah. Absolutely. Yes. OK. So the question is if I did some profiling to check the performance gains from Python to C++. No, I did not. Sorry. This is not a performance. Every block is written in C++ anyway. So, you're executing in the C++ world even when you're running in Python script. So, if you don't want to execute Python and want to manage your source code in a different way, but not a performance point. Sorry. Yes. How can people help you? You said you had this long list of things that you want to finish them. I mean, maybe you want to finish them all by yourself, but maybe you want people to help you. Is there any way that people can contribute code or anything like that? OK. The question is how can people help me making this better and finishing it? Yeah. Sure. People can translate blocks. I suppose the most interesting and helpful thing for me would be if people tested it. It's up on GitHub. It's my fork. Perhaps we should have a link somewhere. I don't, but I can fix that later in the slides. So, yeah. Please try it, clone it, download it, test it. It would be really helpful. Yes, please. My question is, are you planning to integrate cross compilation? Or will cross compilation be taken care of? OK. So, the first question is, is the objective of compiling into C++ to avoid having to use Python? Yes. That is my understanding. And the second question was? So, we have to cross compile. There is no target architecture in Europe. No, I haven't. The question was cross compiling. I haven't looked into that, sorry. I mean, the CMake will take care of that for you. Yeah. Yeah. It basically is you will just tell CMake to use the cross compiler and get a radio, have a tree module, stuff compiles, find that way. But Beth's opened the challenge of linking with the right average. That's not the C++. Does GRCC work with this? Can you run it on the command line, like trying to GSC file into C++ file? OK. The question is, if GRCC works? Yeah. I haven't tried it in a couple of months, but last time I did, it worked. Because GRCC in itself is a very small Python program, and it basically just uses all the GRC code. So every cross compiler is different, right? So what you would then do, I assume, is you would pull the GRC files into your compile chain, have a big CMake file that adds other parts of your project, pulls in the correct toolchain file, and then runs GRCC as an intermediate compilation step before generating your SOs or your ICQQs. So GRCC is just a command line interface to GRC, really. Conversation, if you had to circumvent having to do a lot of that hand mod stuff. If you're using kind of a, what's called a recipe from an OE-type system with a setup environment and all that, we could make it easier, I think, if you're using the standard approach. I could always just take the Python and copy it over and make my own C++ file. It's just that easy. But what we're trying to do is minimize as much work as possible to make this accessible for all these other platforms. I guess to solve all the possible problems, you would have to provide your own CMake template. I guess you have a CMake template that takes your SOs files and does all the rest. I'm not going to use the default template. I'm going to use this one that works across the other part. I like that we're having this discussion because we have some time to do so. We have five more minutes, if anyone wants to ask a question. Just out of curiosity, do you have a plan to support embedded Python in it? We have these embedded Python blocks and you could embed it to C++. OK, so the question is, do I plan to support embedded Python? C++ block ones, because he played around with LVM, was pretty happy. But I don't recommend doing that. It's not good personality and everyone knows more. Any more crazy ideas? By the way, this push to be able to generate C++ on the GRC was one of the reasons why I had a rule that no Python blocks were going into the new radio proper because I did not want to have those kinds of concerns or people did it accidentally. Sure. So if you're generating like a filter block and you generate the tabs, that's Python code if I get it right. The actual tabs is just a Python array. Have you tackled that? So the tabs, could you repeat the question? If you create tabs in a block, any engine. Like an array, you mean? Yeah. How do you translate that? Yeah, parameters. The question was, how do you translate Python arrays? In those fields. So if you have a parameter, if you put in a parameter block, sorry, a variable block, and you put an array as a value, it will be automatically translated to a C++ array. So that's how it is. What? Sorry? If you use the furthest notation, I haven't deleted that, sorry. How can you use health, because that's like a special case if you get a furthest object in the errors of C++ equivalent. But it's nothing that you can automate without the maintainer of that conversion and that's something that the first time someone uses that could actually implement that. If you use that code, contribute fixes, contribute back the cars. Yes. My answer was probably a little too fast. So that is true for furthest. Your question in a larger context is still true that there's still a lot of Python utilities that may not be accessible in this. I think that should probably just be tracked and converted over as much as possible to pure C implementation wrapped into Python for access there, but we're not leaving anything out of that. Okay. I think it's time to thank you. Thanks.