Transcript from 433: Getting Mad About Capes with Michael Gielda, Chris White, and Elecia White.

Welcome to Embedded. I am Elecia White, here with Christopher White. This week, well, this week it will be an engineering week. And I am excited to have Michael Gielda talk to us about Renode, which is something about testing hardware, software? Something.

CW (00:00:26):

Hey Michael. Welcome.

MG (00:00:28):

Hey, everyone.

EW (00:00:30):

Could you tell us about yourself as if we met at wherever we actually did meet?

MG (00:00:36):

Alright. So I'm Michael Gielda. I'm a co-founder of Antmicro and an open source enthusiast working with open source silicon software, hardware, you name it. Mostly these days I'm actually managing the company. But you can say I'm a manager during the day and an embedded developer at night, which is kind of pretty literal, because just tonight I was coding something. Yep.

EW (00:01:04):

We want to do lightning round, where we ask you short questions, and we want short answers. Are you ready?

MG (00:01:09):

Yeah, I guess so.

CW (00:01:11):

Favorite post-Halloween candy?

MG (00:01:15):

I didn't really celebrate Halloween too much, so I don't have a favorite. Sorry.

CW (00:01:20):

Favorite candy of any kind?

MG (00:01:23):

Any kind? I think that would be sour jelly beans.

EW (00:01:29):

Do you have a favorite Internet of Things connection method, Bluetooth, Zigbee, internet, Wi-Fi, et cetera?

MG (00:01:41):

I have a love-hate relationship with Bluetooth. I love it, but it doesn't always work. Wi-Fi probably ... , but it depends on what you mean by IoT, of course. 6LoWPAN is also kind of highly underappreciated.

CW (00:01:57):

Favorite microprocessor?

MG (00:01:59):

Some sort of RISC-V. It's hard to kind of decide which one though. I have a soft spot for the original FE310 from SiFive, the original kind of RISC-V MCU.

EW (00:02:13):

Favorite video game?

MG (00:02:14):

Tough one. Between Fallout and Baldur's Gate, I guess. It's a tie.

CW (00:02:20):

Which Fallout?

MG (00:02:22):

Well again, it's a tie between 1 and 2. Between 1 and 2, the original ones.

CW (00:02:28):

Yeah. Do you like to complete one project or start a dozen?

MG (00:02:34):

That's a very easy one. Start a dozen.

EW (00:02:37):

And do you have a tip everyone should know?

MG (00:02:39):

Plenty, but kind of a short one, yeah? I guess there's nobody out there to really kind of steal your ideas. So it's best to just talk about them because people are too busy doing their own thing, and if you don't talk to people about your ideas, they'll never learn about them.

EW (00:02:54):

That is so true. Okay, so let's talk about Renode, because I keep seeing it. And we talked to Jonathan Beri a little bit about the landscape of tools for developing embedded systems that are connected. But I go to your website, and it says it was created as a virtual development tool for multi-node embedded wireless, something, something, scalable workflow, something, something, secure IoT systems.

(00:03:30):

And I have to admit, it's a lot. Could you give it to me in terms that -

CW (00:03:38):

Explain it like we're five-year-olds.

EW (00:03:39):

Yes, thank you.

MG (00:03:43):

Okay. I can try. Well, if you're really a five-year-old, I have a five-year-old, so I produce a bit different language, but I know what you mean. Without prior experience, I guess it boils down to the fact that it helps you put your physical embedded devices into the virtual realm so you can develop on a PC instead of using the actual device, which doesn't seem like a big difference.

(00:04:07):

But once you try to scale developing methodologies across teams, across continents, across different kinds of devices, it turns out that developing software is much easier than developing hardware, because anyone with a computer can do anything.

(00:04:21):

And that's what a simulator at Renode will allow you to do. Instead of having to set up your entire physical device setup, you just start hacking right away. And you can also kind of share this environment with other people very easily without having to send them physical boards.

(00:04:37):

So that's why it's good for developing IoT systems. And of course the more complex your system, the more advantage you're going to get, because you're developing something very simple. Then obviously real hardware will definitely work for you very well. But once you get to this kind of scale, it becomes a bit of a challenge.

EW (00:04:59):

Other than Wokwi as a simulator, which I use for my class, which is all small problems, I haven't had a lot of good luck with simulators. They never quite do what the hardware does, and they're are a lot of work to set up. Sell me what you have.

MG (00:05:20):

Sure. I think the key to how Renode is kind of successful is that we're trying to make an open source framework that a lot of different people and companies and so on collaborate to develop. And in the end, of course, yes it takes time to set up simulation to model hardware and so on.

(00:05:40):

But then again, hardware is commoditized to a large extent. There's a lot of overlap. There's a lot reuse. So if the entire world kind of builds the simulation infrastructure for everybody else, it ends up being not so hard to build simulation.

(00:05:57):

And then even if you have the building blocks, you still have to put them together. That takes some work. But from my experience it definitely saves so much time in the longer run than the 10x kind of return there. So as long as you can kind of pool the resources to develop the actual models for the hardware, which we're doing, the setup and the use of simulators saves much more time than it takes.

EW (00:06:27):

So what kind of hardware are you supporting?

MG (00:06:30):

There's quite a lot. I would try to kind of mimic the real-life projects, or we don't even try to mimic, It just happens that the people that approach us have real problems to solve. So they are using whatever is being used on the market right now. So much of the support is oriented around Arm's platforms, which are of course extremely popular in the embedded market.

(00:06:52):

Cortex-M is of course very well-supported, but we have support for Cotex-A and are working on 64-bit advanced Cortex-A platforms right now. This will drastically improve in the coming months.

(00:07:06):

And of course we have very good coverage of RISC-V, because it's been one of the key focuses in the last few months ever since we joined the RISC-V Foundation as one of the very early members and got very involved in open source hardware. So RISC-V is kind of obvious, but Arm is also very important just because of the scale at which it is deployed. Other than that, there's some Spark. There is extensive support.

EW (00:07:35):

I'm going to interrupt you, because I don't really care about all of the processors, because all I ever use is a Cortex-M. I want to know, am I supposed to start with a Discovery board, or do I come in with my own custom board to start with? Since that part of simulation is so hard -

CW (00:07:56):

It's the peripherals.

MG (00:07:57):

Yeah. Yeah.

EW (00:07:57):

It's the peripherals that kill you, or the Cypress processor, it's just a pain in the neck to set up. So how are you supporting -

CW (00:08:05):

I just wouldn't.

EW (00:08:07):

- an FPGA plus -

CW (00:08:07):

I just wouldn't support that.

EW (00:08:09):

Well, yeah.

MG (00:08:11):

So that's the perfect question, because that's why Renode was born, right? That's how we kind of ended up doing it in the first place. We obviously started off with using QEMU as everyone would, right? So you want to similate a board, and that's the first thing that comes to your mind. Except that as you said, there's the whole world of peripherals that QEMU kind of tends to normally ignore, whereas if you're trying to actually run a real thing, you do have those peripherals to take care of, and the drivers to write, and the I/O to do.

