#599 – An Interview with Uri Shaked (Wokwi.com)

Chris Gammell: This is The Amp Hour Podcast. Released August 14th, 2022. Episode 599. An interview with Uri Shaqed. Welcome to The Amp Hour. I'm Chris Gammell of Contextual Electronics.

Uri Shaked Wokwicom: Hey, Chris. I'm Uri, working on Wokwe.com, and welcome to our podcast. Hi. Thanks, Uri. How are you? A bit under the weather, but very excited to be here.

Chris Gammell: Yeah. I'm glad you're here. So you mentioned Wokwe. So let's start with the important thing. How do you spell Wokwe so people can go and follow along as they're listening right now? W-O-K-W-I. All right. And I do recommend people do it because we actually mentioned this. Actually, you know what? I told Dave about Wokwe at the end of the show, after we were done recording last week, and he started tweeting about it. And he was very excited about it because I mentioned we were talking about the RP2040. And I was like, I know this guy, Uri, is going to be on the show next week. And there is a simulator for the RP2040, among other devices that are out there. And it's super easy to get started. And you can visualize stuff and you can plug in all of these external peripherals. And you can also use the tools that you might have in like an Arduino getting started kit. What is your go-to recommendation when people start with Wokwe?

Uri Shaked Wokwicom: That's a good question. First of all, you forgot to mention there is also free shipping to New Zealand. So Dave's covered.

Chris Gammell: Uh-huh. Yeah.

Uri Shaked Wokwicom: So that's actually something I'm trying to figure out myself. Like, I built it, first of all, a sort of tool that helps to alleviate my own pain. And in pain, I'm talking about endless drawers full of electronic components that just like a pile that just keeps growing.

Chris Gammell: Yep. I know that fear. I know that feeling, right?

Uri Shaked Wokwicom: So, yeah. Right now I'm free from most of my electronics. I can say it out loud. I'm clear, almost. Still fighting this addiction. I really built it as something that tries to just give you everything you need. And I know when people work on products, they always say you should focus, focus, and focus. And you should have a very clear product and everything like that. I'm trying, but it's really like it started off as an Arduino simulator. So if you know Tinkercad or Proteus, it probably compares best to Tinkercad. But then I started adding things that a user asked for and things that I myself was missing. So right now it can do a bunch of stuff. So Arduino, we already mentioned it. And then you have like the Raspberry Pi Pico, which I added in a live stream last year as it was announced. I decided to take on a challenge and just do weekly live coding sessions where I create a simulator for the new Pi Pico from scratch. Yep.

Chris Gammell: Yep.

Uri Shaked Wokwicom: And then we also have now the ESP32. And I think the most important part is that you have a huge library of peripherals that you can connect to all of these chips. So the idea is you don't need your hardware to prototype, at least for some kind of projects, anymore.

Chris Gammell: Yeah. I'd like to just give my personal anecdote. So I had a simulator. I remember it was like a lab bench simulator. It must have been. So it was when I started school. So like early 2000s. And I don't remember why they had us doing it. It was an electronics lab, but it was like more like test equipment. It was like, oh, hook this to that. But it was I think it was like Adobe Flash or something like that. And like that's what that's what my head goes to when I think of a simulator. Now, very, you know, very different, I guess, use case even. But when I think about like electronics and simulation, I think about that because it was like such a it was almost like a choose your own adventure style. Like it was like, you know, it was like you could basically just click around and get the right answer. But that's only because there wasn't any flexibility in it. This is so much closer to reality that it really is actually useful. Like so what does it take to get it to be closer to reality like this?

Uri Shaked Wokwicom: So I will answer that. But first, let me something that I encounter so many times where people are saying, hey, I found a bug in your simulator. Why doesn't the push button register on my digital read when I'm reading for it? Why doesn't it register correctly? And then it turns out they either forgot to turn on the pull up on the input or they got confused by the simulator simulating the bouncing of the pin of the push button. Wow. Yeah.

Chris Gammell: Yeah.

Uri Shaked Wokwicom: Yeah. Yeah. Often or another example, they say like you have a bug. I can't work with this and this library, which works on my computer. And then it turns out that the author of the library included Arduino dot H with without a capital A. So if you compile it on a Windows computer, it works. But when you compile it on Linux, it breaks. So that's like sort of the downside of having realistic simulation where users think there are bugs in the simulator. But it turns out it's actually...

Chris Gammell: It's too real. It's too real. It's too much like the stuff that you might experience in the real world, huh?

Uri Shaked Wokwicom: Yeah. I think the only missing part is the magic smoke.

Chris Gammell: That's right. Right. Also, the jumper wire falling out of the breadboard. That's always the one that got me. It was like, oh, you know what? If I just reshuffle each of the breadboard wires and now it works. Yeah. Just a little bit of, you know, a little touch here and there.

Uri Shaked Wokwicom: Would you pay for such feature? Like... Yeah. So... Hyperreality. Hyperreality. So in terms of technology, the simulation itself is built in several layers. So the basic layer is some sort of digital electronic simulator that gets a netlist. So all the parts and their pins and the connections to the other parts in the pins in the circuit. And it just knows how to sort of resolve the state of all the pins based on the changes. So if something goes high, it knows which pins are connected to it and how they are affected in like the sort of effect cascade. So that's one part, this digital simulator.

Chris Gammell: It's kind of like a schematic almost like because you're setting up wires. And so if I put down like a spy or I squared C based like display element, you have to go and actually hook up the SDA, SCL type of thing, power ground. And actually, so then that creates that netlist between the Arduino megaboard that's shown or the ESP32 board that's shown and what the actual unit is and devices.

Uri Shaked Wokwicom: Right. And then there is also like a logic analyzer that you can hook to these signals and record like the ISP-C protocol as it's going between the parts. So that's like all this netlist or schematic simulation is sort of the base of the engine. And then there is like the microcontroller simulation, which is just loading the binary and running it instruction by instruction. So if it's like Arduino program, it's compiled into a hex file. That hex file is loaded into memory space, which represents the on-chip flesh. And then there is an interpreter written in JavaScript. And by the way, this AVR simulation engine is open source on GitHub, github.com slash walkby slash AVR8JS. And it just runs the code or the machine code instruction by instruction. And on top of that, there is another layer of peripherals because the CPU core itself is not very useful unless you can connect it to the external world. So there is another layer of like UART and ISPERS-C, SPI, timers, EEPROM, whatever you have on the chip. So that's sort of one side of the simulation. And then the other side, there are like the external peripherals, like the LCD displays. And they have their logic implemented in JavaScript.

Chris Gammell: Which is crazy to me, but also it's amazing. Like the fact that all this stuff is like in the browser and running, it's just like, yeah, it's really, really impressive, man. It's like, I'm so impressed.

Uri Shaked Wokwicom: Thank you. It is still a huge undertaking. And a few things that people don't actually realize that are happening behind the scenes are, for instance, we have a FAT file system driver. So if you simulate an SD card and upload files to that simulated SD card, we have FAT file system driver that actually writes those, creates a FAT file system out of those files that you uploaded. Because the simulated code expects to read FAT file system from the SD card.

Chris Gammell: Right, right. Yeah, because it's like you said, you're actually compiling binaries and doing it instruction by instruction. So when it goes to that instruction that says, start reading this file system, it needs to actually simulate the other side of it like an actual micro would have, which is bonkers. So you're basically doing like all of these abstraction layers for reality, basically. It's really, it's crazy.

