Embedded - 433: Getting Mad About Capes

Episode Date: November 3, 2022

Michael Gielda spoke with us about Renode, an open source embedded systems simulator. It also simulates large distributed systems and network communications.  Check out Renode.io and the boards supported by Renode and Zephyr on Renodepedia. Elecia played with the Nucleo F401 tutorial on colab. Michael is the co-founder of Antmicro. The ESP32-C3 is a commercial RISC-V core with WiFi and BLE. We also mentioned Wokwi on the show. (And we had its creator Uri Shaked as a guest on episode 396: Untangle the Mess Transcript

Welcome to Embedded. I am Alicia 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. Hey, Michael. Welcome. Hey, everyone.

Could you tell us about yourself as if we met at wherever we actually did meet? All right. So I'm Michael Gilda. I'm a co-founder of EntMicro and an open source enthusiast working with open source silicon software, hardware, you name it. Most of 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 this night I was coding something. So, yep.

We want to do a lightning round where we ask you short questions and we want short answers. Are you ready? Yeah, I guess so. Favorite post-Halloween candy? I didn't really celebrate Halloween too much, so I don't have a favorite. Sorry.

Favorite candy of any kind? Any kind? Huh. I think that would be like sour jelly beans. Do you have a favorite Internet of Things connection method? Bluetooth, Zigbee, Internet, Wi-Fi, etc. I have a love-hate relationship with Bluetooth. I love it, but you know but it doesn't always work.

Wi-Fi is probably my technology to go, but it depends on what you mean by IoT, of course. Six-Loban is also highly underappreciated. Favorite microprocessor? Some sort of RISC-V. Hard to kind of decide which one, though. I have a soft spot for the original FE310 fromC-V. Hard to kind of decide which one, though. I have a soft spot for the original FE310 from Sci-5, you know,

the original kind of RISC-V MCU. Favorite video game? Tough one. Between Fallout and Baldur's Gate, I guess. It's a tie. Which Fallout? Again, it's a's between one and two. Between one and two, the original ones, you know.

Do you like to complete one project or start a dozen? That's a very easy one, start a dozen. And do you have a tip everyone should know? Plenty, but kind of a short one, yeah. I guess that nobody's 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. That is so true. Okay, so let's talk about Renote because I keep seeing it and we talked to Jonathan Berry 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. And I have to admit, it's just, it's a lot.

Could you give it to me in terms that... Explain it like we're five-year-olds. Yes, thank you. Okay, I can try. Well, if you're really a five-year- Okay, I can try. Well, if you're really a five-year-old, I have a five-year-old, so I probably use 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. But once you try to scale development 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. And that's what a simulator like Renote 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. 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, you know, 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. I haven't, other than Walkway 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 there's a lot of work to set up.

Sell me what you have. Sure. I think the key to how Reno is kind of successful is that we're trying to make an open source framework that a lot of different people and companies collaborate to develop. And in the end, of course, yes, it takes time to set up simulation, to model hardware and so on. But then again, hardware is commoditized to a large extent. There's a lot of overlap. There's a lot of 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. 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. So what kind of hardware are you supporting? There's quite a lot. I would try to kind of mimic the real-life projects. 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 in the market right now. So much of the support is oriented around ARMS platforms, which are, of course, extremely popular in the mid-end market. Cortex-M is, of course, very well supported. But we have support for Cortex-A

and are working on 64-bit advanced Cortex-A platforms right now. This will drastically improve in the coming months. 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's deployed. Other than that, there's some Spark. There's extensive support. 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? What do you, since that part of simulation is so hard. It's the peripherals. It's the peripherals that kill you. Or like the Cypress processor, it's just a pain in the neck to set up. So how are you supporting an FPGA plus? I just wouldn't support that. 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 QVU as everyone would, right? Like you want to simulate 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 QVU kind of tends to normally ignore. And 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. So Reno was kind of born from that need where we were working with real hardware and wanted to model the hardware in its entirety. And so, Reno actually kind of models all those peripherals. We have very good coverage of, like, ST mic controllers and, you know, Nordic mic controllers and different vendors that could kind of...

But what about spy flashes? We have some too. I mean, it's... Oh, you're talking external things to the microcontroller. I mean, it doesn't do me any good to have an ST32F4 whatever if I can't also connect it to... A display. A display and a spy flash and an ADC

and all of the other things that actually make up my system. My processor is... Boring. Boring, actually, yeah. I mean, it's super important, but overall, that's just the application that isn't the embedded system. Sure, but Reno 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. So do you need an RTOS or do you support KubeMX? How does that actually work out? It's completely software agnostic. So you can run KubeMX, Bionrace, you can run Zephyr, you can run FreeRTOS, whatever you want. It doesn't rely on any specific payload it runs. 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. So I'm actually compiling in my normal environment and programming, JTAGing, flash updating onto your virtual devices. Yes, except like you're not really flash updating in the sense that you're just uploading a binary to a place in memory on your PC. So it's kind of faster and easier.

But yeah, the flow is kind of the same. And if you don't have a peripheral that I need, can I write one? 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. 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 and over time what happens is that people might build those things in isolation or even we might do that and then once the the peripherals 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 like digging into renotes internals to model a single piece of IP inside a chip or outside of a chip, of course. 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 the physical world. Do I replace that with a data file, a comma-separ separated file that every time i sample how does that work you're absolutely correct i mean there's many ways you could solve this because of course you could imagine you know 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 like a very simple data file that we supported. 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're having more and more scenarios where we're kind of getting multiple sensors going at the same time. And, you know, the application perhaps processes the data and makes some decisions based on several data sources. So we've designed a format that allows us to do this more, you know, fine-grained and have better control of how this data is being fed into simulation. But yeah, it's a file in the end.

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 real time or not? 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? 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 like 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. So when it comes to the question whether it's real time, 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.

Like, for example, if we run multi-node systems, we'll synchronize them together. We're not just running as fast as we can. We're kind of taking time to ensure the determinism. 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, you know, will allow you to adapt renotes to different kinds of scenarios in terms of what you want to achieve in your testing. I could definitely see a case for I'd like to run as fast as possible, maybe with determinism still on. But, you know, there are those cases of bugs where it's like, oh, this happens once a week. 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, or generally speaking, simulation, you'll have many ways to solve this. You can even record and replay these kind of scenarios. You can compress time if your

device sleeps a lot, then you don't need to really 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. 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.

But if you just 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. What about all the times I need to work with Bluetooth or servers to connect to?

How do I... 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 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? Yeah, you can absolutely do this, and we've done this.

Obviously, the server is done this. Obviously, the server is expecting a real device, so it might have some kind of quirks you have to adapt to in terms of how you talk to it. But generally speaking with rich networks, the virtual and physical world,

also in 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 guarantee of determinism. But you can definitely do this, and we've done this. It's definitely possible.

And Bluetooth, can I integrate with an iPhone app? That's a very common question, too. And the answer is you absolutely can. We haven't done much of this yet. We're 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.

But talking to your phone is absolutely doable. It's just we haven't really... 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'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. 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?

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, you might want to care about the physicality of things, but we're not aiming to like model the entire world because that's just a lot of compute. We're focusing on the results of what happens when communication fails 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 can also put nodes in physical like 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. So you can have various ways in which the connection quality can be represented as being poor. That is not to say that 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. 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 you know focuses really when people talk about wireless networks is what they want to test what happens if things go wrong not if they work well so you can go in and say like i want to stochastically drop 15 of packets or corrupt some percentage randomly that kind absolutely yeah and you could even introduce some more like intricate corruptions like you know if you know the kind of things to look out for you can break the packets in ways that you know because you can you can just drop packets for example and then of course uh dropping is 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. At what point do I start looking at

Renode? At what point in the development cycle? At what point in the development cycle? At what point in the development cycle and then at what complexity of device? 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 reNotes. 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. 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, Renote 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. So I would encourage everyone to try to introduce Renote into their workflow very early. But on the other hand, you know, it's, I think think best if you introduce it at the moment when you're comfortable with fusing it

and you feel there's a real need. And what about complexity? You mean of using Renode itself? Well, there are going to be projects that don't need Renode because they're too simple or don't need Renode because they are too complex

and setting up the simulation is as much work as doing the project. Well, perhaps, yeah, definitely on the simplicity end of 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 it's just a lot of work to simulate them. 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 a really complex system

without the systems, without having to put in a lot of work. And so I wouldn't say that, like, 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 in terms of, like, yeah, if you're just building something very simple, you might just not need Reno, then that's fine.

And it seems like there's cases where you, 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 into subsystems. Yes. Yep. That's a great thought. Yep. 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? Well, I mean, first you should probably match whatever components you're planning to use at least. Before that, I go to the Renode website and I push download Docker? I mean, that's what I was meaning. 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 Renote 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. And then there's the Renotepedia effort, which covers hundreds and actually thousands of demos. So definitely that that would help to to get a feeling for what we not can do but like in terms of actually how can we not be useful for your particular project um it's always good to kind of research a little bit you know whether the hardware you're trying to use is kind of uh at least nominally supported

right because like if you if you pick something that's completely different than what we have, then you'll just find it harder to adapt to your needs. Whereas if you pick a board that we have a demo for, that's kind of what I would try to lead with. It's like, if you find that we actually have a specific demo for the exact board 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. And of course, if you start using hardware features that are not there, like say a sensor that you want to connect and it 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. And so coming back to how I would 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 GreenNote and try to run that demo.

I could run any random demo, of course, and that's also fine because it shows you the capabilities of the framework but it's especially cool if you can actually you know compile a binary that's like a hello world which is like the starting point these 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 you would start with something very simple. And once you have that simple thing and you run it in a simulator, you can realize, oh, okay, that's really something. I can really kind of 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 the Renode is, of course, one of the important steps. And you can do it for any platform, like Mac and Linux and PC. Windows PC, I mean. And we have portable packages for Linux, which is the best starting point for Linux people. We're actually working on having portable packages for all, which is the best starting point for Linux people. We're actually working on having

portable packages for all three operating systems, but installing on Windows and on Mac is not hard. These are just an exafile, a regular installer on Windows and DMG on Mac. And on Linux, you have the portable package.

So on all three OSs, you have a fairly simple choice how to install Renode. Or, of course, you can the portable package. So on all three OSs, you have a fairly simple choice how to install Renode. Or, of course, 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. 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 is available too. I am desperately not the person who just goes and installs stuff on my computer. Really? I just grabbed stuff. As he was saying about looking for tutorials, I found one that had a collab, which is the absolute best way to get me to try it.

Oh, yeah. Although, trying to figure out what this collab does while I'm also trying to figure out how to do a podcast. While you're also doing a podcast, yeah. You might be multitasking too much. This is incomprehensible, but that's probably because I can't do both. I have a question about the demos. So if I grab one of the demos for some STM32, does that include like 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? That's such a fantastic question. Yeah. And that's a big struggle because, you know, like we're building a simulator and at the same time, of course, in some sense, we're building, you know, all the embedded software in the world because we have demos and stuff. So historically how we approached this was we'd provide binary demos with some kind of binary. 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 of work than getting them to install Renode. So what we have in Renode is a bunch of work than getting them to install Renode. So what we have in Renode is like a bunch of scripts that you can just install

Renode, you run it, you type one line, like essentially it's just start and the name of the file with the demo, like 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, in the script, you change one line, and here you go.

So we don't provide like, you know, KubeMX projects and stuff. Not because we couldn't, it's just like a huge endeavor 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 like 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've embarked upon

throughout the last year, which is called Renodepedia, or earlier, the Renode Zephyr Dashboard. That's the origin of it. And Renode Zephyr Dashboard is actually building hundreds of Zephyr RTOS binaries from source. 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 Renode has those building blocks. There's the CPU models, there's the IO models, different sensors, and so on. 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 kind of generate the re-node description files

called REPL, re-node platform files, as we call them. And so generating it all together gives us the ability to kind of test Zephyr binaries at scale. And there, if you want to actually reproduce the entire thing, it's trivial because we give you collabs that kind of show you how to build that kind of binary. And a lot of it is for structure that you can just trace back directly to the sources.

So for Zephyr, it's been pretty simple because Zephyr is well-structured. It's easy to generate different kinds of binaries for different kinds of targets, right? And of course, it scales across different vendors, even different architectures with 5R and so on. So it's a good kind of, it has a good coverage of the entire ecosystem.

But you could imagine similar efforts for, you know, other operating systems, other, you know, or Kubemex 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 that those demos actually work. 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. 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. Okay, well, I was going to add to that about Sysbus and cpu zero but i think you've covered all of that um so we have some listener questions um from benny uh has um is there a guide for dockerizing renoad for ci continuous integration or other larger scale use cases?

As mentioned, there's Docker images available. And basically we even have like GitHub action with Renode where you literally just have to submit like several variables and Renode is 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 Docker file

of the Renode Docker. And you can just make your own if you need a special image with Renode. But I guess the real... Like, 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? Like, 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. read on. 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. That should feel pretty familiar where like in the end what you see is the window right like 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 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. You know, like,

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 Renote, I would say. Benny wanted to know if it's possible to do socket CAN. Why would anybody want to do CAN? Sorry.

Yeah. Having a bad CAN week. Well, 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 socket CAN. We haven't bridged with real physical CAN connections from Reno.

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 have connected, like you can bridge to 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

connected device, then we'll just have to implement that. Jonathan suggested I ask about Pokedex for Zephyr boards. Is this like Pokemon? Yeah, I love that question. Pokedex is, you know, how you kind of look up all the Pokemon in the Pokemon world.

I love the analogy where Renotepedia, the framework I was talking about, is kind of like this, except not for Pokemon, but for actual real hardware. The Renotepedia is kind of an effort to try to showcase, you know, how much diversity there is in hardware. It's a nice encyclopedia, basically. You can also think of it, the inspiration for doing Renalpedia in the first place was Ufopedia from XCOM, the XCOM 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. And I, 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 text and comparing different parameters, you know, of different, I don't know, weapons. It's just, I guess, engineers, many at least, have this kind of mind where they just like these kind of things. And of course, it has a practical,

like perhaps in a game, it isn't very practical. You just want to win the game. But in real life, when you're trying to document all of the world's hardware, you're trying to document all of world's hardware, they're trying to see what they're comprised of, like what kinds of relationships between different pieces of hardware there are. This actually becomes useful, like this kind of

data set where you try to take this hardware apart and take a look at what is this SOC? Like, how is this SOC related to the other SOC? What kind of IP blocks come into this SOC and make it what it is? 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. 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. This realpedia is there, it's full of stuff, but there's plenty more to be shown and said. Do you have any questions for us before we move on to RISC-V? I mean, I guess I had the question whether you'd actually used read or whatever, and I guess the question was

more like, you haven't earlier, but you've just started experiencing it, right? Exactly. I ran my first Reno thing, widget, Reno note during this podcast. So the answer is both yes and no. You haven't entirely convinced me. I mean, I'll go off and play.

To be fair, you're difficult to convince. 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. You don't need to. 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 Reno for. But you're a consultant. But I'm a consultant, which means that I would have to get somebody to pay me to want to do this. Yes. Which means that I would have to be familiar enough with this and convinced enough with it that I demand that they do that. This is why I'm saying you're a difficult target. I'm super hard to convince. 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. No, I mean, it's definitely the thing with open source is that that's why I kind of like 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. Some time will pass. 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. You don't have to interact with us to try it out. Of course, we try to make documentation better and better, but there's never enough time.

So definitely construction 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. Renode PD 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. And it's fine for some people to never actually be in a position

where Renode helps them because it totally depends on your station life and your way of working, your clients. So yeah, it's perfectly fine not to want to use Renode, especially at a specific point or in a specific project. I think that the sweet spot is when some scales suddenly start to appear and you 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 saying, oh yeah, I have many development teams working together. How do I make them collaborate more effectively? And that's where Renode really comes in. 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 yeah oh no i absolutely understand this viewpoint

because it 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 you know to do something they aren't used to doing and so on. But what I was going to say was projecting backwards in my career, if I had had this at various other times, I would have 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 have gotten a ton of use because we really needed, you know,

CI stuff to work at scale on devices. I mean, we had just horrible, you know, racks of Mac minis and stuff and attached to watches. I think we had cameras at one point. It was just, you know, we had all kinds of Frankenstein's monsters to try to get device testing to scale. And we work with clients like that.

Yeah. 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 reached out to them a year earlier and we'd been using Renode when 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 right but because testing with real hardware is hard

they're kind of wasting time and money most of the time that's where renote is especially handy 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 Reno would be somewhere I would look to get that first few months of okay, let's play around with this. I see where this is. 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, but and for the most part, they all get the same board. So, and one of them was a nucleo board that you, that is on, uh, the Renodepedia. Um, but I don't know, I have a few, uh, things in Walkwee that they, 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, Walkway is like, here, go play with this. But Reno would require at least a lecture and not just a hand wave. Yeah, I mean, Walkway 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 move towards as much as we can. I would say that playing around with things in Renode doesn't necessarily have to be a whole lecture, but sure, if you wanted to 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 um so it's more a matter of the fact that uh what we also has this kind of visual you know editor that allows you to kind of build a this kind of nice uh connected uh setup so but that is something you could do we know too It's just that we have had a few approaches to this kind of thing. It's fundamentally not trivial to do it well. 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 Walkway 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. 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, visual system. And we definitely want to do more of this.

And, you know, as the framework grows bigger, as the team gets bigger and so on, that's an obvious direction. But it's just not something you can easily do and make everyone happy. No. You really can't. And if you are making everyone happy,

you're probably not actually getting anything done. You're lying. Exactly. Someone's lying. Yeah, no, I mean, this is, things like Reno seem to be kind of a holy grail in my mind. That's this shining thing on the hill that everybody wants to have. But it, you know, 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.

Exactly. Yeah. You end up looking for the 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 100% of what you'd assumed initially. hearing, right? There's holy grails. You want to aim high, but

you can never really do 100% of what you assumed initially. And that's fine. And Renode helps a lot of people. And yeah, as I said earlier, it's not going to help everyone do everything. We're trying to take the burden off. 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 that you really need to test in hardware. So it's all about the Pareto optimal way of working, really. But you said both, and I'm like, okay, you just doubled my testing. But I know where he's coming from, that

the re-node 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. Well, when I hear somebody say that, I hear, okay, you can do your continuous integration testing

in Renode, and maybe 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. Yeah, that's what I meant meant and of course like you can even take some of the user testing and some stuff that the users have detected like you know they're trying to input stuff and things

are not working you can actually try to record and replay these kind of events you know so mixing up like real testing with virtual testing is actually pretty cool if you if you have a good understanding of what's you know what are the strengths and weaknesses of both approaches but i agree it's 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 you know i'm not talking about a hobby project where you know like it's you don't really need to do so much testing or or just very small deployments where you could literally imagine someone going and testing things manually because there's just five things so brisk five uh you mentioned that earlier uh how are you involved

with it 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 like the beginning of the foundation, 2008, 2014, 2015, we got involved early. We kind of started building some first RISC-V implementations. We worked with Sci-5, we worked with Microchip. That was that built the first mass market SOC on RISC-V. We have a lot of RISC-V clients, and we're also very active in the entire ecosystem,

not just RISC-V itself, because RISC-V itself is actually going well. And, you know, 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, you know. Open source implementation 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. 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. Yeah, 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 typically be part of these kind of groups that would say, hey, you need, Europe needs to do more open source or the US needs to do more open source. Anyone that wants to be competitive needs to kind of use RISC-V, you know, needs to do open source hardware to stay relevant. That's our belief. I remember quite clearly when we didn't all run open source compilers. Yep. When we had to pay for every compiler, not just for the special ones that work on a particular processor. Absolutely.

And that changed, and that's how the world is. It needs to change because it's not just about the money. It's about having to ask for permission. you know you're just gonna go somewhere else you're gonna like people from hardware they will very often just go and start doing ai or web development because you know hardware is just too proprietary and there's too many um walls uh and people stop caring that's and people are complaining a lot oh why are people not going to study hardware and why they're not taking up those kind of difficult topics? And part of the reason, I'm not saying it's the entire reason, but 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 on, and just build things, I kind of result in five minutes versus embedded, where you have to do a lot of hand-waving to even get started. And it's not just the physicality of the world. That's the one thing we're trying to solve with Reno,

but it's also about the licenses and the obscurity. If that was different, I think it would be much easier to attract new talent to focus on hardware rather than other areas. But because it is open source, what happens if it gets too fragmented? What happens if every vendor adds their own custom instructions? That question is, 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. 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 the 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. So I guess the answer is, the 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 kind of 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. work, what kind of features does it need to have, what kind of software is that associated with.

RiskFive 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. 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. 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. And being open source isn't a unique... Being open source doesn't lead it necessarily to being fragmented any more than proprietary

because x86, I don't... I mean, AMD and x86 had a pretty... There was a fork about 20 years ago, and it was pretty significant, and things reconverged, and now, you know, everybody supports everything else that everybody came up with. But there's precedent for things fragmenting even in the majors in the past. I always talk about open source as this kind of switch, whether the source is open or not. 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? Open source is a great method for consolidating things where people flock behind successful projects and, you know, work together as part of foundation or something to improve one or a group of projects together versus perhaps proprietary products where you have, you know, lots and lots of options and none of them works as you want it to. 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.

It's, you know, a standard of ways. Even in Reno, for example, because this is standardized, we have a very easy way to add support for custom instructions so that even if people come up with 100 new custom instructions, 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. Will RISC-V chips be cheaper because they don't have the licensing cost?

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 lifecycle. 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. 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?, 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. Just a microcontroller. I think the Espressif C3 series is kind of a decent, you know, level of support versus price versus performance at this point.

If you're looking at the Cortex-M space. And let's see, there were a couple more questions you put for us. Okay, I'll ask Christopher, but this is for Michael. What is your take on Rust and Embedded? Have you seen much uptake? I've seen uptake elsewhere i have not encountered rust in my daily work um 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 you know people are integrating into things but

uh 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. I've had a client recently ask me for C Sharp, but not Rust. Well, yeah. 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 Ferris Systems or one of the other ones that basically is named for Rust. Rust Shop, yeah. One of the Rust-focused ones, yeah. 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 notable exceptions. We have some really nice work going on with Rust, but it's a minority. I would like Rust better if they weren't so evangelical. But that's just me. I think I haven't seen... I was about to say, there was a lot of excitement and stuff,

for lack of a better word, evangelical stuff about Rust like 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. Yeah, I watched some Euro Rust talks. All of them had a section that was called Preach.

But you're at a Eurorust conference. Yes, but I didn't... It's like going to a superhero movie and getting mad about capes. Point taken. I love the analogy, yeah. Okay, and let's see, what else

do we have for you from our listeners? Ah, 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. What is a GUI element for me who hasn't used Renode? Yeah, I mean, I don't know what the question is about is it more about you know uh how do you

create a part of the soc that's capable of displaying gooey stuff but i i believe that probably what's meant is how do you create like a visual representation of the board oh yeah yeah i would guess that's the the question's 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 we also have, like, Renode has a library called xwt built in. So if you want to do like a desktop style visualization of something,

we have a logging utility that's visual. We have some kind of, 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 just difficult to build out this feature in a very consistent way that works for everyone.

So there's two ways. Either you can go at a 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 Walk.Wi are a good inspiration. And you'll certainly see more of this kind of stuff in the future. More specifically, I feel like we should send Benny to a discord do you have a discord? 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 talk to people about questions in real time talking to people is overrated sorry it's definitely is overrated. Sorry.

No, it's definitely not overrated. It's very difficult. You have to do it right, right? You have to kind of be able to answer. As we talked in this podcast, Reno 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. Yeah, but the request is out there. And we're just trying to make sure that if we do it, you know, and when we do it, we do it right. And we can actually afford the bandwidth to, you know, make sure that it's high quality and we observe some code of conduct, etc, etc.

Yeah. 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? Perhaps that open source that we can touch upon a number of times today is this thing that's not just free, you know, 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, if making things open just helps people work together very easily helps science helps the advancement of mankind in general 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's also at least for us it 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.

There are different kinds of free. Our guest has been Michael Gelda, co-founder of AntMicro. We'll have many links in the show notes, including to this collab I'm playing with. Thanks, Michael. Thank you very much. Thank you to Christopher for producing and hosting. Thank you to our Patreon listeners Slack group for their questions. And of course, thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. Now a quote to leave you with. I probably should have chosen something about open source,

but I'm still very much in the murder bot world. So this one's from Martha Wells. All systems red. This is murder bot. 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, serials,

books, plays, and music consumed. As a heartless killing machine, I was a terrible failure.