(00:08:41):

So Renode was kind of born from that need where we were working on real hardware and wanted to model the hardware in its entirety. And so Renode actually kind of models all those peripherals. We have very good coverage of ST microcontrollers, and Nordic microcontrollers, and different vendors.

EW (00:09:03):

But what about SPI flashes?

MG (00:09:05):

We have some too.

CW (00:09:08):

Oh, you're talking about external things to the microcontroller.

EW (00:09:10):

I mean, it doesn't do me any good to have an STM32F4 whatever if I can't also connect it to -

CW (00:09:18):

A display.

EW (00:09:19):

- a display, and a SPI flash, and an ADC, and all of the other things that actually make up my system. My processor is -

CW (00:09:27):

Boring.

EW (00:09:28):

- boring, actually. Yeah. I mean, it's super important, but overall, that's just the application. That isn't the embedded system.

MG (00:09:37):

But Renode does have display support as an example, right? So when you're mentioning STM32, that's one of the original ones where we actually did implement a display controller, an accelerator. And you can actually run a GUI inside of Renode for STM32.

EW (00:09:53):

So do you need an RTOS, or do you support CubeMX? How does that actually work out?

MG (00:10:01):

It's completely software agnostic. So you can run CubeMX binaries. You can run Zephyr. You can run FreeRTOS, whatever you want. It doesn't rely on any specific payload. It tries to mimic the hardware to the point that the payload doesn't really understand it's being run in simulation. So it can be anything.

EW (00:10:20):

So I'm actually compiling in my normal environment and programming, JTAGing, flash updating onto your virtual devices.

MG (00:10:32):

Except you're not really flash updating -

EW (00:10:34):

Right.

MG (00:10:34):

- in the sense that you're just uploading a binary to replace memory on your PC. So it's kind of faster and easier, but yeah, the flow is kind of the same.

EW (00:10:44):

And if you don't have a peripheral that I need, can I write one?

MG (00:10:50):

Of course. We absolutely accept contributions, and people have been contributing things. And of course we also do it as a service. So there's choices there. The one thing that perhaps is important to mention is that we actually have infrastructure that allows you to model a single peripheral and bolt it on top of Renode without having to recompile the whole thing.

(00:11:12):

So we've built it so that if you have one additional thing you need to model, you can create it as an external file, and just load it in runtime. And it's going to work the same as if you compiled it in directly into the core of the framework.

(00:11:25):

And over time what happens is that people might build those things in isolation, or even we might do that. And then once the peripheral's kind of developed enough, we can kind of wrap it back into the core framework to be available to everyone. But you don't need to start with digging into Renode's internals to model a single piece of IP inside a chip or outside of a chip, of course.

EW (00:11:50):

So let's say I have a device that has a complicated ADC system that I'm not going to be able to reproduce, because it has to do with physical world. Do I replace that with a data file, comma separated file, that every time I sample? How does that work?

MG (00:12:11):

You're absolutely correct. I mean, there's many ways you could solve this, Because of course, you could imagine connecting not a file, but perhaps another program that supplies the data, which we could also do. But yeah, a file is the most obvious choice. And in fact, historically it would just be a very simple data file that we supported.

(00:12:31):

Right now we've actually created a more complicated, advanced format for supplying multiple-sensor data at the same time. And this is because we we're having more and more scenarios where we're kind of getting multiple sensors going at the same time, and the application perhaps processes the data, and makes some decisions based on several data sources.

(00:12:54):

So we've designed a format that allows us to do this more fine-grained and have better control of how this data is being fed into asimulation. But yeah, it's a file in the end.

EW (00:13:05):

And then what about timing? On one hand, I can see that having a simulator run fast is so much easier to debug, because I don't have to wait for Tuesdays at midnight or whenever my system is having problems. But on the other hand, some of my bugs are timing. So do you run realtime or not?

MG (00:13:22):

So obviously hardware is not the same as simulation. And if you're kind of looking for really tricky timing bugs, that's one of the things that perhaps needs to be said. We don't tell people not to test in hardware, right?

(00:13:36):

We believe that hardware is extremely important, and you need to test with hardware in the loop, except that we also believe that 90% of the bugs you can catch with a simulator and then you're only left with 10% that are really tied to those tricky timing problems, whereas the rest is other kinds of timing problems, or logical errors, or bugs that Renode can actually help you with.

(00:13:59):

So when it comes to the question, whether it's realtime, in the sense of the user experience, yes. In the sense of how do we approach time, it's deterministic so that we kind of synchronize, for example, if we run multi-node systems, we will synchronize them together. We're not just running as fast as we can. We're kind of taking time to ensure the determinism.

(00:14:24):

But at the same time, if you do want to let go of determinism and just run as fast as you possibly can, that's a feature. You can also just turn off the determinism and run faster, which is very useful for some scenarios. It depends on what people need. But there's a lot of kind of tweaks you could do in the timing space that will allow you to adapt Renode's to different kinds of scenarios in terms of what you want to achieve in your testing.

CW (00:14:52):

I could definitely see a case for, "I'd like to run as fast as possible," maybe with determinism still on, but there are those cases of bugs where it's like, "Oh, this happens once a week."

MG (00:15:06):

That's a very, very kind of good thing that you're raising here, because that's another way to look at time, in which, yeah, real-time is really real-time. If a bug happens every week, then you have to wait a week for it to trigger. In Renode's or generally speaking simulation, you'll have many ways to solve this. You can even record and replay these kind of scenarios.

(00:15:26):

You can compress time. If your device sleeps a lot, then you don't need to really kind of wait for it to sleep, you can just skip until something interesting happens. So there's kind of a bunch of features there that allow you to manipulate time, let's call it, and go back. You can record, you can save games like you would do in a game. You can save the state of the entire simulation and load it later. You can record and replay events.

(00:16:02):

So you can imagine a big system where you're trying to focus on a single node in that system, and you only care about what happens to that node. You don't want to simulate the entire system, because it's big, and slow, and it takes a lot of time.

(00:16:16):

But if you just kind of simulate it once and record the events, you can take those events, you can save them and you can replay them into that single node. And from then on you can actually focus on the single node. You can just simulate a single node, which is much, much faster and just replay the events as they happened. And so trigger bugs that normally you'd have to have a huge simulation or a huge physical setup and perhaps wait for a long time, you could now possibly trigger in minutes.

EW (00:16:47):

What about all the times I need to work with Bluetooth or servers to connect to. Let's go with servers, let's go with just Wi-Fi, because that's a simpler case. Let's say my device is a sensor that needs to send data to a AWS instantiation, and I want to be able to test this all the way with my application people who are getting the stuff off of the AWS server. Can I do that?

MG (00:17:21):

Yep. Yeah, yeah. You can absolutely do this. And we've done this. Obviously the server's expecting a real device, right, so it might have some kind of quirks you have to adapt to in terms of how you talk to it.