Uri Shaked Wokwicom: And I think the problem is, it's always hard to know, like where to put the line, where to stop. Because there is always one more thing that you want to simulate to make it more realistic. So one good example is the LEDs, simulating LEDs is such a horror because you would imagine like you have the computer screen and it emits lights and then you have LEDs and they emit light. So it's a perfect match, right?

Chris Gammell: Right.

Uri Shaked Wokwicom: But then your computer screen has a refresh rate of 60 hertz or if you are lucky, I don't know, 120 or 200 hertz. But a physical LED has an infinite refresh rate. And people actually use this to create PWM, like to drive the LEDs to different brightnesses. So if you just wanted to map this LED into like something that you would display on the screen, that would just flicker when you have PWM. You will see it either full on, full off. But since the refresh rate is just 60 frames per second, it won't look smooth. It will look like very jumpy and it won't create the right experience.

Chris Gammell: You don't get the benefit of the low pass filtering of the human cornea or whatever, whatever the physical phenomenon that actually helps smooth out the PWM and make it look like just a dimmer light.

Uri Shaked Wokwicom: You explained it much better than I would have. So thank you. And then on the other hand, when you try to simulate it on a computer monitor, you go and do some kind of averaging. But the sort of larger time span that you take, the more the LED, like there is a noticeable delay. So when you turn the LED off, it actually seems like it fades off because there is like, it's sort of, you can't predict the future. Or if you are trying to simulate things in real time, you can't know what the state of the LED will be in the next few milliseconds. You have to run the simulation to know that.

Chris Gammell: Right.

Uri Shaked Wokwicom: You sort of have to either average the best behavior of the LED to determine the next frame and decide what will be displayed for the next 16 milliseconds. Or just make some educated guess based on delaying the simulation or delaying the visuals of the simulation. And that's just something specific as an LED.

Chris Gammell: Yeah.

Uri Shaked Wokwicom: But if you get it right, then things like PWM or charlie plexing or seven segment display, then they work correctly. If you get it wrong, they are all broken. Yeah.

Chris Gammell: So this actually goes back to, I think, my negative experience with simulators in the past, which was basically they looked at the entire solution space of a thing that was going to happen. They said, you know, instead of infinite things that could happen, there are maybe 100 things that could happen. And they kind of code each of those examples. But it seems like yours is kind of going more towards that infinite solution space because it really is simulating a lot of physical characteristics or the register set inside of a processor, that sort of thing. So you mentioned drawing the line is difficult. But like how deep then does your physics model have to go? Because you have to then, I imagine in this PWM example, you know, you have a model of what an output on a AVR8 microprocessor is. And then you could turn it on. It has characteristics. You can turn it on and off at this certain speed, whatever. But then it's also like current drive characteristics. And it starts getting into how much current are you driving into the LED at these different PWM frequencies. So like where does it stop then?

Uri Shaked Wokwicom: That's a good question. So the answer is when I just feel it's too much.

Chris Gammell: When you have to sleep for the night and you're like, I just can't do anymore right now.

Uri Shaked Wokwicom: So one way to solve this was actually trying to deliver solutions that works with the common use cases, just like you said. So testing against code that does Charlie plexing or drive seven segment displays or does PWM. And seeing that I get a result that looks correct with the current set of like constraints or simulation, physics simulation that I already got in the system. And then I got to this. Initially, I would just listen to users when they asked, hey, I wanted to do this and it doesn't work well in the simulator. Can you edit? So I would just add whatever users asked me for. But then I sort of hit a wall when there were too many requests. Some of them are really big. Like, it would be nice if we have a debugger inside the browser. Why not?

Chris Gammell: Yeah. I may have been asking that at some point too.

Uri Shaked Wokwicom: Sorry. Sorry. I won't hold it up against you.

Chris Gammell: Okay.

Speaker ?: Good.

Uri Shaked Wokwicom: Yeah. But so now I'm trying to prioritize it by letting users vote so they can buy vote powers. And then use those vote powers to vote for features they care about. So right now the debugger is actually at the top of the list. And I've been working long nights to try to get LLDB, the LLVM debugger, to compile into WebAssembly so I can run it in the browser. Wow. Yeah. That's crazy. Yeah. It's, I mean, nobody does debuggers nowadays. I tried to contact some of the people who worked on LLDB and they told me, yeah, we would love to work in debuggers. But apparently nobody's interested in working on it. So we shifted to working on compilers.

Chris Gammell: Yeah. I can imagine there's not a lot of money in it. You know, like there's kind of the established players in the space and then there's GDB and all the, you know, those kind of things as well. And it's just like, I can't imagine there's a lot of greenfield happening there.

Uri Shaked Wokwicom: So yeah, GDB was actually my first attempt to circumvent the need to create my own debugger. So I did something really crazy that should never be done. And that was taking GDB, compiling it as an x86 Linux binary, and then using a simulator for x86 that's called V86 to run a Linux distribution inside the browser. So there's GDB Linux binary that runs on a virtual machine inside a Linux simulator in the browser. And that talks to the Arduino or Raspberry Pi Pico simulator through WebSockets to like establish a GDB debugging session. Oh my gosh.

Chris Gammell: Yeah, that's when I think Leonardo DiCaprio shows up and says, you know, you're too many levels deep. This is going to fall apart.

Uri Shaked Wokwicom: Yeah, and surprisingly, it works. There are a few hiccups, but the amount of effort to get this just to work was incredible. And whenever I have to make like, I want to update a version of GDB, I just keep postponing it because I'm always worried that something, you know, it works. Don't touch it. Right. Right.

Chris Gammell: It's a house of cards, right? It's just like, what might potentially have a dependency that moves away and then you're like screwed. Wow.

Uri Shaked Wokwicom: Well, yeah. There is actually even one more trick that I'm doing. So once you start this VM on your browser, I take a snapshot of the VM and then store it to your browser storage. So the next time that you run it, you don't have to wait like the 10, 20 seconds. It takes Linux to boot. Oh, wow. Yeah. So I actually had to learn how to cut down the Linux boot time. So it's crazy that you have to learn about optimizing the boot time of the Linux kernel and recompiling the kernel with different like options in order to get GDB to run faster in the browser.

Chris Gammell: That's crazy. Wow. Yeah. I'd like to quickly go back. I think the PWM example is really great. Can we do a quick session of kind of follow the packet or follow the code or I guess it's going to be multiple layers here. But just to kind of dive people down through these layers of abstraction and try and visualize where they are.

Chris Gammell: Yeah. Yeah. Go ahead.

Uri Shaked Wokwicom: Oh, I thought you would go ahead and then I will tell you.

Chris Gammell: So, well, let's start. Let's start in this. So if you open up walkway.com, right? So basically there's a Arduino left side. There's a editor on the left side. Looks like setup and loop. Very similar to people that have, you know, people that have done it before would probably recognize it. So if you go and you did a PWM sketch and you were driving, you know, you pulled an LED into the right side pane, which is a simulation that actually has you wire things up. And then you hit compile. What happens? So like there's a binary and it goes all the way down. So like what happens under the hood in each of those cases? So we've compiled a binary to say maybe 50% duty cycle on driving LED out of pin. I don't know. A five or can we do PWM on. So on like an Arduino, like a five pin, a five or similar. And then we're going to drive an LED with that. So like what happens under the hood then for each of these cases? Okay.

