396: Untangle the Mess
Transcript from 396: Untangle the Mess with Uri Shaked, Elecia White, and Christopher White.
EW (00:00:06):
Welcome to Embedded. I am Elecia White alongside Christopher White. This week we'll be talking about simulating processors and boards with Uri Shaked.
CW (00:00:17):
Hi Uri, welcome.
US (00:00:19):
Hello. Thank you.
EW (00:00:22):
Could you tell us about yourself as if we met at an embedded systems conference?
US (00:00:30):
Oh, well, for that we would need to actually go on an embedded system conference. Let me just imagine the situation. You are standing next to a booth where they show some kind of future technology. And then we are both looking at this technology and starting to talk about it. And if you have some idea what it would be then tell me. And you ask me, "Hey, what are you doing in this conference?" And I'm like, "Hi, I'm Uri, and I love learning about technology and seeing how I can do creative things with it, taking it to the limits." I think that's it. I will probably let ask you about yourself at that point and let you continue asking questions to figure out what part of my personality or interests you are most interested in.
EW (00:01:37):
Well, that's going to work out well because now we want to do lightning round where we ask you short questions and we want short answers. And if we are behaving ourselves, we won't ask. Are you sure, and why and how. Are you ready?
US (00:01:51):
Yes.
CW (00:01:52):
Favorite food?
US (00:01:56):
What was that?
CW (00:01:57):
Favorite food.
US (00:01:58):
Favorite food. Good food. If it's tasty, it's favorite.
EW (00:02:04):
Favorite processor?
US (00:02:07):
Favorite processor, I think might ESP32.
CW (00:02:15):
Emulator, simulator or other thing that ends in -ator?
US (00:02:19):
Terminator.
EW (00:02:23):
Complete one project or start a dozen?
US (00:02:26):
More than a dozen.
CW (00:02:28):
Samba or salsa?
US (00:02:31):
Salsa, of course.
EW (00:02:33):
Favorite fictional robot?
US (00:02:36):
Wall-E comes to mind. He's cute.
CW (00:02:39):
Do you like to listen to music when you're working?
US (00:02:41):
Yes.
CW (00:02:43):
Yes. What do you like to listen to?
US (00:02:45):
I knew that would come. It really depends. Sometimes it's upbeat merengue music, which if I need to really get into the zone and if I need to just enjoy what I'm listening to so that would probably be some type of jazz, salsa like Sofrito from Mongo Santamaria. That's one I listen to a look nowadays.
CW (00:03:21):
I would talk about Latin music on this podcast, exclusively and we could just do that because it's one of the most difficult things I've ever had to deal with on drums and I still can't figure it out, it's just so complicated and hard, but it's so amazing. But anyway, this is not what the podcast is about.
EW (00:03:35):
We should actually get back to that because he has something related. One more lightening round question. Do you have a tip everyone should know?
US (00:03:43):
Yeah, actually something pretty useful I figured out lately and then I shared it in one of the courses that I did and everyone was well, so maybe it will be useful for the other engineers listening here. If you go to any repository on the GitHub site and you press the dot button, the period button on your keyboard-
EW (00:04:05):
Yes.
CW (00:04:07):
It's the best. Go on, I'm sorry.
US (00:04:09):
So you already know.
EW (00:04:11):
It's still great tip.
CW (00:04:13):
Tell people the tip. It's awesome.
US (00:04:16):
Suddenly the screen, the static page with the GitHub file suddenly replaces with a full screen code editor where you can see everything jump between files, search, syntax, highlighting. Do anything you will do in editor and it happens in just an instant.
EW (00:04:36):
Yes. I love that. Okay. But we have asked you here to talk about Wokwi. Is that how you say it?
US (00:04:46):
You pronounced it right.
EW (00:04:50):
First, where does the name come from?
US (00:04:52):
I get asked that all the time. The story behind it is that there is no story. It just I was looking for a short name that would be easy to pronounce and wasn't used by anything else in the world yet. One night, there is a website where you can enter a set of constraints, I just went there and said I want a name, five or six letters long with two vowels. And then it looks for available domain names and shows you a list of all the ... You have many pages of possibilities and then it just went through 50 pages of possibilities and eventually I shortlisted a few and Wokwi was the one that sounded, I guess, the least strange out of that list.
EW (00:05:55):
Okay. I have been teaching a course about embedded systems, and I recently asked students to write a flash simulator for testing. And they hated me for that, but I've been thinking a lot about simulators and that's what Wokwi is. Could you tell me about what it does?
US (00:06:17):
Yes, of course. Wokwi is basically just like the magic where you go to GitHub press the period and then you get a full blown code editor. That's the kind of experience I'm eventually aiming to create where you can create simulation of a complete project with the code and all the parts and you can just send the link to somebody and they open it and boom, they can run your project in their browser without having to download or install anything or to buy wires and connect them and then fry their micro controller because they connected the 5V to ground. You did that, right?
EW (00:07:10):
Of course, I've done that. When I open it, I clicked Arduino Mega as one of the boards to play with and it opens INO-style setup and loop file that I can type into on the left. And then on the right, it has the Arduino Mega board and if I click on things, the plus button I can put in key pads or buzzers or LCDs, and then I can just hook those to this board. And it works. I mean, as though my wiring was perfect the first time, and I haven't blown up any boards at all, and if it isn't, I can play with it until it is, and I don't have to use a soldering iron. Why did you make this? I mean, it's very cool but why?
US (00:08:07):
Thank you. Wokwi started as something completely different. I started working on a service where you could create your own customized Arduino Uno boards. If you want an Arduino Uno but with USB type C connector, instead of the bulky printer style USB connector. And you wanted pink for some reason, even though pink wasn't in the option. So you wanted blue with green connectors and your own logo, and you also want to add an accelerator metaphor into it. That was the first version of Wokwi. And I started working on that product. And eventually I realized I would need to market it somehow to get to potential users. I started writing a blog and writing about Arduino. I think my first blog post, there was five ways to blink an LED in Arduino.
US (00:09:14):
And it's still a pretty popular blog post. But when I wrote this blog post, it felt weird to me that I can include code examples but then if you actually wanted to try those code examples, you have to find an Arduino board, connect an LED, plug it into your computer. Then if you don't have the setup, download Arduino ID, fight with drivers. And eventually, hopefully, see while I run the code from my blog post. And I'm coming from web development background. And in web development, we have this concept where you have live documentation. You have documentation about something and there are code examples and you can just edit them and see the results. And I was like, "Can we have this in hardware too, pretty please?"
EW (00:10:13):
But you didn't just simulate the board you actually simulate the processor in assembly and stuff, right?
US (00:10:26):
Right. I started with something that was even not simulating the board. So if you go back to that very blog post about five ways to blink and LED and Arduino, there is a section that talks about timers and they had this small simulation written in JavaScript where you can see how the timer is counting these clock cycles and how the different Arduino timers have different resolution, eight bits and 16 bits. The first kind of simulation I did was that, but eventually I figured out that if I want this to be useful to other people, then it has to be the whole thing. I mean, I can create things as needed for my own blog post, but if I want it to be something everyone can embed into their documentation, blog posts or even use for other use cases, which we can talk about if you have some ideas, then it has to be that. It to be the entire thing.
EW (00:11:42):
But had you had much experience with simulating micros before? Simulating processor cores?
US (00:11:52):
No, it was my first time. I actually simulated a processor core. I mean, I guess in the past I did write some compilers when I studied computer science and that kind of stuff. But I think my first relation was how little of the AVR, the core of the Arduino, how little of the AVR functionality I actually had to implement in order to get blink working. I was thinking I would have to work very hard to get there, but then I realized most Arduino programs aren't using all the obscure features of the micro controllers. If you have most of the instructions set, even not all of it. And for blinking is just the timers and a bit of GPIO, it works.
EW (00:12:53):
And how long did you end up spending with the AVR core reference manual?
US (00:12:58):
I mean, I still read it when I go to bed. But seriously, this is the only good way of source of information other than Arduino libraries that interface with the micro controller? Whenever I implement a device, not just a micro controller core, but even shift register or something like that, I spend about half of my time reading through the data sheet and then the other half goes to reading source code or libraries that use that device to understand which parts are actually used by the libraries and in which ways, because sometimes the data sheet, for instance, if we go back to AVR, there is the DWI, 2R interface, and it has a pretty complex state machine. And it can be used with interrupt and without interrupt. And you can spend days implementing all of the things the data sheet says, sometimes it doesn't even specify all the edge cases, but then you could also just look at how the libraries use it. If we work with Arduino, then let's check out how the Arduino core the wiring library uses the DWI interface and focus on that part.
CW (00:14:37):
I'm very impressed that you just decided to do this from scratch. I think I would've looked at QEMU and stuff, but that probably wouldn't integrate well into a web application, to use some package like that.
US (00:14:50):
Yeah. I think there are some existing projects also for AVR specific. I think QEMU doesn't do AVR because it's an eight bit architecture and it's pretty different from other 32 bit architectures in some aspects, but there are like sim AVR and there are a few other open source and great AVR simulators. But then the thing is you can compile them to work on the web, but if you really want to have a good control of how everything connects and you want to be able to tune the performance as needed, you really need to be familiar with the internals.
US (00:15:39):
I haven't tried that, but it's sort of a trade off, either you work on something from scratch and then you know everything about it, and you can look the other implementations, if you get stuck to get some ideas how to implement stuff, or you can really study other code base ... An existing simulator thoroughly and get to the point where you really understand how everything is connected and then I think, in both cases, you'll probably be in the same position where you can make any change that you want, but then if you write it from scratch, then you are not bound by the decisions or the architectural decisions of the original maker. That might be an advantage. I don't know, because I haven't tried, but that's what I think.
EW (00:16:42):
At what point did you go from, I'm going to simulate a little timer and then I'm going to simulate the Arduino enough to talk to some of the libraries to, oh, the heck with it, I'll just start simulating all kinds of processors.
US (00:16:59):
The first part going from timers to a full blown AVR core was pretty quick. I would say a few days. It was more like, "Can I make it? I want it. Can I make it happen?" This generic Arduino simulation or AVR simulation library that runs in a web browser. And then I spent, I think two or three days just, I think it was a weekend. I can check in the Git commit history, but just hacking code like crazy and trying to get just blink to work and figuring out how to load hex files and how to map everything. I was trying to connect all the pieces together just to get something that can run blink. And then a few, I think it was two or three days later, I finally got LED on, LED off prints spaced about one second in between, on my screen. And I was like, "Yeah, now I'm going to publish it and share it with the world." And then the hard work started.
EW (00:18:18):
At that point, had you simulated all of the AVR and the peripherals in the Arduino Uno processor, the ATMega328.
US (00:18:30):
Of course not. If you go to the AVR AGS report, that's the open source project that simulates the AVR core. You consider, it's still like an open issue from almost two years ago to simulate the I2C slave. And I think the watchdog timer, no, I implemented that lately. There are things that people don't really need or don't use that much. I have never spent time on implementing them. And it took me pretty long time to get to a state where I can say, it covers most of the peripherals, but it pretty much useful for everyone that needed it so far. I think it covers almost all of the use cases.
EW (00:19:21):
I've been thinking about simulators for testing for not quite unit testing, but sorts of offline sandbox testing. And I like the idea that you don't have to simulate everything. You can simulate what you need. I think that's a good approach. You mentioned GitHub and your code is in GitHub and readable. It's actually quite readable and you have things separated by the CPU and the peripherals and examples. And I had a question, I was going somewhere with this. Oh, right. What are TS files?
US (00:20:08):
Oh, TS. I think it's a kind of subtitle files. That's what windows, when I double click on them, ask me, what do I do with these subtitles files? But in web development, TS is just a language called TypeScript, which is JavaScript, but with types. And it's fun. If you are going to develop for web, then go learn TypeScript.
CW (00:20:34):
Microsoft, is that right?
US (00:20:36):
Yeah. I think it started 10 years ago or so in Microsoft. I think the person who worked on C# was also one of the architects of TypeScript, but I might be wrong about it. I'm not very good at history.
CW (00:20:54):
You started with the AVR series, but you've also got a whole bunch of other architectures on here, including fairly recent stuff like the Raspberry Pi Pico. Was that harder? Were the other architectures easier or harder having already done the AVR? I feel like, well, the ESP32, I feel like would be less documented.
US (00:21:18):
Yes, that's true. And for the Raspberry Pi Pico, it came out, I think it was January 23 this year something or 21 this year. And I was like, "Cool, that's that seems like a pretty useful board and the price point for bucks, that many makers are going to want to use. And there is nothing that simulates that right now." And at that time I already wanted to do ... I had this idea for some time where I wanted to live code something. Do some kind of hardcore coding in a live stream. And the Pi Pico just came out and I was like, "Let's try that." And then about a week after it came out, I started a weekly series of live coding sessions where I would just code different features of the simulator from scratch every week. It was different in many aspects from the AVR.
US (00:22:31):
And I think one of the major hurdles was that with AVR, you get all the documentation in a single data sheet, or there is a different data sheet for the instruction set, but there are in a pretty similar format and they're pretty simple. And then with the Pi Pico, there is their data sheet from Raspberry Pi, which is great. And then there is the instruction set and the entire Cortex M core data sheet, which is, I don't know, if you take the word data sheet and leave data out. I mean, I'm sure they had good intentions, but it tries to be very generic. And it's written in some kind of pseudo programming language. I spend a lot of time just figuring out what they mean and which part of their description of their pseudo code for the instructions are even relevant for the Cortex-M0.
US (00:23:46):
The cool thing is that you can actually watch all the implementation live on YouTube. It's all recorded. You can watch from the very first moment when I created a directory and initialized the Git repo and write the first files and set up TypeScripts. If you want to learn more about TS files up to implementing the peripherals, the PIO, and there are even a few points where I introduced bugs. When I eventually figure out the bugs, I went back to the video and was looking at myself when I made that bug. And usually, I realized it was near the end of the session. Don't do two and a half hours coding session, that's too long.
EW (00:24:43):
Yes, I get that. Looking at this code, it's like a class in micro-controllers because I can compare the AVR with the Cortex-M0 with the ESP32 and look and see, well, they all have stack pointers of course, but what else is different and the same about the implementations? Did you start thinking these are all the same or did you start realizing just how different they were?
US (00:25:22):
That's a good question, actually. I think when I say started working on the Pi Pico, I was thinking my experience will be similar to working on the AVR. And it turned out pretty different. And I'm not sure what the reason for that was. I have a feeling that the live coding from that made it a bit more stressful. For instance, when I worked in the first session of working on Pi Pico, I really wanted to have blink working at the end of the session. I had a lot of corners and really tried together. I think I eventually did, but it was like I had an audience and I wanted it to be as accessible as possible to the audience so I spent time explaining what I was doing.
US (00:26:21):
And I was also trying to think before I code. Usually I just try something, it doesn't work, I try something else and this can be pretty confusing if you're just watching me and you have no context. I try to keep it a bit simpler to slow down on the pace and not to get to adventurers. And I think this made the experience different for me. Now it's hard for me to compare how different they actually are.
EW (00:26:59):
And the ESP32, that's a different core as well?
US (00:27:02):
Yes. The ESP32, I think the biggest challenge with it is, first of all, it's very messy. There are so many peripherals and every peripheral has different kind of conventions. And the data sheet has some of the information. And then the ESP-IDF, it's usually a better place to look for information because sometimes there are registers and some bits do not appear in the data sheet. And then when you go to the ESP-IDF you actually see there are other bits that do not appear in the data sheet but the code, the ESP-IDF uses them. The ESP-IDF is my first source of truth. And then the data sheet is sort of a backup. And then there is the wifi and the Bluetooth stack, which are mostly, the right stuff is totally closed source so if you want to simulate that, then I started reverse engineering their code to figure out how to simulate the wifi and the Bluetooth.
EW (00:28:17):
You gave a talk about that at Remoticon, right?
US (00:28:22):
That's where we met.
EW (00:28:23):
Exactly. I just wanted to make sure that was the talk that I remembered. It was interesting because when we think about things outside of the simulation environment, do I care if the software is doing this or the hardware? I mean, as long as I'm simulating sending packets, what difference does it make? But you wanted it to be fairly true. Why?
US (00:28:56):
When you work on simulators, you have a choice that you need to make. Either you simulate the system as accurate as possible at least from the user code point of view. Either you work really hard to simulate the functionality that the user code has to offer. Many simulators for Arduino, they just run compiler code to the C++ of the native processor. I mean to the machine code of the native processor or C++ to the instruction set of your X82 or arm processor. And then they simulate all the Arduino calls like digital ray, digital ride, et cetera. But then you lose a very important thing, which is the ecosystem. When you write a simulator, or at least when I created a simulator, it was very important for me to make it possible for the users to use any library that they want or any code example that they want out of the box.
US (00:30:04):
And if I don't go at implementing the hardware as accurate as possible route, and I just try to simulate at the higher level, at the API level, then there is endless surface that I have to cover if I wanted to support all the libraries and things that exist in the ecosystem. Going below to actually simulating or emulating the micro controllers and the peripherals in a way that is transparent to the code that is running inside them, that what makes it possible. It gives me all the ecosystem out of the box, theoretically. Practically, there are always exceptions, like one example is the first LED library. It assumes that specific instructions take a number of cycles, like a specific number of cycles. And it uses that to time the signal. And if you get even one instruction off, then that's not going to work.
US (00:31:18):
And even if you compile your Arduino program in debug mode, then the compiler is going to do the optimizations a little different or not do some of the optimizations and that won't work. It not only depends on the timing of the instructions, it also depends on the implementation of the compiler. If you don't go with the actual compiler, the same compiler that Arduino uses, and you don't implement the hardware as accurate as you can, first, LED won't work, and you will have to create a new backend just for your simulator or implement the EPI from scratch, which is a lot of work.
CW (00:32:07):
Yeah. Since there are so many different tweaky little things with embedded devices and their peripherals, it seems like simulation is not a path that unless you want to have workarounds and special cases for everything under the sun, it seems like emulation is the way to go.
US (00:32:29):
Even in that case, sometimes, I mean, take CircuitPython for example, I run it on the Pi Pico, but then when you start it on the physical device, it just wait for one second for the user to press on the boot button. But when I run it in the simulation, I don't want to spend one second of simulation doing busy waiting. I had to implement a workaround it, detect that this is happening and keeps the time forward so the user doesn't have to wait that second.
EW (00:33:06):
When I choose Raspberry Pi Pico, and it says serial dot begin, and it has the board rate and then serial dot print, and the Raspberry Pi Pico in the sketch that's put up, that compiles using a GCC arm compiler to arm code and then you simulate from there?
US (00:33:29):
I think that the answer is, yes, I'm not sure exactly which compiler version it uses, because I don't know, it uses the Arduino CLI to compile that. And this is all transparent for me because I believe they use the GCC arm compiler, that makes sense. But I try to keep it, myself as far as I can, from the implementation details and just use the Arduino CLI as is. I get all the ecosystem compatibility just out of the box. And an interesting thing I think to watch is you mentioned that you call serial begin with the boat rate and serial print line and then if you check the ad component menu, there is a logic analyzer that you can add there and you can connect it to the ETX and our experience, I think zero and one on the Pi Pico. And then you can actually see the serial signals that are simulated.
EW (00:34:39):
Oh, that is very cute. That is super cool. But do you use the hex or do you do LLVM or something in between. Do you actually just go to the binary file and emulate from there?
US (00:34:58):
Yes. You can actually press F1 and load pre compiled hex file and just bring your own hex and that would work. That's the benefit of emulation too, it's actually doing it. When you take it to real hardware, there's not a big shift or vice versa. There's not something you have to do to, "Oh, it's not going to work on this, because it's pretending."
EW (00:35:22):
If you make an ARM processor, a Cortex M0 like this, you have to pay for all of the arm cortex information. It's very expensive to make a processor like this. I would've thought that making a simulator like this would require all that information that you would need to make the processor.
US (00:35:44):
No, because they have to document all that stuff for somebody to write software for it, anything you know to write software for it-
EW (00:35:51):
That's true.
US (00:35:53):
... is enough. And that's public. The IP is all their silly silicon stuff that none of us care about.
EW (00:35:59):
I seem to recall, in your presentation, you were also using GDB on your sketches, in your simulator. How do I load up GDB here?
US (00:36:18):
That was a matter channel that I wanted you to be able to use GDB with the simulation, but implementing the GDB protocol and you can watch me in the Raspberry Pi Pico live streams actually implement it. It wasn't too hard, a few hours of work. But then making it possible for you to use GDB without having to install stuff on your machine and set up web sockets and all of that stuff. That was pretty challenging. If you press F1 and then type GDB, you will get ... F1 opens menu with some secret commands and then you can start a web GDB session. And this is actually pretty interesting because GDB is running inside a virtual Linux machine that runs in your browser.
EW (00:37:16):
It's installing in booting. And when you say F1, I need to be in the window otherwise I get a help window for my browser.
US (00:37:24):
Yeah, in the code window. Right.
EW (00:37:28):
You have a compiler running online, and now you're going to have a GDB running online. And so there has to be a backend to this. How are you going to make money off this so you can pay for all of your ...
CW (00:37:43):
No backend.
EW (00:37:46):
Oh, it's using my cycles.
CW (00:37:48):
This is all running in your browser that's why he wrote it in TypeScript and that's why he's running a virtual machine and you're-
EW (00:37:53):
What if I don't have GCC installed?
US (00:38:01):
Let's untangle the mess. There are a few things that are going on. It's very confusing. Users are always asking about it. The simulation itself, once you have the hex file runs in your browser. Same goes for GDP. When you start it, it downloads a small Linux build route image, which includes the GDB binary. And it also downloads a small X86 simulator that runs that in your browser. As long as you are loading hex files or running precompiled ones like MicroPython or CircuitPython or using GDB, then everything happens in your browser. And I only have to pay for the bandwidth that allows you to download the files, but it is no backend. With the compilation, that's a different story because nobody, as far as I know runs GCC in the browser in a production website.
US (00:39:11):
And at some point they actually tried that and it turned out that you could run the Arduino CLI and compile a link in the browser. It just takes two minutes. It's not really useful. And it takes two minutes and you would have to download 85 megabytes of data just to get a compiler and all the Arduino stuff and the CLI and everything. That's most practical. The only thing that currently runs in the cloud is the compiler. And for now, answering your second question, how do I pay for it? And there is even larger cost or more prominent cost, which is my wife and my time we are working on it full-time now. We are still figuring this out. If you have good ideas, I would love to hear you or the listeners.
US (00:40:17):
One thing we are doing right now, if you go to wokwi.com/features, you can see a list of all the features user ask for and asking for a feature is just opening an issue in GitHub. And then users can vote for them and they can buy vote powers, which let them vote, so they can vote with their money. And this has been solving a need that I had because whenever new request came, I was just trying to implement everything everyone requested. And at some point it became too hard to keep up. Now I use this as a solution to prioritizing what to work on. If you go now to the list, you will see simulate an SD card drive is on the top because it was very important for users. So they paid for this. Now I know what I should work on.
EW (00:41:11):
That's ingenious.
US (00:41:12):
Thank you.
EW (00:41:13):
Are you familiar with Godbolt?
US (00:41:16):
Yeah. What about it?
EW (00:41:22):
You're both solving similar problems with compiling and Matt's really great. And I feel like I should introduce you because you're going to have similar problems with hosting. ... Salsa beat machine. Can you tell us about the salsa beat machine?
US (00:41:41):
All right. I need to tell you for Christopher, but please introduce us. I like meeting great minds. Please introduce us. Salsa beat machine. Long, long time ago ...
EW (00:42:03):
Sorry.
US (00:42:06):
It's okay. Long, long time ago, I used to be a salsa dance teacher. We had a salsa dancing school and we had weekly socials where everybody would meet and learn how to dance and dance. And this is how Ariela and I met more than 10 years ago.
EW (00:42:25):
[Plays Salsa Beat Machine.]
CW (00:42:29):
Stop it.
EW (00:42:30):
Sorry. Sorry.
US (00:42:32):
When I was trying to learn how to dance, I had a real problem. I couldn't find the beat in the music. People would always say you are dancing on the two or on the three and I was like, "Huh, where, where do you see numbers here? I just your piano."
EW (00:42:54):
Exactly. Okay, go ahead. I totally understand the problem because I've had this problem.
US (00:42:58):
So it turns out Latin music is pretty complex. There are a lot of instruments that play at the same time and the patterns are pretty unusual to the Western ear. It take time to pick this up. And as I was trying to learn about a subject, I realized that if I had a tool where I could just play with different instruments and arrangements and focus on one instrument at time and then gradually add more instruments, there is this salsa song that does exactly that by the way. La Salsa Nunca Se Acaba by Susie Hansen, it begins with one instrument and then they are gradually adding up more and more instruments and then naming them. I realized if I could do this for myself, then I would maybe be able to start training my brain to pick up all the nuances of the different instrument and how they play together and how they formed this rhythm, this mysterious count that I couldn't figure out.
US (00:44:13):
And it started as a pattern script that used the media API. A friend gave me some book about Latin rhythms and I just went over the book and implemented every kind of rhythm that I couldn't find. And then I had to undergo a surgery and I had to stay home after the surgery for like a week or two. And I spent the time learning about Flex, which was back a thing. It was a way you could develop well applications with Flesh, some kind of development platform framework. And I just converted that Python script into a web application. And since that day it became the salsa beat machine. And I think it's pretty popular nowadays. The code is open on GitHub and I don't really spend much time on it right now nowadays, but I think it's still being used a lot.
EW (00:45:15):
And it's on the web.
US (00:45:17):
And Chris is a drummer.
EW (00:45:18):
Yes. And Chris is a drummer. What do you think of it, Christopher? Have you tried it?
CW (00:45:23):
It's very cool. I played with it. That is one of the difficult things with especially Latin kind of beats is there is... Well, they were designed for ... I'm going to start talking about this, you know all this, but they were designed for big groups of people with different instruments. And when you're trying to translate that to drum set, as you're just the one person. And so you have all these rhythms that maybe aren't difficult. Well, they're still difficult, but they aren't as challenging for four people to do. And trying to have each hand do something that's kind of polyrhythmic, it's very challenging. Breaking these down into individual parts that you can concentrate on and get into your mind before adding more is really, really great idea, because that's kind of how it's natural to learn stuff, but it's sort of hard to do that by yourself sometimes and hear what it's supposed to be doing because you're trying to learn at the same time.
EW (00:46:19):
Did the salsa beat machine come before Wokwi?
US (00:46:24):
Yeah, it was like, I think 10 years ago. And then something like seven years ago, I started another tool that would just let you play popular salsa songs and then see either shoes dancing to the rhythm. Performing the basic salsa steps. So you could program your brain to match what you are hearing with a visual representation of the rhythm. And at least for myself, I found this very helpful, train the brain to make the connection between what you hear and another sense. And then Wokwi, I think I started it a little bit more than two years ago. It's pretty young.
EW (00:47:15):
Was salsa beat machine your first open source thing that other people were using?
US (00:47:23):
I think it was my first thing that other people in the world were using when I was serving in the IDF, Israeli Defense Force. I wrote a small plugin for Microsoft messenger that would save the history of the chat because it didn't have that feature. And that was my first open source because I distributed it over mail with the source code that other people were using, but salsa beat machine was really something that I made and many people around the world started using. And it wasn't open source at the beginning and it didn't really matter. Actually, there is something similar between salsa machine and the simulation libraries like the AVR and Cortex-M. The users don't have enough knowledge or willingness to contribute. It probably takes a lot of expertise that is different from what they have, if they wanted to contribute code. Even though the salsa beat machine has been open for five or six years, I get almost no source code contributions and same goes for the simulators.
CW (00:48:48):
Really?
EW (00:48:51):
That's interesting and it's true because the people who would use it, the people who want features probably are not the people who have enough microcontroller, microprocessor development knowledge.
CW (00:49:05):
Well, that leads me to a question that I had in the back of my mind, going back to the ambulator, Wokwi. Right now it's focused on Arduino, but you have all of the emulation capabilities for all of these processors. There's no reason that you have to keep Arduino as the ... Let me rephrase this. Are you looking to go beyond Arduino? Is that a thought in your mind?
EW (00:49:34):
He did MicroPython.
CW (00:49:37):
Well, okay. Beyond hobbies to, we can run anything on this.
EW (00:49:47):
Let's put some IAR on here.
CW (00:49:50):
Not IAR, but have VS Code in the browser and just have the bare metal stuff and be able to do all the emulation of a more professional environment.
EW (00:50:02):
Should buy some voting power.
US (00:50:05):
Yeah. I need more people Elecia to say yeah to this. I'm in a pretty interesting situation. I have a lot of ideas where I could take it to, and I think Elecia may have mentioned testing. I have an idea where you could use this in your CI to just run the tests. There is already a, if you go to work wokwi.com/arduino/auto-test then there is a bunch of tests that I use to just test the simulator, see that blink is still blinking and the SD card still works and the USB works. And now I'm going to add some tests for the wifi. Basically the simulator is pretty complex and I want to make sure that if I change something, it doesn't break something else, which happens a lot of time.
US (00:51:08):
That's another direction we could take it. And I think for now the features page does give me a good picture of what users care about, but I don't know if users are able to see beyond their specific needs to generalize. And I think that's one of the challenges coming up with new places where the simulator can be or this environment can be useful for engineers and finding where the gap is. I don't know, perhaps the gap is not even in the tools as much as the messaging. I know some of the users, one user just wrote to me yesterday that he started using Wokwi for work after he used it for hobby and they found it really useful to cut down on their development cycle time. Please help me make this happen. Figure this out.
EW (00:52:20):
I'm happy to. There's the mbed processor, mbed online compiler from arm, which is rapidly not being supported. They've moved over to something called Keil Studio Cloud or something. And they had a simulator that was kind of a, I don't want to say a summer intern project, but because I know some really good engineers worked on it, but it was an out there not very well supported program, but it was really neat to have the simulator and with COVID, a lot of professors were using it because you couldn't go to class and help people with hardware. And so the simulator became very popular. I'm actually using it in class for the same reason, because I can give students code. And if it's in the simulator, I know it works, but I'm really trying to break them of the habit of using the Arduino IDE.
EW (00:53:20):
So I want to use VS Code really and be able to simulate boards. I have many ideas for features and it starts with make it available to use for college classes so that they can compile C files or C++ files and not be stuck with the Arduino interface, which is awesome. I love the Arduino interface. I have lots of hearts and kisses for the Arduino interface, but I would like people to not have to use the Arduino interface.
US (00:54:00):
When you're saying Arduino interface, you mean the editor? [crosstalk 00:54:05] like the libraries and wiring?
EW (00:54:11):
Wiring, the setup and the loop is the first part. The libraries, if you look around, a lot of the libraries are implemented in pretty good C++, or there's some version implemented in C++ that's similar and you can use those. And I think people should, as long as they don't need the extra cycles or extra RAM that they bring in. It isn't the library so much, it's actually just the setup and loop. And having people understand that you have to have hardware set up, you can't just assume it will all be taken care of for you under the hood. Similar to what you have, the embed simulator, you can put in different peripherals. I did a lecture, I did a lecture that's going up today or tomorrow, where I started with embed. And I did a PWM out in the simulator with an LED so that you could see what PWM looked like.
EW (00:55:12):
And then I put a speaker on it so you could hear what it sounds like. And then I changed the period of the PWM so you could hear the pitch shifting of the frequency parameter. And that was all really fun for me. But then I went through all of the code associated with going from PWM out as a variable to getting to registers in the data sheet, in the reference manual. And I feel like your tool would be able to do that much easier because I could look at GDP along the way and show stack traces and show variables and then show actual memory in the processor. Well, I mean, actual simulated memory, show the address where the register is supposed to be set and help people understand that you go from a high level variable through three layers of hardware abstraction, but in the end, you get to a memory that you write a bit to or a variable to.
EW (00:56:27):
And it feels like magic because I agree typing serial.begin in a baud rate feels kind of like magic compared to what I used to have to do. But what I used to have to do with writing a serial drivers are still there. It's just not as obvious. Okay. So when will you be done?
CW (00:56:49):
As soon as you contribute. Start filing some PRS.
US (00:56:56):
That's one I think it's a pretty interesting time in the development of Wokwi, because right now there aren't so many users, so it's pretty easy to get your voice heard or anybody's voice heard and set a direction of where this is going. And hopefully if Wokwi grows, then it won't be the same in a few months or in a year when there will be many more users and it will take much more power to steer the board. I don't know, maybe.
CW (00:57:32):
And I think, back to the dilemma you were talking about, how do I get more contributors? That's one thing where heading towards having a version that support more bare metal stuff, those kind of people might be the same kind of people who would contribute both to the simulator and be the people who would use it.
EW (00:57:53):
Yeah. Because they're the professional engineers, but they're the professional embedded engineers, as opposed to people who write good web software. What does TS mean again? I've already forgotten. TypeScript.
CW (00:58:04):
TypeScript.
US (00:58:05):
Yeah. You got it right. I think that's one of the problem is that you have to be good both at the embedded development or at least understand some of the deeper concept and also be fairly okay with, I won't say web development because you can pick up, I guess, some of the important parts pretty quick, but you still need to have this mentality of, if you classify yourself as an embedded developer and then you go and see a code base in TypeScript, you still have to have this mentality of, okay, this is code. I can manage that.
EW (00:58:52):
Yeah. But there is more crossover than I ever expected. I do meet more and more web engineers who are interested in embedded and more embedded engineers who are using web as part of their development. We talked to Tyler last week about using web tools instead of having to compile things. That was pretty cool. And we talked to Carlotta about Arduino. We know which she had a good point. She doesn't want to have hardware that she has to spend all semester setting up. And the simulator would, again, help the students go from Arduino easy level to being able to understand the deeper what's happening under the hood. This is very cool. I'm happy. Please continue. But you not only write the code, you also have blog posts that are really cool. Where do you find the time?
US (00:59:55):
I don't know, in my schedule. I mean, one of the thing I'm trying learn is how to ask for help. And it sometimes work. I think there have been some pretty amazing things happening with ... I was talking about the fact that people were not contributing to the AVR simulation core, which was nearly not to the Raspberry Pi Pico core to the RP2040 JS library, the Raspberry Pi Pico simulator, but people do contribute on a lot of other things. I think one of the most impressive efforts is by a person called Anderson Costa from Brazil. And he constantly translates all the documentation that they produce to Portuguese.
US (01:00:53):
He translated over, I think 50 pages of documentation or so, so far. And he keeps doing it and it makes Wokwi so much more accessible. I watched a video of somebody from Brazil introducing Wokwi in Portuguese and then it clicks on the question mark next to one of the parts. And it opened the Brazilian, the Portuguese side. And it feels, I guess, for the people who watch this, it feels much more home when they see that the documentation is in their own language. And this is just a user who really love the product and does this translation.
EW (01:01:37):
It's amazing how people think that to contribute to an open source project, they have to dig deep into the code and find the smallest bugs to work on when the truth is a lot of open source projects, they need help explaining what they do, getting the word out, being translated into different languages, checking the docs for grammar errors. I mean, it doesn't have to be hard to contribute.
US (01:02:07):
Yeah. One of the users just sent me last week and I was working on it before we started recording this, one pager explaining the benefits of Wokwi and I'm like, "Okay, you explain it so much better than I do." And now I'm trying to sort of wrap my head around it and see how I can break this down. All the information that he shared with me and use this for my communication to explain people what Wokwi can do for them. That person, even if he contributed a feature, I don't think it would have the same impact as letting me know what the perspective users is, how he sees Wokwi, how he sees the advantages or the benefits of the simulator.
EW (01:03:12):
Yes. Sometimes users and listeners are amazing in that they see things that we're too close to see.
US (01:03:21):
Exactly. I will just give you one bullet. Mistakes are okay. No hardware can be destroyed. I haven't thought of that.
EW (01:03:35):
I've let out a lot of magic smoke in my career. That is the awesome thing about simulator is, you can do really stupid things. Although I do want to simulator that when I hook things up wrong it-
US (01:03:50):
Shouts at you?
EW (01:03:52):
No, I want it to fake explode. I wanted fire on screen.
CW (01:03:55):
Outrageous. Beyond reality fire. Well, maybe I can work to put some 3D shader stuff into here. That seems like a important contribution that would be accepted.
US (01:04:08):
Do you do 3D shaders?
CW (01:04:12):
I've done some. I've played around, but not professionally, no.
US (01:04:18):
A funny story about 3D shaders. At some point I wanted to speed up the implementation of the lead metrics simulation. I tried to write a shader to do that, and it worked pretty good on my machine, which has RDX something and video card. And then users complained it was super slow on their machines. And then I just reverted back to the CSS implementation and then it ran fast for everyone. Shaders are a lie.
EW (01:04:51):
Before we let you go, you've taught a couple of courses at Hackaday. Could you talk about those briefly?
US (01:05:01):
Yeah. Those courses were one of the drivers for me to implement some of the more advanced features in the simulator. For instance, the first one was about AVR, the architecture, the assembly, and how to approach reverse engineering AVR programs, Arduino programs. And I decided to try to use the simulator for the entire course. And that's one of the major reasons, we now have the GDB on the web because I wanted the students to use GDB and I didn't want to spend time or them to spend time configuring GDP, setting it up, windows versus Linux versus Mac and all of that stuff. I just tried to build all the features or if you go to any Arduino program and you press F1 in the code editor and then type view assembly code listing, you will actually get a tab with the assembly code listing.
US (01:06:09):
That's another feature that I built, especially for that course. And the second course was about the Raspberry Pi Pico a few months after it came out. And as soon as I started working on the simulator, and you asked about the data sheet, so I spent so much time studying the data sheet. I figured out that I have gained considerable amount of knowledge about the internals of this chip. And that's something I can share. This is how the second course was born diving into the depth of the Raspberry Pi Pico. And for that course, I implemented a small PIO debugger. If you are running a Raspberry Pi Pico programs that use the PIO peripheral, there will be a new tab where you can step through the instructions of the PIO machines, set break point, see the registers. That's something I implemented just for that course, again, to make my life as a teacher easier.
EW (01:07:15):
You've done a great job sharing the knowledge as well as gaining it. It's just really cool. I like Wokwi and I expect to be using more of it in the future.
CW (01:07:25):
And I really encourage people. If you go play with this to read the docs, they're really good.
EW (01:07:30):
The code's really good, too.
CW (01:07:31):
And extensive. The code is good and make sure you click on the little thing after you sign up on an account with your avatar or whatever, because there's a bunch of other stuff like the feature roadmap and a discord and stuff and links and things that aren't obvious immediately on the webpage.
EW (01:07:51):
Do you have any thoughts you'd like to leave us with?
US (01:07:54):
Okay. I think my parting thought is, when I'm working on this whole platform, I really enjoy doing the code, working on the code, coding, all the engineering stuff. It's fun for me. But then I think one of the major things that makes it a lot of more fun is the community that evolves around this. I really love the community. And there are people who hang on the discord server and they just answer random questions of other people and they are so helpful. And sometimes I just come back and see a discussion in the discord server. Somebody asks a question about connecting LEDs and people helping with power supplies, which has nothing to do with the simulator, but then it creates so much value for that person. And I think that's the other thing that really helps me go forward and continue with this. The people that are so involved and care so much about Wokwi and want it to be better. My parting thought is just to say, thank you.
EW (01:09:23):
Our guest has been Uri Shaked, maker and serial warranty voider. You can find his simulators at wokwi.com. That's W-O-K-W-I.com. And Of course we'll have links in the show notes, including links to the GitHub site where his code is all open and very interesting.
CW (01:09:45):
Thanks, Uri. It was fun to talk to you.
US (01:09:48):
Thank you. Until the next time.
EW (01:09:51):
Thank you to Christopher for producing and co-hosting. And thank you for listening. You can contact us at show@embedded.fm or hit the contact link on embedded.fm. I don't have a quote to live you with so here's a little bit of samba that Christopher wrote.
CW (01:10:06):
Please, I'm not going to write. That is outside my area of expertise musically.
US (01:10:18):
I can play something on my panpipe if you want.
CW (01:10:22):
Go for it.
EW (01:10:23):
Go for it.
US (01:10:24):
Let's see if you recognize this.
CW (01:10:26):
Perfect.
EW (01:10:31):
Perfect. Thank you.