(00:17:34):

But generally speaking, with bridge networks the virtual and physical world, also the context of sending data to the cloud, one thing that perhaps you have to make sure you understand is that determinism cannot really be guaranteed in that regard, because you're bridging into the real world. Once you do that, you kind of lose the guarantee of determinism. But you know can definitely do this. And we've done this. It's definitely possible.

EW (00:18:03):

And Bluetooth, can I integrate with an iPhone app?

MG (00:18:10):

That's a very common question too. And the answer is you absolutely can. We haven't done much of this yet. We are kind of looking at this right now. We've mostly been focused on simulated networks, so internally in Renode you can make a Bluetooth connection between nodes and talk between them.

(00:18:28):

But talking to your phone is absolutely doable. We've had a lot of people ask about that use case, right, but then it boils down to actual customers that are building these kind of systems and testing these kind of problems. So I think we we're going to be doing this very soon, because we have a few also vendors that we're working with directly and that's an interesting topic for them to explore as well.

EW (00:18:56):

And you mentioned multi-nodes, which is one of the places that this gets really interesting for me because sometimes, I mean we talk about the Internet of Things, but it used to be called distributed systems and sometimes that meant a lot of systems. For example, sprinkling sensors around a city and having them all work together to get more information, but then that leads to lots of other problems including timing and staying in sync. But also they have to communicate in the real world, which sometimes is very hard. Do you model the network issues?

MG (00:19:43):

That's another question that pops up very often. And of course, we've given some thought where there is some level to which you know might want to care about the physicality of things, but we're not aiming to model the entire world, because that's just a lot of compute. We're focusing on the results of what happens when communication fails.

(00:20:04):

And we can actually have models of the radio medium between the nodes, which either can be a perfect medium, and then of course all the packets always get through. But you could also put nodes in physical virtual locations that are kind of at some distance and then have some kind of a distance-based radio model which drops packets every now and then the further you are.

(00:20:34):

So you can have various kind of ways in which the connection quality can be represented as being poor. ... We're not simulating physical walls or something. We're not trying to model the physics of how the particles, actually, or the waves behave.

EW (00:20:52):

Yeah.

MG (00:20:52):

But we are kind of simulating the result of a failed communication. And then when communication fails, what happens? Does your protocol handle this retransmission well, and these kind of things that can be simulated. And in fact, that's kind of one of the key focuses really when people talk about wireless networks is they want to test what happens if things go wrong, not if they work well.

CW (00:21:19):

So you can go in and say, "I want to stochastically drop 15% of packets or corrupt some percentage randomly," that kind of thing.

MG (00:21:28):

Absolutely.

CW (00:21:29):

Okay.

MG (00:21:29):

Yeah, and you could even introduce some more intricate corruptions. If the kind of things to look out for, you can break the packets in ways that you know. Because you can just drop packets, for example. And then of course dropping is very binary. But if you wanted to, let's say, malform packets or something, you could also think of writing a simple script that just mangles them a little bit and then you see how your protocol is handling this.

EW (00:21:58):

At what point do I start looking at Renode? I mean, is this -

CW (00:22:04):

At what point in the development cycle?

EW (00:22:06):

At what point in the development cycle and then at what complexity of device?

MG (00:22:13):

I would say that it depends a bit, of course, but pretty early on. We try to encourage people to try to do things early on. It's going to be easy to scale them out once you're trying to build a more complex system. So definitely even starting with a single device like a 32-bit Cortex-M MCU with two sensors on it, there's already kind of usefulness in using Renode.

(00:22:39):

Having said that, I think it's a different place for different people, where some people love tests and they kind of want to get everything tested, or perhaps the company they're working for is requiring that, or likes to have that. And then you should start very early.

(00:22:54):

And there are other people who perhaps prefer to set up testing once they're more comfortable with what they want to do. I mean, Renode can also be used for prototyping. So we're talking about testing a lot, because it's one of the key use cases, but prototyping and just picking the hardware they want to work with is another aspect that we're trying to target.

(00:23:16):

So I would encourage everyone to try to introduce Renode into their workflow very early. But on the other hand, it's, I think, best if you introduce it at the moment when you're comfortable with fusing it and you feel there's a real need.

EW (00:23:30):

And what about complexity?

MG (00:23:32):

You mean of using Renode itself or - ?

EW (00:23:35):

Well, there are gonna be projects that don't need Renode, because they're too simple, or don't need Renode, because they're too complex and setting up the simulation is as much work as doing the project.

MG (00:23:50):

Well, perhaps. Yeah, definitely on the simplicity of the things, absolutely. You don't need to set up simulation every time you try to blink an LED, right? But on the other end of the complexity spectrum, I mean, I can envision projects that are kind of complex enough that is just a lot of work to simulate them.

(00:24:06):

But over time we're actually trying to through, again, pulling the resources, making the framework open source, we want to be able to simulate really complex systems, without having to put in a lot of work.

(00:24:19):

And so ... ideally we can also target the complex side of the spectrum without the actual act of setting up simulation being complex in itself. But I totally agree and in terms of, yeah, if you're just building something very simple, you might just not need Renode, and that's fine.

CW (00:24:40):

And it seems like there's cases where even if your system was daunting, or too complex, or felt like it was too complex to simulate at one go, you could certainly break it into subsystems.

EW (00:24:53):

Yes.

MG (00:24:53):

Yep. That's a great thought. Yep.

EW (00:24:55):

Okay, so I have a project coming up that is starting out as an STM32 Nucleo board, and an inertial measurement device, and a couple of pumps and sensors. So I have inputs and outputs. Where do I start? I mean, the hardware is not yet on my desk. Right now, I'm still sketching out where everything should go in the prototype and talking to the EE to find out which pumps need what kind of special handling. What do I do?

MG (00:25:36):

Well, I mean first you should probably match whatever components you're planning to use at least.

EW (00:25:43):

Before that, I go to the Renode website, and I push download Docker?

MG (00:25:52):

I mean that's what I was meaning by before. Okay, you should download Renode for sure, right? But doing some research before doing that actually helps, in the sense that you're mentioning a specific project, right? You already have something on your mind. You're trying to use it in a specific scenario. So certainly downloading Renode and just playing around with the demos we have and we have lots of them, because over time they've accumulated, and there's dozens.

(00:26:18):

And then there's the Renodepedia effort, which kind of covers hundreds, and well, actually thousands of demos. So definitely that would help to get a feeling for what Renode can do. But in terms of actually, how can Renode be useful for your particular project, it's always good to kind of research a little bit whether the hardware you're trying to use is kind of at least nominally supported, right?

(00:26:41):

Because if you pick something that's completely different than what we have, then you'll just find it harder to adapt Renode to your needs, whereas if you pick a board that we have a demo for, that's kind of what I was trying to lead with, if you find that we actually have a specific demo for the exact word that you want to run, let's say, that's obviously the best place to start, right? Because you can literally go run the demo, and I'll tell you how to do it in a second and just replace the binary with your own.