Uri Shaked Wokwicom: So you hit the play button. The first thing that happens is that your source code is going to send down to a server that is hopefully near where you are. And then it uses the Arduino CLI on that server to compile that source code into a hex file. And it's the same hex file that you would get if you compile the code on your machine and upload it to a physical Arduino board. As a matter of fact, you can even press F1 and look there for download compiled hex file and get this hex file and try it if you want to. So the hex file gets downloaded to your browser. And then the browser starts the AVR simulator, which goes over these hex files and starts executing the instructions. At some point, it will get to the implementation of the function analog write, which sets up the PWM in Arduino. And that function will write to the timer registers. So depending on the pin, that would be timer 0, 1, or 2 on Arduino Uno. And then the timer peripheral gets in action. So once you start writing to those registers, it actually calls functions in the simulation of the timer peripheral, which make all sorts of calculations to know when the next time the timer is going to shoot and what's going to happen then. So after a few simulated microseconds or milliseconds, the timer figures out it's time to toggle the pin. So it tells the simulator, hey, I want to toggle the specific pin of this simulated AVR chip. And then the simulator sees that this pin is now changing the state from, let's say, low to high. It checks everything that is connected to that pin. So all the other pins that are somehow wired to this pin, either directly or resistors or push buttons. And then it sort of tries to calculate the total state of that pin and everything connected to it. So it could be like that you have a few pull-up resistors and pull-down resistors. And you have to sort of see which signal you end up having on that set of pins. And eventually it figures out that, let's say, this whole set of pins is now high. So it goes to all the components that are connected to these pins, in this case, the LED. And it tells the LED, hey, your cathode is now or your anode is now high. And the LED then checks, okay, so my anode is high, my cathode is low. This means that I should turn on. But that's just one point in time. This happens like thousands of times for every second of the simulation. So what the LED does, it sort of takes a moving average of how much time the LED was on for each frame of the screen. And then it uses that moving average to draw the brightness of the LED. So if it sees like it was on 30% of the time, it will set the opacity of the layer that represents the light of the LED, not exactly to 30%, because it also applies gamma calculation. So that would be, I guess, something like 70%.

Chris Gammell: Okay.

Uri Shaked Wokwicom: But the opacity of that layer that represents the light of the LED that you see on the screen correlates to the duty cycle of the PWM. But it has to go through all these mechanisms because you want to simulate it as close as possible to reality.

Chris Gammell: Yeah. That's amazing. That's a lot of stuff in there. That is just like all the way up through the various levels of... And you mentioned like it's happening thousands of times per second. So what is the calculation that's... I guess, what is the layer that's actually handling the... I guess the physical layer? That's probably the thing I'm most interested in this specific example. So you wrote basically like a physics engine that's reevaluating at every... Not really.

Uri Shaked Wokwicom: I have no idea how to write a physics engine. So talking about timescales, the CPU simulator is like the actual simulation of the core is the most compute intensive part. For Arduino, it runs up to 16 million times a second. So it depends which instructions you are writing. You are using some instructions takes only one clock cycle. Some instruction takes multiple clock cycle. And at least with Arduino, the simulation tries to be cycle accurate. And that's really important for libraries like FestLED. Because if you look into the source code of FestLED... And for those who don't know, it's like a library very popular for driving matrices of LEDs, WS12, 08, and that sort. If you look into the source code and don't do it, it's really horrible. They have like handwritten C++ code that uses a lot of macros. And it somehow translates to very specific hand-optimized assembly instructions. So if you don't get the timing super on spot, then the signal that you will get for the NeoPixels will be off and they won't light up.

Chris Gammell: Yeah.

Uri Shaked Wokwicom: Yeah. So it has to be... At least for Arduino, I had to make it cycle accurate. So libraries like FestLED could work. And then there is like the... Whenever you toggle a pin, there is like this layer which tries to figure out what's connected to that pin and calculate the state of this whole like node in the network of the pins. Yeah.

Chris Gammell: That's great. I mean, yeah, that's... I think the cycle accurate stuff, like that's really interesting to me. First off, because I think the FastLED library, it's also a workaround to work within the constraints of the Arduino ecosystem, it feels like, right? So it's like C++ under the hood for this library, but then it's assembly to actually make it so that you can drive microcontroller to hit the specific timings you need. Because it's like a... It's like there's like a... WS2812 I know has like a long pulse, short pulse is like a zero, and then the opposite is a one or something like that. But it's just like how you have to actually go and drive that in the real world ultimately impacts your code. So that then feeds back up the chain in the library.

Uri Shaked Wokwicom: Right. And then when I was trying to debug the program that ran in the simulation using that GDB setup, because it didn't like work initially because I got something wrong with the timings for faster LEDs, it didn't work. And then I ran it again without the debug mode, and it worked. And it turns out that FastLED has such specific optimizations that they only work if you compile it in release mode.

Chris Gammell: Oh, wow. Any kind of like overhead just blows the timing out of the water, huh?

Uri Shaked Wokwicom: Yeah. And at some point I got a report that the code was not working on the ATtiny. And I was like, huh? But it's supposed to work. Like if it works on a physical ATtiny, it's supposed to work in the simulation because it's cycle accurate. So it turns out I measured the timings with my Salae on a physical ATtiny and in the simulator, and they were the same. But what happens is that the ATtiny is not fast enough to deliver the timings that are provided in the datasheet for those LEDs. So it turns out that the physical LEDs has some tolerances that are out of spec of the datasheet. So I had to make my simulation more lex so it would work with ATtiny. Oh, gosh.

Chris Gammell: It's art representing reality, representing art, representing reality sort of thing, huh? It's like, yeah. Yeah.

Uri Shaked Wokwicom: I mean, the datasheet says one thing, but then if you want it to work in reality, you just need to see what works in reality.

Chris Gammell: Yeah. Yeah. Yeah. I think, so you were also on the Embedded.fm podcast, I believe, and you also talked about this simulation of things. We will link people into that so they can go on. You talked about that when you were on with Alicia and Chris, right?

Uri Shaked Wokwicom: Mm-hmm. But another Chris, not you. That's right. Yeah.

Chris Gammell: Different Chris. Lesser Chris, really. Let's be honest. No, I'm just kidding. So I was very interested. So I think that's how I first heard about you. I had also heard when you were on Remoticon, you gave a talk at Hackaday Remoticon. So that's, you know, sometime around then is when I first started learning about Wokwe and your stuff. I think the thing that blew my mind the most, though, about all this stuff, right? This is under the hood. There's so much crazy, awesome stuff going on. But you and I got in touch and you told me that I could just run any generic binary on one of the things that you have here because it's a cycle-accurate CPU. And so I was like, okay, well, I'll try this out. And I took some of the stuff I was doing for my job at Goliath, and I took a Zephyr-based binary that I had built. And the ESP32 thing that you have also has a network connection. And it just worked, man. Like, what? Like, I uploaded a binary for an ESP32, and it connected, and it looked like it was connecting back to the internet. And like, so then you also have an internet portal through this thing for devices as well. Like, how does that work?