(00:27:18):

And of course if you start using hardware features that are not there, say a sensor that you want to connect isn't there, then of course you have to do some work to add it. But just being able to run your own binary on the approximate platform that you're going to aim for is a very powerful experience that I really encourage everyone to try out.

(00:27:42):

And so coming back to how to approach this problem, I would really first try to see if normally that platform is supported, and if I had some confirmation that, "Okay, something similar to what I want is there," then I'd go and download Renode and try to run that demo.

(00:27:59):

I could run any random demo, of course, and that's also fine, because it shows you the capabilities of the framework, but especially cool if you can actually compile a binary that's like "Hello, World!" which is the starting point you'd also do if you were trying to run the real hardware, right? You'd also compile a "Hello, World!" first. You wouldn't build the entire application.

(00:28:22):

You would start with something very simple. And once you have that simple thing, and you run it in a simulator, you can realize, "Okay, that's already something. I can build a test." And of course it gets harder as you try to introduce more complexity into the flow, but that kind of experience is very powerful. So yeah, download Renode is of course one of the important steps and you can do it, do it for any platform like Mac, and Linux, and Windows PC. And we have portable packages for Linux, which is the best starting point for Linux people.

(00:29:05):

We're actually working on having portable packages for all three operating systems, but installing on Windows and on Mac are not hard. These are just an XZ file, a regular installer on Windows, and DMG on Mac, and on Linux you have the portable package. So on all three OSes you have a fairly simple choice how to install note or of course, yeah, you can try Docker too. We have docker images so if you're more into that kind of way of working, then Docker is your friend.

(00:29:37):

But of course then you might run into some issues with setting up where are your files and how to find them on your drive and stuff. So installing Renode natively, for me at least, I'm the kind of person who would probably just go and install it. But yeah, Docker's available too.

EW (00:29:56):

I am desperately not the person who just goes and installs stuff on my computer.

CW (00:30:00):

Really? I just grab stuff.

EW (00:30:03):

As he was saying about looking for tutorials. I found one that had a Colab, which is the absolute best way to get me to try things.

MG (00:30:10):

Oh, yeah. Colab. Right. Yeah.

EW (00:30:15):

Although trying to figure out what this Colab does, while I'm also trying to figure out how to do a podcast -

CW (00:30:18):

While you're also doing a podcast, yeah. You might be multitasking too much.

EW (00:30:23):

This is incomprehensible, but that's probably because I can't do both.

CW (00:30:28):

I have a question about the demos. So if I grab one of the demos for some STM32, does that include a Cube project? Is it a fully fledged demo that I can just drop into the IDE as well and build for, or is it a demo that's just defining the board and stuff?

MG (00:30:48):

That's such a fantastic question, yeah. And that's a big struggle, because we're building a simulator, and at the same time, of course, in some sense we're building all the embedded software in the world, -

CW (00:30:58):

Right.

MG (00:30:58):

-because we have to have demos and stuff. So historically how we approached this was, we'd provide binary demos ... All this Renode stuff would be, of course open, and then you'd have a compiled binary, just because explaining to people how to also go and compile the actual binary is 10 times the amount work rather than getting them to install Renode.

(00:31:25):

So what we have in Renode is a bunch of scripts that you can just install Renode. You run it. You type one line. Essentially it's just start and the name of the file with the demo, the script, that's the entry point to the demo. And then what the script does, it actually downloads the binary from our servers and it runs it in simulation. And if you want to put your own binary there, you just, -

CW (00:31:51):

Oh, okay.

MG (00:31:52):

- in the script, you change one line, and here you go. So we don't provide CubeMX projects and stuff, not because we couldn't, it's just a huge endeavor -

CW (00:32:01):

Yeah. Yeah.

MG (00:32:01):

- to try and provide other people's demos. Actually, demos from ST or someone else should work, right? And so we provide those compiled binaries because they're this instant success thing. And then once this works for you, well, just replace the binary, and run something else, and see what happens. But there's this one endeavor that we'd kind of embarked upon throughout the last year, which is called Renodepedia, or earlier the Renode Zephyr dashboard. That's the origin origin of it.

(00:32:34):

And Renode Zephyr dashboard is actually building hundreds of Zephyr RTOS binaries from source, right? So you can trace back the sources directly, compiling them, running them in Renode seeing if it works. It's also automatically generating all the Renode files, because Reno has those building blocks. There's this CPU models. There's I/O models, different sensors, and so on.

(00:33:00):

These are kind of building blocks from which you have to assemble a platform. Fortunately Zephyr has device trees which describe what's connected where. So we can take that data, we can generate the Renode description files called repl, Renode platform files as we call them.

(00:33:16):

And so generating it all together gives us the ability to test Zephyr binaries at scale. And there, if you want to actually reproduce the entire thing, it's trivial, because we give you Colabs that kind of show you how to build that kind of binary and a lot of infrastructure that you can just trace back directly to the sources. So for Zephyr, it's been pretty simple, because Zephyr's well structured. iI's easy to generate different kinds of binaries for different kinds of targets, right?

(00:33:47):

And of course it scales across different vendors, even different architectures, RISC V, Arm and so on. So it has a good coverage of the entire ecosystem, but you could imagine similar efforts for other operating systems, or CubeMX, or something. It's just a matter of, there's some work involved in actually setting up the compilation and testing infrastructure to make sure those demos actually work.

(00:34:16):

So the Zephyr dashboard has been the biggest such endeavor from us and perhaps in a sense worldwide. I'm not claiming it's the biggest such thing, but definitely one of the bigger and more ambitious projects that I think if you're into, "Where do I get a demo that I can actually reproduce end to end," Zephyr dashboard is a great place to start.

EW (00:34:42):

Okay, well I was going to add to that about CS bus and CPU zero, but I think you've covered all of that. So we have some listener questions. From Benny, "Is there a guide for Dockerizing Renode for CI continuous integration or other larger scale use cases?"

MG (00:35:06):

As mentioned, there's Docker images available and basically we even have GitHub Action with Renode where you literally just have to submit several variables and Renode's just there in a Docker image prepared for you. So absolutely, yes. There isn't a dedicated guide for Dockerizing Renode, because it has been Dockerized. But if you want to learn how you can just go and look at the Dockerfile of the Renode Docker, and you can just make your own if you need a special image with Rednode.

(00:35:42):

But I guess if you don't want to recompile Renode, and we're trying to make the framework so that few people have to really recompile it, right? It's really people that want to do some hardcore development and develop some inner interfaces. But if you're just going to use it, if you're just going to add a little bit of stuff on top of it, then the portable release for Linux or whatever other installation that we have is enough, meaning that you grab a Vanilla Docker image, and you can just install Renode on it. And there you have Dockerized Renode.

EW (00:36:22):

And right now I can type at my device as if I was at the debug port that I have usually connected to my computer through an FTDI cable.

MG (00:36:34):

That should feel pretty familiar, where in the end, what you see is the window, right? There is a physical port. You can see the cable, but ultimately how you really experience your board is through this UART. And we just open a window, and we show you the signs, and you can type stuff and interact with the board. I think that's another topic, so perhaps I'll stop here, but exactly. The virtual UART is kind of the first point of contact with, Renode I would say.

EW (00:37:06):

Benny wanted to know if it's possible to do SocketCAN.

CW (00:37:10):

Why would anybody want to do CAN? Sorry,

EW (00:37:12):

Yeah. That was -

CW (00:37:14):

Having a bad CAN week.

MG (00:37:17):

Well, yeah, yeah, true that. But I guess the automotive guys wouldn't agree, and there's a lot of CAN use out there in robotics and so on. And we've done virtual CAN setups. We haven't used SocketCAN. We haven't bridged with real physical kind of CAN connections from Renode.

(00:37:36):

But this is absolutely possible. We have not, just because I think someone mentioned we have virtual UARTs that we can also bridge into the real world, but we also you can bridge the Ethernet networking as well and generally networking. So you can have host-guest interactions of different kinds. CAN would absolutely be possible. It isn't there right now, but I think it'll come at some point when someone has a real use case where they need to talk to a physical CAN-connected device. Then we'll just have to implement that.

EW (00:38:14):

Jonathan suggested I ask about Pokédex for Zephyr boards. Is this Pokémon?

MG (00:38:18):

Yeah, I love that question. Pokédex is how you kind of look up all the Pokémon in the Pokémon world. I love the analogy where Renodepedia, the framework I was talking about, is kind of like this, except not for Pokémon, but for actual real hardware. The Renodepedia is kind of an effort to try to showcase how much diversity there is in hardware. It's a nice encyclopedia, basically.

(00:38:50):

You can also think of it, the inspiration for doing Renodepedia in the first place was UFOpaedia from X-COM, the X-COM games, where you'd go and get lost in the lore of the game. You'd get into this mindset where you're really kind of interacting with this world and looking up all the alien species, and weapons, and whatever you have in that game.

(00:39:13):

And at least, and I think there are people like me as well, could spend hours just browsing and just reading all those descriptions and flavor texts and comparing different parameters of different, I don't know, weapons. I guess, engineers, many at least, have this kind of mind where they just these kind of things.

(00:39:34):

And of course ... perhaps in the game, it isn't very practical, you just want to win the game. But in real life, when you're trying to document all the world's hardware, to trying to see what they're comprised of, what kinds of relationships between different pieces of hardware there. This actually becomes useful. This kind of data set where you try to take this hardware apart and take a look at, "What is this SoC? How is this SOC related to the other SOCs? What kind of IP logs come into this SoC and make it what it is?"

(00:40:09):

"How are these boards related together? Why is this Ethernet controller appearing in a bunch of RISC-V and Arm boards?" And not even just Arm Cortex-M, but perhaps Cortex-A. This is a fascinating story. You start seeing how the sausage is made, how the hardware is really composed of building blocks that ultimately are much like software components.

(00:40:32):

When we're building software, we're using libraries. Similarly, when people are building chips, they're using IP cores, libraries of sorts. And so uncovering that complexity, and showcasing it for the world, and trying to reason about it in a structured way is a fascinating story to tell, I think. And we're just getting started, because Renodepedia is there. It's full of stuff, but there's plenty more to be shown and said.

EW (00:41:01):

Do you have any questions for us before we move on to RISC-V?

MG (00:41:07):

I mean, I guess I had the question whether you'd actually used Renode ever. And I guess the question was more like, you haven't earlier, but you've just started experiencing it, right?

EW (00:41:20):

Exactly. I ran my first Renode thing, widget, Renode, node, during this podcast.

MG (00:41:31):

So the answer's both yes and no.

EW (00:41:34):

You haven't entirely convinced me. I mean, I'll go off and parse -

CW (00:41:37):

To be fair, you're difficult to convince.

EW (00:41:39):

I am very difficult to convince. I mean, I need to go read a manual on, oh God, AT commands, but also I need to go read a modem manual for different things, and then I need to go work on a CAN bus thing, and -

CW (00:42:00):

You don't need to.

EW (00:42:02):

Well, but I will. And then I have a device that's getting closer to production, and has a bunch of sensors, and a bunch of code, and Bluetooth communications. And none of these would I immediately jump to Renode for.

CW (00:42:20):

But you're a consultant.

EW (00:42:21):

But I'm a consultant, which means that I would have to get somebody to pay me to want to do this, -

CW (00:42:25):

Yes.

EW (00:42:25):

- which means that I would have to be familiar enough with this and convinced enough with it that I demand that they do that. And I'm not there.

CW (00:42:34):

This is why I'm saying you're a difficult target.

(00:42:35):

I'm super hard to convince. And the list of to-be-read manuals is so long, that I look at this tutorial, and I see a couple of things I can probably work out, but it would take me a solid eight hours to figure out how to make Renode useful to my clients. And if at the end of that eight hours I couldn't, then that's billable time wasted. So yeah, I mean I can see how it would be useful.

MG (00:43:09):

No, I mean, definitely the thing with open source is that that's why I kind of running a company that does open source, because I'm not really trying to tell everyone, "Oh, this is the best. You have to buy it," right? It's just, it's out there. So you might not be convinced right now. Sometime we'll pass.

(00:43:26):

And we've seen that a lot of times where we've had interactions with people throughout the years, and they've perhaps gone from being like, "What is this? Why do I need this," to being absolute zealots about it. And we've had other people who never became convinced, right? And that's also fine, because it's just open source. You can just grab it and use it, but you don't have to interact with us to try it out. Of course, we try to make the documentation better and better, but there's never enough time.

(00:43:59):

So definitely constructive criticism in terms of how easy it is to set up is always welcome. And I think we should for sure work hard to expose the coolness of Renode. Renodepedia is one of those efforts. But it's definitely just one thing, so that people get the point easier. They're more grasped by the immediate benefits.

(00:44:23):

And it's fine for some people to never actually be in the position where Renode helps them, because it totally depends on your station in life and your way of working, your clients. So yeah, it's perfectly fine not to want to use Renode, especially at the specific point or in a specific project.

(00:44:46):

I think that the sweet spot is when some scales, they start to appear, and have to work with more people, and coordinate between them, and hardware suddenly starts being more of a pain than this nice shiny thing on a desk that you like to play around with. So we see a lot of bigger clients approaching us and then saying, "Oh yeah, I have, I have many development teams working together. How do I make them collaborate more effectively?" And that's where Renode really comes in.

CW (00:45:19):

Yeah, I think our situation is weird, because we're often coming into small clients at the mid-to-late development stage, and everything's a panic. So it's very difficult to say, "Oh, you need to take a step back and simulate everything."

MG (00:45:35):

Yeah. Although I absolutely understand this viewpoint, because this has happened to us many times before as well. And in those cases it's probably not a good idea to go and try to push people to do something they aren't used to doing and so on. So, yeah.