Uri Shaked Wokwicom: Oh, wow. That's one of the things I'm really excited about because that was the first time that I had to learn how Wi-Fi works, like how the actual protocol works. Because when I wanted to implement the Wi-Fi in the... Or let's take a step back. I started working on simulating the ESP32 because it's a chip that I used in some of my projects, and it's really capable. And I saw many users, especially from the FastLED LED community, which were early adopters of Wi-Fi, and they used ESP32. And I'm like, ESP32 is everywhere. How difficult would it be to support it? You know, just like the way I started originally working on the AVR simulator, the open source AVR simulator that eventually became the basis of Wi-Fi. I started one night hacking on the instruction set for the ESP32. That's the extensa instruction set. And I said, okay, I will just try to get Hello World or some link to sort of, not even run, but sort of give me a sense that something is going on. And gosh, the ESP32 is so much more complex than AVR. Yeah.

Chris Gammell: Yeah. Yeah. Yes. I mean, it's 32-bit, it's dual core, it's extensa. It's like, yeah, it's just, I mean, how much bigger is the instruction set than the AVR stuff? I mean, imagine that that's probably pretty sizable as well.

Uri Shaked Wokwicom: So the good thing about AVR is that they have great documentation. And extensa probably also have great documentation, but the instruction set manual, there is only one version that, as I have heard, it leaked. It's not like something they wanted to be publicly available. And it's good. It's not up to date. Some of the instructions do not even appear there. And there is like, for AVR, there are like all those forums, like AVR Freaks, where you can find answers to your questions because somebody has already asked the same questions millions of times. But for extensa, there isn't such a big community. I mean, even if you check out the compiler tool chain and I like the debugger and everything for the ESP32, Expressive have to maintain them. It's not like Arduino when there is like GCC built-in AVR support. They have to maintain their own form. So it's kind of much smaller and less documented ecosystem. But I think the most complex part for me was the Wi-Fi. When I got the ESP to finally show some signs of working and I uploaded an early prototype, people immediately asked, yeah, but we need Wi-Fi. Like ESP32 is all about Wi-Fi. And I was like, okay, it's going to be hard. And the reason it was hard is because unlike most of the ESP-IDF, most of their application framework, which is open source, the Wi-Fi isn't. It's like some binary that they link into the ESP-IDF.

Chris Gammell: It's like a binary blob. Exactly. So from the perspective of Wi-Fi on this device, I mean, does it get simulated? Is there an instruction for Wi-Fi? I mean, or is it more at a higher level with like registers and such?

Uri Shaked Wokwicom: So it took me a month of sleepless nights to reverse engineer their Wi-Fi driver. It turns out there is a peripheral for the Wi-Fi radio. So you write to certain registers. It uses the DMA to transmit the data. So the driver writes the Wi-Fi frames into a linked list of DMA buffers. And then it tells the driver. Yeah. Then it tells the peripheral, hey, send those out. It gets a bit more complicated because you have channels on Wi-Fi and you have to make sure like the radio is tuned to the right channel. So figuring out like all the magic constants they use there to convert from a Wi-Fi channel to frequency to whatever they use there internally was very tricky.

Chris Gammell: And does this mean that you are doing like disassembly of these binaries in order to find these magic constants and stuff? Like how are you doing this reverse engineering?

Uri Shaked Wokwicom: It's a combination of Gitra. So some guy who also tried to reverse engineer the SP32 Wi-Fi in the past extends a plugin for Gitra. So Gitra, for those who don't know, is a very powerful reverse engineering tool. It can decompile assembly into something that looks like pseudo-C code. Using Gitra, I sort of managed to have a way to look at what the code was doing. But then the other side of this was actually running the code in the simulator and seeing what registers it wrote to or which functions wrote to which registers. And I think the most advanced technique that I used and that was enabled by the simulator was sort of time travel. So I wanted to know what happened before I hit some breakpoint. So I just told the simulator, hey, record like every function call that happens in the simulated binary. And then I had this trace so I could sort of go back in time and figure out the flow that led to the breakpoint.

Chris Gammell: It's like picking up breadcrumbs and putting them on a map or something like that. You know, like you're basically kind of setting up yourself up for all of the mapped streets that you wanted to map in the first place by saying at the stop sign, go tell me where I just came from or something like that. I'm trying to think of an analogy. It's not very good, but... It's better than what I would come up with. It's impressive.

Uri Shaked Wokwicom: Thanks. The other side of that, there are already three, was just using GDB on the physical ESP32 chip. So whenever I got to a function that like indicated that a packet was received, I looked at the backtrace to see where it was, what caused that function to be called and where the packet, the frame was stored, the Wi-Fi frame was stored in memory. And I figured out it had like some weird header. So I could like record the stuff I got on the real device and replay it in the simulator and then see how it's get processed in the simulator and sort of look at the differences between the stack traces I got on the simulator and on the real device to find if a statement I was not hitting in the simulator, but hitting on the real device. It was a very, very stressful period.

Chris Gammell: Super, super iterative. A lot of repeat work, I'm guessing.

Uri Shaked Wokwicom: Yeah. And it's like I was only able to work on it throughout the night because it required a very long time span of focused work with a lot of attention to small details to figure out like all the pieces of the puzzle. So I really changed my schedule at that period when I worked on it so I could just sit whole nights and focus on it.

Chris Gammell: Oh, wow. That's, yeah, that's intense. So then, okay, so you figured this out. You figured out how it communicates with the ESP32 peripherals that represent Wi-Fi. But then it's actually, I mean, Wi-Fi talks to the other side of, so in your simulator, it's talking to the internet somehow. And then does that mean you had to write a Wi-Fi router? Or did you just then say, oh, well, I know that you're trying to do this packet transmission, so I'll just, you know, shove that into an internet connection then? Like, how do you actually rectify then with the actual connection with the internet?

Uri Shaked Wokwicom: Yeah, that was actually something I haven't figured out only, I only figured it out when I finished trying reverse engineering the Wi-Fi and I'm like, okay, now what? So the first step would be to simulate an access point. And that's where I had to learn how all like those Wi-Fi frames work or the association request, association response, because I had no idea about the internals of Wi-Fi before. And thanks to Wireshark and a few tutorials that I found online, I now know a bit better. So the simulator sends a probe request or the code that runs in the simulator, the Wi-Fi driver sends a Wi-Fi probe request and the simulator sends like the correct response and then they start an association process. So I had to write like all this lower layer of Wi-Fi myself. So the connection, the association with the access point would happen. And then for the next layers, which are like internet, TCP, IP, and whatever goes above it, I actually found a cool workaround. So there is network implementation, full network stack implementation written in Go that was published by Google. And what I'm doing, you can't run this in the browser because the browser won't allow you to open arbitrary internet connections to whatever. Yeah, you are pretty limited.

Chris Gammell: That would be bad for other reasons, right? That they don't want random code execution to happen in the browser.

Uri Shaked Wokwicom: Right. They wouldn't want the browser to contact your DNS server and exploit some vulnerabilities that you have there, right? Right. So the browser uses, opens a web socket to a gateway that I've written in Go. And that gateway uses that, I think it's called GVisor tab proxy or something like that, that package that Google published. And that package implements the entire like TCP, IP networking stack. And it has the HTTP server. If any of the listeners are interested, that part is also like open on GitHub. I think it's github.com slash walkway slash walkway GW, GW for gateway. So whenever you connect to the Wi-Fi, we open this web socket from your browser to either my server, or you can also run it on your local machine to this gateway. And that gateway implements kind of a NAT router that connects you to the internet or connects the internet to you if you want to go the other way around.