CW (00:45:48):

But what I was going to say was projecting backwards in my career, if I had had this at various other times, I would've been over the moon. Because we tried this at Fitbit, but nothing existed. So some people tried to do a QEMU thing from scratch, and it never really went anywhere, because it was too difficult. And if we'd had this at Fitbit, it would've gotten a ton of use.

MG (00:46:10):

Yeah.

CW (00:46:10):

Because we really needed CI stuff to work at scale on devices. I mean, we had just horrible racks of Mac minis and stuff attached to watches. I think we had cameras at one point. We had all kinds of Frankenstein's monsters to try to get device testing to scale.

MG (00:46:31):

And we work with clients like that.

CW (00:46:34):

Yeah.

MG (00:46:34):

Exactly. And then I can tell you a story, we'd actually talked to the Pebble guys, before they were acquired by Fitbit, right? And we just talked to them a little bit too late and the conversation never matured before they were acquired. But you can imagine a parallel universe in which we'd reached out to them a year earlier and we'd been using Renode when Renode Fitbit acquired Pebble.So I totally agree. Probably these kind of clients and use cases are where people are throwing an insane amount of resources on testing anyway.

CW (00:47:10):

Right. Yeah.

MG (00:47:10):

But because testing with real hardware is hard, hard, they're kind of wasting time and money most of the time. That's where Renode is especially handy.

CW (00:47:19):

And I think if I was starting a project of my own from scratch, I'm not that into figuring out the hardware. If I have an application idea, and I want to play with it and prototype, I'm more inclined these days to try to do something in software than to grab a board and get upset at the board. So if I were to start my own project, something like Renode would be somewhere I would look to get that first few months of, "Okay, let's play around with this."

MG (00:47:48):

I hear this.

EW (00:47:49):

The other piece that I would like to use it for, but I'm not sure yet is, I teach a class about embedded systems, and we send students boards and for the most part, they all get the same board. And one of them was a Nucleo board that is on the Renodepedia. ... I have a few things in Wokwi that are part of their exercises so that they can have code that they know runs, and can walk through, and all of that. But I don't know how I would put Renode in that without making it a whole chapter. I mean Wokwi is like, "Here, go play with this." But Renode would it require at least a lecture and not just a hand wave?

MG (00:48:53):

Yeah, I mean Wokwi is a great idea where it runs in the browser, so you can play around with it very easily. And certainly that kind of experience is something we want to kind of move towards as much as we can. I would say that playing around with things in Renode doesn't necessarily have to be a full lecture, but sure, if you wanted to kind of get out all the advantages, it becomes more than a lecture. But the Colab stuff, as an example, is something you can try out without any prior experience. So it's more a matter of the fact that what Wokwi also has this kind of visual -

EW (00:49:34):

Yeah.

MG (00:49:34):

- editor that allows you to build this kind of nice connected setup. But that is something you could do in Renode too. It's just that we had a few approaches to this kind of thing. It's fundamentally not trivial to do it well, -

EW (00:49:55):

No.

MG (00:49:55):

- especially for multi-node systems because of course if you just say, "Okay, I want to focus on a single node," and you make some simplifications, then of course it becomes easier. And if you wanted to, for example, specifically focus on the education space, I think you could do a great job, and Wokwi does a great job, right? But the thing is that we work with pretty complex use cases with clients that have multi-node systems and stuff. And just visualizing this and making it possible to work with this graphically is so hard. We've tried.

(00:50:27):

So we've always fallen back to making sure we have a good API, we have a good textual command line driven flow, and then on top of that you can build any sort of cool visualization or visual system. And we definitely want to do more of this. And as the framework grows bigger, as the team gets bigger and so on, that's an obvious direction, but it is just not something you can easily do and make everyone happy, right?

EW (00:50:57):

No, you really can't. And if you are making everyone happy, you're probably not actually getting anything done.

CW (00:51:02):

You're lying.

EW (00:51:03):

Exactly. Someone's lying.

CW (00:51:07):

Yeah, no, I mean, things like Renode seem to be kind of a holy grail in my mind, this shining thing on the hill that everybody wants to have. But the reality of the embedded systems world is such complexity that you have that trade-off. Either we meet the complexity with something that can handle it and is therefore complex, or we simplify things, and you can't do some stuff.

EW (00:51:34):

Exactly.

CW (00:51:35):

Yeah.

MG (00:51:36):

You end up looking for a sweet spot, and I guess it's everywhere in life and in all of engineering, right? There's holy grails. You want to aim high, but you can never really do a hundred percent of what you'd assumed initially.

CW (00:51:50):

Yeah.

MG (00:51:50):

And that's fine. And Renode helps a lot of people. And as I said earlier, it's not going to help everyone do everything. We're trying to take the burden off.

CW (00:52:00):

Yeah.

MG (00:52:00):

Even in the testing when people ask, "Should I test in hardware? Should I test in Renode?" We say, "Look, you should do both," right? I mean, it's just that in Renode you're going to be able to quite easily test a lot of things that would be hard to test in hardware. That saves a lot of time. And then once you've saved that time, you can devote that time to other things or perhaps to testing in hardware better, right, the stuff to you really need to test in hardware. So it's all about the correct or optimal way of working, really.

EW (00:52:28):

But you said both, and I'm like, "Okay, just doubled my testing." But I know where he is coming from, that the Renode version of testing would be much easier to debug and much easier to make more complex instead of the simple testing I would get in a lab. But when he said, "You have to do both," I'm like, "No."

CW (00:52:47):

Well, when I hear somebody say that, I hear, "Okay, you can do your continuous integration testing in Renode."

EW (00:52:52):

Yeah.

CW (00:52:52):

And you wouldn't want to do your user testing in Renode unless it was something that you could do that with. But if you had a wearable, that's obviously not going to work. So you have to partition the types of testing that are appropriate for your system.

EW (00:53:04):

Yes.

MG (00:53:05):

Yeah, that's what I meant. And of course, you can even take some of the user testing and some stuff that the users have detected, they're trying to input stuff and things are not working. You could actually try to record and replay these kind of events. So mixing up real testing with virtual testing is actually pretty cool if you have a good understanding of what are the strengths and weaknesses of both approaches.

(00:53:27):

But I agree, typically it's just different kinds of testing that will happen in the virtual versus the physical world. And certainly I'm talking about deployments of thousands or at least hundreds of units. I'm not talking about a hobby project where you don't really need to do so much testing or just very small deployments where you could literally imagine someone going and testing things manually -

CW (00:53:51):

Yeah.

MG (00:53:51):

- because there's just five things.

EW (00:53:53):

So RISC-V, you mentioned that earlier. How are you involved with it?

MG (00:54:00):

Well, quite deeply in the sense that we've been around since the very beginning of RISC-V. I mean, not the very beginning, that's obviously Berkeley, but the beginning of the foundation, 2014, '15, we got involved early. We kind of started building some first RISC-V implementations. We worked with SiFive, we worked with Microchip that built the first mass market SoC on RISC-V with a lot of RISC-V clients.

(00:54:26):

And we are also very active in the entire ecosystem, not just RISC-V itself, because RISC-V itself is actually going well, and you don't really need to push it very hard for it to be successful. You can already see it being very successful, but there's this entire ecosystem of open hardware around RISC-V. Open source implementations of RISC-V, that's one thing. But I mean all the other building blocks of an ASIC or all the tools that go into making an ASIC, all this we believe will eventually be open source, just like in software, everything is pretty much open source.

(00:55:03):

And of course you have proprietary icings on top very often, but most of the world's software is built from open source building blocks with open source tools. And the same goes with hardware we believe, just in the longer timeframe. So RISC-V is definitely a key focus and something we're very deeply involved with. I myself am the marketing chair for the CHIPS Alliance, which is this group that's building all these open source hardware building blocks and tools for hardware.

(00:55:33):

So we spend a lot of our time also, for example, in Europe. The EU is putting out requests. "Can the industry tell us what needs to happen for Europe to be competitive in terms of semiconductors?" And so we'd typically be part of these kind of groups that would say, "Hey, Europe needs to do more open source," or, "The U.S. needs to do more open source." Anyone that wants to be competitive needs to kind of use RISC-V, needs to do open source hardware to stay relevant. That's our belief.

EW (00:56:07):

I remember quite clearly when we didn't all run open source compilers, -

MG (00:56:13):

Yep.

EW (00:56:13):

- when we had to pay for every compiler, not just for the special ones that work on a particular processor.

MG (00:56:20):

Absolutely. And that changed, and that's how the world is. It needs to change, because it's not just about the money, right? It's about having to ask for permission. If you want to do something, and before you do it, you have to ask people for permission, you're just not going to do it. If you're the kind of person that I am, you're just going to go somewhere else.

(00:56:44):

People from hardware, they will very often just go and start doing AI or web development, because hardware is just too proprietary. And there's too many walls, and people stop caring. And people are complaining a lot, "Oh, why are people not going to study hardware, and why are they not taking up those kind of difficult topics?"

(00:57:09):

And part of the reason, I'm not saying it's the entire reason, I think part of the reason is that if you have a choice between, "I grab a laptop. I just grab a bunch of front-end software libraries and so on, and then just build things. I can have a result in five minutes," versus embedded, where you have to do a lot of hand waving to even get started, it's just not the physicality of the world.

(00:57:37):

That's the one thing we're trying to solve at Renode, but it's also about the licenses and the obscurity that, if that was different, I think it would be much easier to attract new talent to focus on hardware rather than other areas.

EW (00:57:56):

But because it is open source, what happens if it gets too fragmented? What happens if every vendor adds their own custom instructions?

MG (00:58:10):

That question's, of course, very popular in the RISC-V world. And the answer is, you have to make RISC-V so relevant and the foundation itself, or International, it's called right now, so relevant that people just can't afford to fragment off. You can see it with Linux. Linux is also very fragmented in the sense that everyone has their own fork.

(00:58:29):

But at the end of the day, if you want to be relevant, you have to stick close to the mainline Linux, at least to a certain degree, to be able to benefit from all the mainline development of Linux. Similarly, if you want to benefit from what International is developing and building into the standard and so on, you can't just invent your own stuff. You can do it for a time, but that'll just cost you money and time in the longer run.

(00:58:58):

So I guess the answer is, RISC-V International has to do a good job and stay relevant. And it is doing a good job, and it is spinning up new efforts to standardize different profiles as an example, just to show the way, how would you build this class of RISC-V SoC? How would it work? What kind of features does it need to have? What kind of software is that associated with? RISC-V is trying to map that out using various working groups so that people know how to do it, so that they stay in the comfort zone.

(00:59:34):

And if someone wants to veer off, they're allowed to. They can just do things differently and fork off, but probably they won't be very successful ,because they'll have to support themselves. They'll have to build their own tools and so on, which is hard, and costly, and time consuming.

EW (00:59:50):

Comparing it to Linux makes a lot of sense to me because there are big Linux distributions we all heard of, Ubuntu, and Debian, and Fedora, and they all have, I don't know, their own mascots. I don't know what the difference is between them. But then we also do have some embedded Linuxes that are far more boutique and far more customized to what they are or what they're intended for. So I could see how RISC- V could be similar where, you have the big ones, and then maybe you do go off and have your own set of features. And then you deal with having your own set of compilers.

CW (01:00:30):

And ... being open source doesn't lead it necessarily to being fragmented any more than proprietary because x86, I don't mean, AMD and x86, there was a fork about 20 years ago.

MG (01:00:46):

Yeah.

CW (01:00:47):

And it was pretty significant, and things reconverged. And now everybody supports everything else that everybody came up with. But there's precedent for things fragmenting even in the majors in the past.

MG (01:01:01):

I always talk about open source as this kind of switch, whether the source is open or not, right? It has implications, but the definition of open source itself is just about the availability of the source and what you can do with it. But whatever happens, whether the ecosystem becomes fragmented or not, it's different kind of dynamics at play. It's not necessarily automatically so, that open source is fragmented versus proprietary technologies are very consolidated. It can actually be the other way around, right?

(01:01:29):

Open source is great method for consolidating things, where people flock behind successful projects and work together as part of foundation or something to improve one or a group of projects together, versus perhaps proprietary products where you have lots and lots of options and none of them works as you wanted to.

(01:01:48):

So yeah, I don't think fragmentation is really related directly to open source. The custom extendability of RISC-V perhaps can be viewed as this potential problem, but again, it's a standard way. Even in Renode, for example, because this is standardized, we have a very easy way to add the support for custom instructions so that even if people come up with a hundred new custom instructions, "Oh it's easy to support them in the tool chain," right? Because everyone knows how to do that, and it's baked into the spec itself.

EW (01:02:24):

Will RISC-V chips be cheaper, because they don't have the licensing cost?

MG (01:02:29):

Ultimately, yes. Right now, of course, it depends on the space you're looking at. RISC-V has some catching up to do in the high-end spectrum, but it's growing very fast. Already in the low end space, you can see really cheap RISC-V options coming from China, but it'll take time, of course. It's not that right now, you'll get a comparable RISC-V chip to the same kind of Arm chip, and that's kind of obvious. We're much earlier in the RISC-V life cycle, but ultimately, yeah, it's going to be cheaper. But I don't think it's about the cheapness of it. I think it's about the freedom to design whatever you want. That's the more important aspect of RISC-V.

EW (01:03:14):

And if I am running a Cortex-M something, M0 or even M4, and I want to go to a RISC-V processor, what should I be looking at? I don't want to build my own processor. I just want to buy one.

MG (01:03:32):

Just microcontroller, I think the Expressif C3 series is kind of a decent level of support, versus price, versus performance at this point, if you're looking at the Cortex-M space.

EW (01:03:48):