Chris Gammell: That's amazing. I mean, like there's so much stuff under the hood here, man. Like it's just like, holy crap.

Uri Shaked Wokwicom: And it's all connected with duct tape.

Chris Gammell: Yeah. Yeah. I mean, that's fine. But it's, you know, it's also free. Like that's, I don't know if I mentioned that yet, but like it's also free. Like all of this stuff, the fact that you're giving away for free. Like, so, you know, feel free to ignore this question, but like, it doesn't seem like this would be a small processing load. You know, you mentioned virtual machines and, you know, all of these different libraries that you're running, whatever. Does my using it as an individual user cost you a significant amount of money? Maybe we get into the business side of things too.

Uri Shaked Wokwicom: I mean, that's a question that people always ask. So it depends how you define significant. Most people think that the cost of the operation right now is a few hundred bucks a month. Everything, including the Wi-Fi gateway and the database and everything it runs on. And I've been working pretty hard to optimize that. Like if I was just spurring resources, it could get to a few thousand a month. But I think the real. Yeah. Right. I think the real cost is actually the engineering that goes into this. Like it's a lot of hard engineering work to build all those pieces and to put them together and then to make them easy to consume for the users.

Chris Gammell: Yes, totally. I mean, your time is definitely. And it's just you. Is that right?

Uri Shaked Wokwicom: So I started this project and right now it's on the technical side. It's me and Ariella, my life partner. We are working on the product. And then we have a few freelancers that help with content like blog posts and documentation and graphics. And I hope to at some point in time be able to hire additional engineers. But because like I've been doing engineering for so long, it's really hard to me to outsource that part.

Chris Gammell: Right. Right. Like splitting out the work and, you know, letting go of some of the control, all that kind of stuff. That's understandable.

Uri Shaked Wokwicom: I heard a podcast you had with Simone Yach and I think she had like the same problem, right?

Chris Gammell: Yeah, she talked about it from a video perspective. Like, so, you know, Simone has a lot of video type of work, but she's still like very involved with it. And I think that, and Dave, you know, Dave's mentioned that in the past too, right? Of like, you know, just kind of letting go of creative control or really, you know, any engineering control as well. Like it's just so you have to kind of trust people a little bit more and it changes the nature of your operation. And, you know, distributed work becomes less efficient, right? The most efficient thing is a one person team, but then you're limited by how many hours you have available to your work. So like, yeah, there's, there's always that trade-off. It sucks.

Uri Shaked Wokwicom: I know.

Chris Gammell: Okay. Well, people can join the club. I think that's a good start. So the WalkWeek club, basically, we already mentioned, like, if you join that, you get to help support the site. You can also vote on features. You can get faster and more stable internet access through the Wi-Fi. What is, what is that piece?

Uri Shaked Wokwicom: So as I mentioned, the Wi-Fi gateway runs on some server and then you're using that to get the ESP32 to connect to the internet. But for club users, we'll let you run this server locally. So it doesn't have to go through another place. And then it also means you can connect from your web browser to a web server running inside the ESP32 because the gateway is running locally. So you can do everything that you would be able or almost everything you would be able to do with an ESP32 that sits on your local network. It's like the ESP32 is on your local network.

Chris Gammell: That's super cool. Yeah, that's great. And so then that's like a, so that's the GW that you mentioned, like the WalkWeek-GW. That's like a daemon that would run on your local machine or in the browser? How does that run?

Uri Shaked Wokwicom: Yeah, it's just like a command line application that you run independent of the browser and then the browser connects to it. And then you can enjoy the Wi-Fi locally without having to rely on distant service and you can connect to your local network. And I think if there are like listeners who are more into like reverse engineering and protocols and that stuff, another interesting feature of the Wi-Fi is that you can actually download a packet capture file that you can open in Wireshark. So you can see like all the association requests and the association process and then all the DHCP handshake and basically everything that goes into network stack of the simulator. You can see it.

Chris Gammell: Yeah. So you mentioned the compiler, sorry, the debugger might be on the way or you're kind of grinding through that now. But what about other, you have other parts coming as well? I mean, like all of these things. One thing that's interesting to me is that, so you mentioned the ESP32 and the Extensa core and stuff like that. And then just like, ho-hum, then there's also the S2 and the C3, which means that you also have a RISC-V simulator on here as well.

Uri Shaked Wokwicom: Yeah, that's true. Oh, finally somebody noticed.

Chris Gammell: Yeah. That's non-trivial. So that means you have, so let's see, Arduino, so there's the AVR simulator, there's the Extensa simulator. You must have an ARM Cortex-M0 simulator. You have a RISC-V simulator. What else is on here? Anything else? I mean, that's a lot. Don't get me wrong.

Uri Shaked Wokwicom: There is also an Cortex-M4 simulator that is on the way. It's sort of working already.

Chris Gammell: That's the early access list that I signed up for. Yeah. Yeah.

Uri Shaked Wokwicom: I mean, the first chips we are trying to use that core with are the STM32, even though I'm actively looking for interesting chips that use the Cortex-M4 to simulate. So if there are any people who have a good business reason for me to add those chips, I would love to talk to them.

Chris Gammell: Oh, man. I, you know, I love the NRF52840. That's a Cortex-M4, but that would be a whole nother. You want to go do another protocol stack and Bluetooth or Thread? Oh, I don't think that's bad.

Uri Shaked Wokwicom: Well, give me a good business reason and we'll figure out how to make it work. I mean, it's fun working on this stuff, but it's just a lot of work. So I have to find a way to justify it.

Chris Gammell: Totally.

Uri Shaked Wokwicom: And I think in terms of what's coming to WorkWe, the part I'm most excited about right now is, and this is also like in prototype, so people can come and play around with it, is the ability of users to create their own custom parts in the simulator. So it's called custom chips and there is a C API that you can use to implement your own chip. And it feels like writing sort of embedded code. But it's kind of from a weird perspective because you are not running embedded code that implements a firmware for an application. You are running an embedded code that sort of simulates peripheral like an ISC or C-express.

Chris Gammell: Yeah, you're like writing a mock basically for physical hardware, right? It's like you're writing the UART driver or whatever. It's crazy.

Uri Shaked Wokwicom: Yeah. And I've seen like some stuff that people created with it, with just a prototype. And I'm like, wow, I'm really starting to like where this is going.

Chris Gammell: Yeah, because then, so then the idea would be like, so now, okay, so I mentioned NRF 52.840. That's got a bunch of custom peripherals that don't exist in the STM32, for example. So now basically a community member could be like, you know what, I want to tweak this so that it's a little bit more accurate towards the NRF 52.840. They could go and write this kind of meta C code that could go and target the ADC that's a little bit closer to the actual behavior. Is that the thought process there?

Uri Shaked Wokwicom: It could get into that as well. Well, right now the idea is that you write parts that are not parts of the processor. So for instance, you want to implement some I2C expended chip. Got it. Or I think a few cool examples that users have already implemented is I2C keypad driver. So you have like these keypads that you have to scan continuously. What if you wanted just to have a chip that you can speak to through I2C? And specifically, I think there are a few chips that already do that. So you can just take the data sheet and simulate that. Or if you wanted to add some, I don't know, custom ePaper display to the simulator, you could do that.