And let's see, there were a couple more questions you put for us. Okay, I'll ask Christopher, but this is from Michael. "What is your take on Rust and embedded? Have you seen much uptake?"

CW (01:04:02):

I have not. I've seen uptake elsewhere. I have not encountered Rust in my daily work. I haven't seen it in any clients. I'm sure there are people, other spaces, that are using it, and I see that on social media. People are integrating into things, but I think it's fairly niche at this point still. Yeah, I think it has its place. I think Oxide and high-profile companies like that are the biggest examples that I've seen so far. But I have not personally used it, and I have not had a client ask for it. And I don't anticipate using it in the near future.

EW (01:04:44):

I've had a client recently ask me for C#, but not Rust.

CW (01:04:49):

Well, yeah.

EW (01:04:50):

And Python. I mean Python, I get a lot. I did recently see a job posting that requested Rust, but I think it was one from Ferrous Systems or one of the other ones that basically is named for Rust.

CW (01:05:04):

Is a Rust shop. Yeah.

MG (01:05:05):

One of the Rust-focused ones. Yeah.

EW (01:05:07):

Yeah.

MG (01:05:07):

We do get to work with Rust from time to time, but yeah, I agree. It's fairly niche. I'm interested to see how it grows certainly with the Linux kernel adopting Rust as a potential language to write drivers in. I think that's going to be a huge driver. But yeah, I'd like to see more of it. It's kind of fun to see some innovation in that space. And I've seen people do some pretty crazy stuff with Rust and embedded. But yeah, I also haven't seen much actual real-world projects approaching us and saying, "Oh, we totally need to use Rust for this," with some multiple exceptions. We have some really nice work going on with Rust, but it's a minority.

EW (01:05:48):

I would like Rust better if they weren't so evangelical, but that's just me, I know.

CW (01:05:58):

I was about to say there was a lot of excitement and stuff, for lack of a better word, evangelical stuff, about Rust two years ago. I haven't seen anything in the last couple of years. It's just kind of quieted down and people are like, "Well, here's this language and I'm using it for this." I haven't really seen that much.

EW (01:06:18):

Yeah, I watched EuroRust talks, and all of them had a section that was called "preach."

CW (01:06:23):

But you're at a EuroRust conference.

EW (01:06:27):

Yes. But I didn't -

CW (01:06:28):

That's like going to a superhero movie and getting mad about capes.

EW (01:06:35):

Point taken.

MG (01:06:35):

I love the analogy. Yeah.

EW (01:06:39):

Okay, and let's see, what else do we have for you from our listeners? One more about Renode going back. Again, from Benny, "How do you create GUI elements in Renode?" That's a very detailed question. I think Benny might be using this.

CW (01:06:57):

What is a GUI element, for me who hasn't used Renode?

MG (01:07:01):

Yeah, I mean, I don't know what the question is about. Is it more about how do you create a part of the SoC that's capable of displaying GUI stuff, but I believe that probably what's meant is, "How do you create a visual representation of the board?"

CW (01:07:18):

Oh, I bet. Yeah.Yeah.

MG (01:07:20):

I would guess that's the questions origin, and the answer is we have some examples. We've done some web-based visualizations, and again, we'd love to do more. And also Renode has a library called xwt built in, so if you want to do a desktop-style visualization of something, we have a logging utility that's visual.

(01:07:44):

We have the ability to do such things, but we don't have a framework-wide way to show you the board and everything that's going on with it visually, again, not for lack of the will to do so, or because we haven't tried. It's more, it's just difficult to build out this feature in a very consistent way that works for everyone.

(01:08:10):

So there's two ways. Either you can go with the desktop-style of xwt, or you can do some kind of a web-based visualization where you just communicate with Renode over some kind of a socket or something. And we've done that too. There's examples there. So, yeah. But we're always happy to talk about these ideas. Ultimately, of course, things like Wokwi we are a good inspiration, and you'll certainly see more of this kind of stuff in the future.

EW (01:08:42):

More specifically, I feel like we should send Benny to a Discord. Do you have a Discord?

MG (01:08:48):

I'm afraid not. It's an ongoing discussion. People are asking, and it's just a matter of if you do set one up, you actually have to maintain it, and kind of talk to people, and have the questions in real time, and make sure that -

CW (01:09:02):

Yeah, talking to people is overrated. Sorry.

MG (01:09:05):

Yeah, no, it's definitely not overrated, but you have to -

CW (01:09:08):

It's very difficult.

MG (01:09:10):

You have to do it right.

CW (01:09:11):

Yeah. Yeah.

MG (01:09:11):

You have to be able to answer.

(01:09:14):

As we talked in this podcast, Renode is not always useful for everyone in every context, and sometimes it's just difficult to explain when people focus very much on what it cannot do, or that it doesn't work for a use case. It's like, "Yeah, it's not supposed to do everything." That's the kind of conversation that's the hardest, I guess. And we will have to set something up, of course, at some point, but right now we're mostly using GitHub issues to communicate with the community. But the request is out there, and we're just trying to make sure that if we do it and when we do it, we do it right, and we can actually afford the bandwidth to make sure that it's high quality, and we observe some code of conduct, et cetera, et cetera.

CW (01:10:01):

Yeah.

EW (01:10:02):

Michael, it's been really good to talk to you, and I bet I probably should go look more at Renode. It sounds like it would be very useful in many situations. Do you have any thoughts you'd like to leave us with?

MG (01:10:18):

Perhaps that open source that we kind of touched upon a number of times today is this thing that's not just free as in doesn't cost anything, but it's more a very pragmatic way of solving a lot of problems. I've talked about hardware a little bit, but just the sense of collaboration in general. Making things open just helps people work together very easily, helps science, helps the advancement of mankind in general.

(01:10:46):

So I tend to look at it as a good thing and also a good way to do business, right? It's not just ethically nice to be working with open source. It also, at least for us, has been a very successful story where our company is growing very fast, because we're working with open source. So yeah, remember that it's not just about it being free, but it's more about it being accessible for everyone and helping people collaborate better.

EW (01:11:19):

There are different kinds of free. Our guest has been Michael Gielda, co-founder of Antmicro. We'll have many links in the show notes, including to this Colab I'm playing with.

CW (01:11:32):

Thanks, Michael.

MG (01:11:34):

Thank you very much.

EW (01:11:35):

Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listener Slack group for their questions. And of course, thank you for listening. You can always contact us at show@embedded.fm, or hit the contact link on embedded.fm.

(01:11:49):

Now a quote to leave you with, I probably should have chosen something about open source, but I'm still very much in the Murderbot world. So this one's from Martha Wells, "All Systems Red." This is Murderbot. "I could have become a mass murderer after I hacked my governor module, but then I realized I could access the combined feed of entertainment channels carried on the company satellites. It had been well over 35,000 hours or so since then. Well, still not much murdering, but probably, I don't know, a little under 35,000 hours of movies, cereals, books, plays, and music consumed. As a heartless killing machine, I was a terrible failure."