Chris Gammell: Huh. Yeah. Yeah. So then this would be, so you're mentioning this is C code, but like all of the visualization piece, that's all JavaScript. So then would you then need to write the layer on top? So like the ePaper is a good example, right? So ePaper is going to have some display element to it. It's going to show some, you know, you write to the registers and then it flips the required bits and it says hello world on it. Right. Right. When does that code written for displaying hello world on the actual browser, how do you get that involved?

Uri Shaked Wokwicom: So with display there is, or with chips that implement display drivers, they have what I call frame buffer API where they can supply pixel image like a bitmap to the JavaScript code. And then the JavaScript code rolls out to the script. Ah, okay. And the way this works behind the scenes, your custom chip code gets compiled from C to WebAssembly. So it's something native to the browser and the browser just internally translate this WebAssembly into efficient machine code for the machine you are running on. So whether it's a PC or new M2 laptop, it would translate it to the correct instruction set. So it should run pretty fast. So it's sort of a strange hybrid. It feels like you are programming, you're writing a firmware, but you're actually writing code in WebAssembly that implement some peripheral, which is something that I don't think there is. This concept doesn't really exist. Like, I think for the most part, people are used to use Verilog for writing simulation models for specific pieces of hardware.

Chris Gammell: So then do the people that are writing this code, they don't need to know WebAssembly? They just need to know C?

Uri Shaked Wokwicom: Yeah, it's like, I mean, the API for, it's still very much in flux, but the API for like, if you want to implement I2C peripheral is like I2C in it, and then you pass it like a structure that includes a list of callbacks. So whenever somebody connects to your profile, whenever they read a byte, and whenever they disconnect, you give it like the, you also have like fields where you can specify the STL and SDA pins. And you give it like context. And then whenever it calls those callbacks, it passes those, this context, so you can pass additional information. So it's very similar, I think, for how you would write firmware code that implements an I2C peripheral.

Chris Gammell: Yeah. You can see. That's great. That's great. I think that definitely, because that is probably going to be the people that are most interested in getting close to the hardware, that's kind of like the world they live in. Instead of being like, well, go learn JavaScript or WebAssembly and come back when you're ready. Yeah.

Uri Shaked Wokwicom: So the first iteration of this custom chip API was in JavaScript. And then the feedback I got from developers is, we don't want JavaScript, we want C. And that's why I switched to use C that compiles to WebAssembly.

Chris Gammell: And could you explain WebAssembly for, I've heard of it. I don't quite get it, though.

Uri Shaked Wokwicom: Okay. Cool. So if you know the JVM, the Java virtual machine, or the CLR, the .NET runtime, it's pretty similar in nature. It's sort of a virtual machine, stack-based virtual machine that you can compile a variety of languages to. So I think C++ and Rust are the most common languages that are compiled to WebAssembly, but you can also compile Go, and you can also compile a specific dialect of JavaScript that's called AssemblyScript. And there are a few other niche languages that you can, I think Zig also compiles to WebAssembly, if you heard about that language. And then this WebAssembly is sort of binary that has this virtual machine. So what happens is that the browser loads this WebAssembly binary, and it does two things. First of all, it does a bunch of validations to make sure that the code in the virtual machine is never reading from a memory that does not belong to that piece of code. So to ensure the sandbox security of the browser. And then once, so it's a stack-based virtual machine. So the browser has like all these checks to make sure that you never overflow or underflow the stack. And after it ensures everything is balanced, it translates the WebAssembly instructions into machine instructions like of your architecture. So x86 or ARM or whatever. So when the code runs, it ends up running not as interpreted code, but as translated code. So that's much faster.

Chris Gammell: Basically because it's doing that translate. It's like a universal translator for your actual processor on board instead of doing like an interpreted language that's at a very high level.

Uri Shaked Wokwicom: Yeah. Similar to what you have with .NET and the CLR. I think one of the most common misconceptions about WebAssembly is that it's faster than JavaScript because people think about JavaScript as interpreted language. Which used to be true. But nowadays there is a very powerful just-in-time compiler. And I actually spent a week trying to convert the extensa core simulator for the ESP32 from JavaScript to WebAssembly. And it turns out they run roughly at the same speed. Because for some payloads where you have, I would say for stuff like command line tools where you have a lot of code that is running and has to be translated from JavaScript to optimized machine code. So then the price you pay for doing that translation every time you're running the command line tool is pretty big. But if you think about it, the simulator for extensa is a bunch of functions that just run repeatedly. So after a few milliseconds, the CPU or the JavaScript runtime realizes that this is like the host code and translates those few functions. So you sort of pay a penalty at the beginning of the simulation. Like, I don't know, a few hundred milliseconds until that code gets translated. But once it's translated from JavaScript to optimized assembly code, then it's basically the same result as you would get from WebAssembly. And that was something really surprising for me. I hope that I would be able to speed up the simulation once I translated the engine to WebAssembly. Not happy.

Chris Gammell: No. Yeah. Okay. Interesting. How much of it... So this is all running in the browser, obviously. And I know this is going to sound stupid, but my question earlier about server costs and stuff like that, too. I always thought Wordle, you know, Wordle is like this global phenomenon around like... And I was like, oh, man, he's got like millions of users. He sold it. He must have had like crazy server costs. But then I was reading an article about it. And he's like, well, actually, it's a really small program, but it runs actually completely in the browser. And there's very little like server interaction. So the server cost was just delivering new downloads of the software itself. And so like how much of this is actually running... I guess this is a lack of knowledge of how JavaScript and browsers work anyways. But like how much of what the simulator is doing is running in the browser versus like talking back to the server? Is it mostly in the browser?

Uri Shaked Wokwicom: So this is a question I get asked all the time. It's a great question. Because people tend to think that this can't be done in the browser. So they tend to think there is like some process that is running the simulator on a server. But no, once the hex file or the compiled file gets into a browser, everything runs in the browser.

Uri Shaked Wokwicom: Or if you load a MicroPython program or a local hex file, then nothing goes through the server. It's all in your browser. So when you start like a MicroPython project in WorkWi, WorkWi goes to the server, downloads the pre-compiled MicroPython firmware, loads it. And then it just... After that, it did it once. Whenever you run a Python project, it just loads that firmware into the simulator. And everything is happening in a browser. There is nothing that involves the server.

Chris Gammell: Huh. So is that... That's just true for MicroPython because it's interpreted versus something else? Or why did you call out MicroPython specifically in that case? Is it... Do some other ones have more server interaction?

Uri Shaked Wokwicom: Just because MicroPython is interpreted, then you just need... Think of it... I would say the best way to think of it would be to think... When you develop locally with Arduino, you have to compile and upload the code each time, right? But when you use MicroPython, you just load MicroPython once into the board, and then you can interact with MicroPython and update your program without re-uploading MicroPython itself every time. And more importantly, for the purpose of server costs without recompiling MicroPython every time. Right, right. Okay. So another good example...

Chris Gammell: So it's just that single binary download, like you said, and then it all just happens...

Uri Shaked Wokwicom: In the browser, yeah. Or another example is now we started working on adding Rust support for the ESP32. And Rust is a compiled language, and the compiler is pretty demanding. So that one actually adds a lot of... Like has a lot of potential server costs. If people started compiling heavy Rust binaries to run in the simulation, that would cost a lot. Because we have to run those compiler processes and pay for the resources.

Chris Gammell: Yeah, and this is actually... So I had asked you at one point about like Zephyr as well. I was doing some Zephyr stuff, and I think you even did an experiment where you had like a containerized Zephyr where you were showing a compiling. And it was like very slow because the Zephyr toolchain is monstrous. But it was in that same scenario. It was running remotely. It wasn't running in the browser. It was running on some like remote container, right?

Uri Shaked Wokwicom: So the compilation was running at the remote container, but once it's compiled, it runs in the browser. So even for Rust, there are like ways to speed up the compilation. And at some point, I even looked into running the compilation inside the browser. The thing is, I tried going two ways. First of all, the way I did with GDB, which is running a virtual machine in the browser and then running the toolchain inside that virtual machine. But then it's super slow because you're running the x86 simulator and compiler is resourceful. So for instance, just compiling link for Arduino takes around two minutes. If you go with a virtual machine approach, virtual machine in the browser, and it also takes like 20 megabytes of downloads. And that's the other problem. Usually those build systems and containers are really heavy in terms of download. You wouldn't want the user to download like half a gigabyte and running in their browser. It doesn't make sense. It doesn't work.

Chris Gammell: Yeah, this is something that so like I've been working on some like trainings. I think I sent you that article I wrote, but like I've been working on some training stuff. And like I have like a remote container where I actually have the toolchain pre-installed. And it pops out a binary. So that actually is like really beneficial to work with WalkWe, right? So I could like download the binary, load it up into the local browser, that sort of thing. But still, it's like the remote resources are on some like random ass server who knows where. You know, it's like some digital ocean server that I pay for and you get what you get then, you know. But there is a significant cost associated with that sort of thing. And that's at a single scale versus what you're talking about. If you have now 10,000 Rust users that want to do that sort of thing, it could really start to add up in terms of cost.

Uri Shaked Wokwicom: Yeah, so there are a few tricks that can really help. One of them is caching. Most of the people who are using the simulator will probably start by opening a link to an existing project and just running it. So there is no reason to recompile it every time. And then also caching at the compiler level. And we're partially doing it because if you are compiling an ESP IDF project, that's around 1,000 files that you have to compile. But you don't have to recompile the entire ESP IDF every time you make a change, right? You can just compile the files that you changed.

Chris Gammell: That's right. Yeah, just the incrementals. Yep, totally. Yeah. As long as you don't say clean build or whatever the command is on the ESP command line, right?

Uri Shaked Wokwicom: Yeah, and then it also adds another layer of complexity because you have to manage this cache and make sure the right user gets the right cache. So sometimes I do wish that I only made a simulator and not the entire platform because then I wouldn't have to worry about compiling and about scale. But then there are already numerous simulators out there. I don't know if you are familiar with Pixim Lab, which is quite impressive.

Chris Gammell: I don't think so.

Uri Shaked Wokwicom: It's a Brazilian guy called Luis Gamboa and he has made a pretty impressive simulator. You can run AVR, PIC, STM32, and ESP32 through QEMU. But then the user experience is still that you have to download the software to your computer. You have to install the toolchain locally. You build your own binary.

Chris Gammell: You have to trust downloaded stuff from SourceForge.net. I was like, oh, wow, SourceForge. Yeah. There is a name I haven't heard in a long time. That's true. That's true.

Uri Shaked Wokwicom: How many projects do you have on SourceForge, Chris? Your own projects?

Chris Gammell: I have no SourceForge projects. I just download shady Windows binaries from there and just cross my fingers and be like, you know, is this the one that's going to get me? Who knows, Uri? Who knows?

Uri Shaked Wokwicom: Yeah. I think the kind of people who upload stuff to SourceForge, I think they are too niche to be malicious. But who knows?

Chris Gammell: Yeah, probably. Probably. Yeah. Yep. Downloaded some shady software in my time. That's all I'm really trying to get at.

Uri Shaked Wokwicom: So, yeah. So, I would say it's, again, it's like engineering is always about trade-offs. And I always have this trade-off whether I want to implement more of the development environment, add a debugger, implement better editor, and make the browser environment better, or spend my time improving the simulator. But the feedback I've been gathering so far shows that there is a lot of value in this integrated solution where you can just send a link to somebody and they hit play and it just works. They don't have to worry about downloading, setting up things. It simply works.

Chris Gammell: Totally. I had an interesting interaction with someone recently who was working at a big chip company and they're like, look, we can't get dev boards right now. How do we showcase our product when there's a 10-week lead time on a dev board and I need to be able to send them something else? And it's like, oh, yeah. That's how they make sales at chip companies. So, yeah.

Uri Shaked Wokwicom: Make an intro. I would love to talk to that person.

Chris Gammell: Yeah. Right. Yes, I will. That's still on the to-do list with that one specifically. Yeah. I think some of it is going to be grumpy hardware engineers who are like, oh, it's not real hardware, blah, blah, blah, blah, blah, blah. But I think once they try it, I think they'll see the accuracy piece. And I think the important thing with simulations too is the most accurate simulator is never going to cover 100% of all test cases in the real world. It's impractical and it just doesn't make sense. And I think one part of the engineering discipline is understanding where some of those limitations are, what you're willing to accept. And then some of the risk mitigation around like, oh, well, what if it is different? And so I think about my early days with LT Spice and just kind of learning what I should be simulating. How much should I try and simulate a precise part versus kind of a more generic, just a diode or just an end channel MOSFET. That was a big shift for me, but it's pretty important, I feel like, in my engineering evolution.

Uri Shaked Wokwicom: Yeah. I think if I had to draw the line in Walkwee, I'm trying to make it, at least that's my focus right now, to make it so if you wanted to check or to work on the software part, then Walkwee would be a good fit. If you wanted to work on the electronics part, you would probably want to use a spy simulator or some more specific tools because I wish we could do everything, but it's just impractical. So Walkwee is great for simulating the software part and for the electronics. Well, good luck with that.

Chris Gammell: Right, right. But I think that there's so much of like, you know, so if I go and have a generic I2C device or spy device, you know, maybe you don't have every specific sensor that's available in the world and don't have everything, you know, obviously a growing list now with this new feature, but, you know, maybe you don't have every sensor available, but I could go stick in a logic analyzer on the I2C and be like, oh, that's the expected, you know, write this value to go and access a register, go and access the register, get readback, that sort of thing, and having like a generic logic analyzer readback. And you could start to generate pretty interesting. You could, you could do some interesting testing on the software piece, which is like you said, is the kind of the target, the target use case and still see what the output will approximate in the real world.

Uri Shaked Wokwicom: Right. And one other thing I'm sort of trying to figure out is the use case of automated testing. So what if you wanted to, then you have like written a piece of code and you want to automate testing it right now. I know most people just don't do it because it's pretty complicated to do with real hardware.

Chris Gammell: Yeah. And so instead of like setting up a, you know, you could do like, so we've had past guests on the show, like blue clover and, uh, uh, crap. What's the other one? Uh, I was just, just thinking of the other one, but basically, you know, hardware in the loop style testing. I'll see if I can remember who it was and. You know, you could actually go and like run your code on an actual real world device, but maybe a walk, we, you know, end, end device and testing your code. When you, when you do a new build that might get you 98% of the way there. And that's, that's enough for before you take it to a integration level test.

Uri Shaked Wokwicom: Exactly. That's where I'm trying to aim. I can give one example from my personal experience. So two years ago, I worked on a pretty mean hardware riddle called the skull. And it had an 80 tiny, uh, 45 chip that runs an open source framework. And despite the firmware being open source, it had a secret hidden inside. And you had to figure out a way to extract this secret from the skull and, uh, reprogram the skull through a mysterious interface to do things it wasn't supposed to do.

Chris Gammell: And skull, you're saying, you're saying skull, like a human skull, like, like the bone structure inside my head. Exactly.

Uri Shaked Wokwicom: And I don't want to do any spoilers, but when I had to develop the firmware from the skull, I had a thing where I didn't have the option to do field updates because once somebody gets the riddle, it already has like the firmware inside with the secret. And if you like had to re-upload the firmware, then you would override the secret. You would have to erase the chip and remove the secret. So I had to get it right. And there is some analog stuff going there. And the firmware had to do a bunch of calculations. And again, I'm trying to find a way to tell the story without too many spoilers, but I had to test this in a lot of different, uh, conditions. I would say I ended up having a list of 40 different test cases. And each of those tests took like, uh, two minutes to perform. And you can imagine like doing this manually. So what I ended up doing, I just performed each of the tests once in the physical environment with, uh, my, uh, Sully logic analyzer, recorded that, and then use the simulator to just simulate all the 40 test cases. So I had a setup where whenever I made a firmware, a change to the firmware code, I would get a result in five seconds. So imagine like 40 tests that take two to three minutes manually to perform each. All of that compressed into five seconds. How, how, like the feedback cycle went from half a day to a few seconds.

Chris Gammell: And like each, each individual, so you said two to three minutes times 40, but some of the, was there setup time in between each test as well? Like even just like hitting a key or something like that, or like moving wires around?

Uri Shaked Wokwicom: Uh, it's even, uh, moving to different rooms and waiting for different, for different times of the day. So at day at night. So, and all I wanted to do was just tweak a few numbers in the firmware to find a combination that works best in all the scenarios. So you can imagine like the, how happy I was that I had this tool to just simulate everything instead of manual labor.

Chris Gammell: Yeah. Yeah. I think, uh, it's okay to do it once or twice, but then, you know, I think the other thing is that like, there's human error that like comes into there. So like, this is just a perfect place for automation.

Uri Shaked Wokwicom: And I'm really good at human error. Like I'm very bad at.

Chris Gammell: Yeah, me too.

Uri Shaked Wokwicom: Yeah. I'm very bad at like working, uh, with like documenting each step. I'm just doing something and then, yeah, I will remember it. I will write it down and then I forget. And then I have to redo it. And then even if I like follow some method, I'm always unsure whether I did it right. Maybe I got the numbers wrong. Maybe. So, yeah. So it's so error prone. And I think without the simulation, I would have never delivered the scale in time.

Chris Gammell: That's crazy. I did look up the other person. I was thinking it was Akbar from logger data. So that's another people that are doing hardware in the loop, similar kind of stuff. We've also had the Salier guys on here, but I think I'm not sure how much they were doing back when we had Mark and Joe on. I'm not sure that they were doing a lot of like capture type stuff like that. They've introduced their, like their ecosystem where they have plugins for Salier stuff now as well that I'm not sure they had that when they were on the show, but I'll, I'll link that in as well. Rui, this is an amazing tool that you've built. I am really excited for this and the future of it. How can people sign up for it? How can they support you? Where should they get started? How can they reach you? All of the things.

Uri Shaked Wokwicom: All of the things. All the things. To play around with the tool, go to walkway.com. And then once you figure out it's confusing or hard, or you don't know where to go, or you just feel that the UX is crappy, hit me on the Discord server, walkway.com slash Discord and tell me what to improve. I'm really looking for feedback, especially, especially if it's actionable feedback that is delivered in a good way. I'm sort of like you mentioned Dave, Dave's tweet the other day. So I was really happy to see his tweet and how we found Walkway charming, but it seems to me like it's always hard to get people to tell you about the things that they really don't like, or they feel that could be better. I don't promise to act on every piece of feedback, but I want to at least have this feedback. So I have the chance to understand how other people see it. Because from my point of view, there is a lot of work and a lot of rough edges that should be improved, but maybe other people see it differently. And I just don't know.

Chris Gammell: Yeah. I think a thousand people are told about a thing, you know, like what is the percentage that are actually going to click through and actually try it and give it a real try? And then like of that, there's going to be some vocal group that actually like gives you feedback. And so it's just about like getting the maximum number to take a fair shot at it at the beginning. I feel like that's a really important thing. Actually, I was thinking about, I was asking at the beginning about where people should start. And I think my eye always goes towards the boards that are at the top, which are basically kind of like blank slates. But I would actually recommend that people click more Arduino library examples, because that usually calls out the library and has a pre-configured piece of hardware, something like a DHT sensor library, which is a temperature and humidity sensor. And basically it will already be hooked up. And then you can just immediately run the code that's like the test code that's there. I feel like that's an important thing for really getting people started quickly.

Uri Shaked Wokwicom: Okay, so I take that feedback and there is a good chance that by the time the episode will be up, the homepage layout will change a bit.

Chris Gammell: Okay, look at that. Yuri is incredibly fast with feedback in general, like you said, when it makes sense. You do a lot of work, it sounds like, like a lot, a lot, a lot.

Uri Shaked Wokwicom: I try to keep it as fun as possible. So I try to avoid the parts that I less like or find a way to make them more fun to me. I think that's my approach to this, like how to stay on top of things, except for the SP32 Wi-Fi. That was a crazy story, but usually I try to stay sane. Yeah, that's good.

Chris Gammell: Yeah, I think, and you know, I think the way people can help out as well is make examples, share them with other people. You can share the links, you can just share links to things that you've built. And that kind of helps Yuri and Walkwe to, you know, spread the word of it. So as you're building things, share them with other people. And that will also help for people to understand what Walkwe is and how you're using it.

Uri Shaked Wokwicom: Also share them with me because I'm always amazed to see what people are doing with Walkwe. And especially, like, I see so many projects that are yet another blink or yet another print hello world to LCD. But every once in a while, somebody sends me something remarkable. And I'm like, yeah, I want more of this. So do remarkable things and send them to me, please.

Chris Gammell: Okay, that sounds good. That is a good way for people to, a good task for people listening here. So go try out Walkwe, do interesting things and send them to Yuri on Discord or otherwise. Yeah, break it. Yuri, thanks so much for, yeah, break it. Break it all. Thank you for being here today. I really, I really appreciate it and taking the time to talk to us. And I'm looking forward to seeing more of what you built.

Uri Shaked Wokwicom: Thank you, Chris. Thank you for joining your podcast today. Bye-bye. Thanks.

Chris Gammell: We'll chat soon.

Chris Gammell: Bye-bye.

Speaker ?: Bye-bye. Bye-bye. Bye-bye. Bye-bye. Bye-bye.