Transcript from 454: Printf Hello with Uri Shaked, Christopher White, and Elecia White.

EW (00:00:06):

Welcome to Embedded. I am Elecia White, here with Christopher White. Our guest this week is Uri Shaked, the creator of Wokwi. That sounds familiar. Well he has been on, but we have so much more to talk about, because Wokwi has grown so much.

CW (00:00:24):

Uri, thanks for joining us again.

US (00:00:26):

Printf Hello World.

CW (00:00:27):

<laugh>

EW (00:00:30):

Could you tell us about yourself?

US (00:00:34):

Yes. I do not watch TV, I do not drink beer, and I rarely drink coffee. So, all the things that set me apart from the cliche developer. I fail often. And I love engineering, hardware, software, even mechanical engineering sometimes, and even engineering business.

(00:00:56):

Throughout my career, I have started as a web developer more or less, and expanded to other areas. I did blogging, live streaming, and even tried my luck with hardware crowdfunding project. It did not go very well, but it was fun. Now I am working on two projects, Wokwi which you already know, and Tiny Tapeout which Chris knows about, but has not shared a thought with you yet.

EW (00:01:31):

<laugh> Well, lightning round is on vacation this week. Partied too hard last weekend. And so let us get straight to all of the questions I have about these things. Let us actually start with Tiny Tapeout, since you guys surprised me with it right before the show started. What is that?

US (00:01:54):

So, Tiny Tapeout is something that happened out of the same conference where you and I met, that was the Hackaday conference two years ago. I really loved your talk about Ram Landia, and I think other than your talk, there was another guy, Matthew Venn, which I think I connected you a few months back. Matthew gave a talk about designing ASICs, so custom chips with open-source tools.

(00:02:32):

I was always intrigued by this literally black box that I put on my PCBs. How can I make one of my own? And the answer for that, when I googled that back a few years ago, was, "You go to college and study this. Or you have a lot of money to throw at it, and you just throw tens of thousand of dollars on software and manufacturing costs. And then it will probably fail, because you have no idea what you are doing." You are probably going to make all the trivial mistakes.

(00:03:10):

So Tiny Tapeout is trying to solve it. It is a part of a bigger thing, which is open source slowly creeping out into this whole subject or area of custom ASIC design. And Tiny Tapeout is a service where you can create your own digital design, and get it manufactured and receive a physical chip with your design on it, for as low as 100 bucks.

CW (00:03:50):

All right.

EW (00:03:51):

What?

CW (00:03:51):

Well, that seems kind of impossible, so there must be some trick involved here. Having worked- <laugh> I worked at a fabulous semiconductor company, and we were probably making much more complicated things than people make on Tiny Tapeout. But I remember it being very hard and very expensive, and it involved flying to TSMC and arguing with people. So, okay, how do you do this <laugh>?

EW (00:04:11):

Yeah?

US (00:04:14):

Yeah, it is simple, but it is also there are a lot of moving parts that have to work together for this to happen. I think the first one is open source. So, fabs are starting to open-source their PDKs. They are set of files that you need in order to manufacture a chip. And traditionally you had to sign an NDA with a fab, and then buy licenses for expensive software, before you could even start actually working on your design.

(00:04:52):

Nowadays there are I think already three different fabs that have open-sourced their digital PDKs. And there are a great number of open-source tools and solution, moving from digital design in a language like Verilog or VHDL into a GDS file, which is the equivalent of a Gerber file, what you send to the factory for manufacturing.

(00:05:24):

There are open-source tools chains that can do this whole process of taking a design and preparing it to fabrication. So this combination makes it simple to get from idea to file that you can actually send to be manufactured.

(00:05:44):

The other problem that is left to be solved is costs-

CW (00:05:50):

Yeah.

US (00:05:50):

And complexity. Even though these tools exist and the PDKs are open, it is pretty complex to set up all the things on your computer. And Tiny Tapeout tries to tackle these two subjects. So, for complexity, we have set up a GitHub action that wraps all those tools.

(00:06:12):

So basically all you need to do is to clone a repo, and then you can just put your Verilog code there. Or if you do not know Verilog, we extended Wokwi to support designing stuff with logic gates. So we can just drag a few logic gates, connect them, and create your digital design visually in Wokwi.

(00:06:38):

And then the GitHub action takes either the Wokwi project or the Verilog file, and runs it through all the tools that gets you to a GDS file. So that makes things really simple, because you no longer have to fight with tooling and incompatible versions, DLL Hell style.

(00:07:02):

And then I think the more intriguing part, which is what Chris asked about, is how is it possible to make it so cheap?

EW (00:07:17):

I am boggled, because I have worked with companies who wanted to make chips, and I have worked with companies who have made chips, and it is so expensive. I remember one startup wanted to make a Cortex-M0 chip as a core for their additional stuff they wanted. And I was like, "Okay, do you have two million dollars sitting in cash for Arm to take? Because if not, you are not doing this."

CW (00:07:49):

Well, that was for an IP core.

EW (00:07:50):

Right. That was for an IP core. But then even 8051s, it still is hugely expensive. It is partially the engineering cost of putting it together and testing it, but it is also largely just working with the vendors in the silicon.

CW (00:08:10):

Well, I think we are making simpler things.

EW (00:08:13):

Right. I saw on the website there are adders and barrel rollers. I got that.

CW (00:08:17):

Okay.

EW (00:08:17):

But the base cost has always been hundreds, if not millions, of dollars to get started in this area. I mean, hundreds of thousands or millions of dollars. And now you are telling me that I can do it for hundreds of dollars, and I am just-

US (00:08:38):

Yes.

EW (00:08:38):

I mean, that is more than Moore's law. That is wow! Okay, I am done being shocked. So you can go on.

US (00:08:51):

<laugh> Okay. So the basic trick is that usually you do not need a lot of area to test something. If you just want to test something like let us say UART peripheral or even a small microcontroller core, you do not need the whole die area. But you cannot, or it is not really easy to, buy just the amount of space that you need.

(00:09:22):

I have not been to that era, but I heard that this has also been the case with PCBs. In the past, you could just get a whole panel made for you, but now we have-

EW (00:09:33):

OSH Park! Is this OSH Park for chips?

US (00:09:36):

You nailed it. In a way, this is OSH Park for chips. It is not exactly the same. There are some differences. I think in terms of manufacturing, the factor that is contributing to the cost the most is the masks. So, it is not like we can create a different version of the chip for anyone who submits the chip.

(00:10:05):

Rather we create one chip with everyone's design, and then everyone gets that chip with everyone's design. So not only you get your stuff, you also get 100 or more designs of other people to play with.

CW (00:10:23):

Because chips are so small, unlike OSH Park, you do not need to depanelize them. You just ship everyone the whole thing <laugh>.

EW (00:10:30):

<laugh> But does not everybody need pins? And it is not just the silicon, you do have to put it in a package.

US (00:10:38):

Yeah. So that is the other reason we are shipping everyone a copy of the same chip. We are just having everything go through the same pipeline. So same set of masks, then they are all packaged as a QFN chip, and we are basically sharing pins.

(00:11:01):

So what we are doing, we have a multiplexer where there is a simple controller that lets you choose which design is currently active. So when you get the chip, you can just choose, "Hey, I want my design to be active right now." And then your design gets access to, I think right now we have eight plus eight plus ten, so that is 26 IO pins. Or, that is ten inputs, eight outputs and eight bidirectional pins. And you can do whatever you want with them as long as it is digital.

(00:11:40):

We are also looking at some kind of support for mixed signal designs and analog designs. But I learned that iterating on silicon is really slow. It takes months, if not years, to iterate and get our designs made. So it also means that we cannot add features as fast as we want, because we also need to iterate on the features that we are adding to this wrapper chip, where everybody puts their designs.

EW (00:12:19):

What happens if one person's design is flawed and takes over the chip? Do you end up nobody else can use the chip? Or how are you preventing that?

US (00:12:31):

That would be a disaster, right?

EW (00:12:32):

Right.

US (00:12:32):

So, it really depends. We prevent it on two levels. The first level is, if you only submit a digital design that went through the standard hardening process of converting your digital design into a GDS file, then there is not really a reason why your design would create a disaster for the chip.

(00:13:02):

We are also looking at what people are submitting, and it does not seem like people are trying to sabotage with their designs. But if you start supporting things like- Oh, and of course part of the flow includes DRC tools that check that you do not have short circuits, and you comply with all the design rules.

(00:13:30):

The other layer, which we are now prototyping, and that would allow more bring your own GDS file or more complex mixed signal and maybe even analog designs, is power gating. So we are prototyping a solution where we could just power down your design when it is not active. So even if you did something really horrible, as long as someone else does not activate your design, then nothing bad happens. Right.

EW (00:14:08):

With Wokwi, it is very much simulation. But this is simulation of code running on boards at chips. But this is physical. Is there a level of simulation to Tiny Tapeout?

US (00:14:24):

So, yeah, Wokwi is simulation and the core of Wokwi- We did not even explain what Wokwi is. So if you do not know, bear with us.

EW (00:14:35):

<laugh> That is a good point.

US (00:14:37):

So, the core of Wokwi, other than the microprocessor simulation, there is a digital simulator. If you want to simulate digital logic, then it fits like the engine. The digital engine of Wokwi can also simulate AND gates and OR gates and NANDs.

(00:14:58):

We even have- I have this on my list of features that I will mention later. But we even have some basic Verilog simulation support. So you could even run Verilog code, and create a chip inside the Wokwi, and simulate that.

EW (00:15:19):

That is really cool.

US (00:15:21):

Thank you.

EW (00:15:22):

With Tiny Tapeout, I see that there are puzzles I could do, to help me understand how to put together the logic gates.

US (00:15:31):

Mm-hmm. <affirmative>

EW (00:15:32):

Is that the best place to start? Or do I need to have an application in mind? Where do I start?

US (00:15:40):

That is a great question, and I think the answer is always in engineering, "It depends." What are your goals? Are you an enthusiast looking just to get your hands dirty, and do something in one evening or one weekend? Are you a college teacher that wants their students to do a full semester project with, and design something meaningful, or I would not say meaningful, more complex? So it really depends what your goals are.

(00:16:21):

If you want just to play, tinker and close the loop with the simpler thing possible, then just go over the tutorials, and use Wokwi with the visual editor. And you could create a project that, I do not know, maybe spells your name on a seven-segment display. That would be a non-trivial, pretty complex project, that would probably take a day or two to complete.

(00:16:52):

If you want to learn Verilog, or other hardware design language, then I would start with taking some course, which we currently do not offer, but some training on how to write Verilog. And then we have an example project in Verilog, where you can just drop your code, and get it through the flow of generating a GDSII file.

(00:17:20):

And I think the most important resource is the Discord server of Tiny Tapeout, where you can just pop in and start asking questions. We will answer, or other people from the community who know better than I do, because I have only been doing it for like a year and a half. Actually, two days ago I just got the first chip that I designed, and tested it for the very first time. So this is all very new to me.

EW (00:17:52):

But you have had three tapeouts?

US (00:17:55):

Yes, we had three tapeouts, but none of them has returned from fabrication yet. The chip that I got was an experimental tapeout off Google in combination with Efabless, which is the contractor we are working with to do the manufacturing. And it had a surprisingly low turnaround time of just six months.

CW (00:18:24):

<laugh>

US (00:18:24):

So this is a design I submitted in December and I got it back two days ago.

EW (00:18:32):

I have to ask this for all open source projects, but yours is of a scale that I really have to ask. How are you going to make money doing this?

US (00:18:41):

Doing Tiny Tapeout?

EW (00:18:44):

Sure. I am going to ask the same question about Wokwi, but I have more detailed questions there.

US (00:18:47):

Okay.

EW (00:18:47):

Let us start with Tiny Tapeout.

US (00:18:51):

So with Tiny Tapeout, it is like you said, we want to be the OSH Park of open source, or of ASICs. Will start with the open source, maybe eventually we can also offer a similar solution for commercial users. So our product is selling you space on the chip.

(00:19:17):

If we manage to sell enough of those, we are going to be profitable. If we do not, then it has been nice, "Goodbye, Tiny Tapeout." I hope the first one will be- Actually even if it does not work, it has still been so far a very fun ride. I met Matthew, and working with Matt Venn is so much fun. I learn a lot, so even if it does not work out, I am good. But, that is the plan. Just selling slots on silicon, selling pieces of silicon.

EW (00:19:58):

It seems like it would be a fantastic teaching resource. But the 12 month turnaround means it is not all one class. Is there any way to make it shorter, or have you talked to instructors about how to make that work within their curriculums?

US (00:20:18):

Yeah, it is a good question. We are still in the process of figuring out how universities are going to use it. Some of them want to use it as part of their curriculum. I think there is even one teacher who said that when he discovered Tiny Tapeout, it made him change his entire curriculum around that, which was very cool to see people are actually excited about it, they are adopting it.

(00:20:53):

We also feel the pain of one year turnarounds. And the good news is that it seems like going forward the turnarounds are going to be smaller. I do not want to be too optimistic and give a number and then we will not make it, because we know how it is with projects. But it seems like the whole ecosystem is moving in the right way to get the times shorter. It will not be as fast as PCB, that you can get in like 24 hours. No, it will not ever be there. But let us say a couple of weeks might not be impossible.

EW (00:21:38):

That would be...

US (00:21:39):

Very hard, yes. I do not think it would be impossible.

EW (00:21:44):

And it cannot be the 24 hour PCB times, because silicon chips like this have real chemistry they have to do. They have-

CW (00:21:55):

They are grown in dank caves. It takes a long time for the crystals to grow.

EW (00:22:03):

<laugh> Kind of, but not.

US (00:22:05):

You also need unicorn dust when manufacturing them. And that is really hard to obtain.

EW (00:22:13):

Yes, exactly. But there are physical limitations to the timeframe.

US (00:22:21):

Right.

EW (00:22:22):

How does this- Well, actually let us go back to Wokwi. Could you explain what Wokwi is?

US (00:22:31):

Just a moment. I need to switch this my mind, to turn the switch to the other mode, now from Tiny Tapeout to Wokwi. Can I get a good sound effect from you, Chris? <sound effect> Okay. Yeah, I remember last time you had to play samba.

CW (00:22:51):

<laugh> That is right.

US (00:22:54):

Okay, so Wokwi. For those who do not know Wokwi yet. Yeah. What Wokwi is- Let us start by describing the problem that Wokwi tries to solve. So we know that software is very complex, and embedded software is no exception. But it becomes even more complex, when you have all those heavy tool chain and IDEs that you need to install.

(00:23:20):

And then electronics just adds one more layer of complexity, because you no longer have to debug just your software. You also have to debug the connection, the hardware, to get the right parts. And it becomes very complex to develop and debug embedded systems, especially for people who do not have years of experience doing so.

(00:23:47):

So Wokwi tries to alleviate this pain, and make it a little bit more smooth, less painful, more magical experience. At the core, we have a simulator for multiple microcontrollers, the ESP32, STM32, Pi Pico, Arduino, and many common electronic parts like displays, sensors, motors, even Wi-Fi.

EW (00:24:24):

Logic analyzer?

US (00:24:26):

That was my surprise for later.

EW (00:24:28):

Oh, I am sorry.

US (00:24:28):

Yeah, logic analyzer.

EW (00:24:30):

I love the logic analyzer.

US (00:24:31):

No, that is fine. <laugh> Logic analyzer. And then around this core, we have the web interface, which means that you can just use an interactive drag and drop diagram editor to capture your project, your schematic, in a visual way. And then we have a bunch of compilers that are set up in the cloud, so you do not have to fiddle with tool chains.

(00:24:58):

The idea is that once you have your code, or you develop your code in the online editor, and then make your circuit or project in the diagram editor, then you can just save it, get a link, share it. Any other person opening this link and just running your project, and pick it up from the place or from the state where you saved it. So sharing electronics embedded projects become very easy, just sharing a link.

(00:25:34):

No longer need to deal with physical hardware, and you can isolate the software from the hardware. You know that if I share a project with you, you know that the virtual hardware works exactly the same as it did for mine. No longer you have to worry about loose wires or magic smoke.

EW (00:26:00):

You cannot blow up your web browser.

CW (00:26:03):

Oh, I can do that.

US (00:26:05):

You can.

EW (00:26:05):

<laugh>

US (00:26:05):

I can even tell you if you want, how you can create a circuit in Wokwi, that will kill your browser tab.

CW (00:26:14):

<laugh>

EW (00:26:16):

Well OK, but there is no magic smoke that comes out. It does not stink up your office.

CW (00:26:20):

Depends on your computer. So last time we talked to you, I think you had support for ESP32 and Arduino. And we begged you to work on lots of features, to move out of the Arduino thing, and be able to do-

EW (00:26:39):

Raspberry Pi Pico in C.

CW (00:26:40):

Generic projects on Raspberry Pi Pico and STM- And as far as I understand it, you have done all of that. Is that right?

EW (00:26:47):

And more <laugh>.

CW (00:26:49):

So you can basically do anything you can do on a dev board, on Wokwi first. Pretty much.

EW (00:26:57):

Well, the two STM32s are supported as Nucleo boards.

CW (00:27:02):

Right.

EW (00:27:02):

And I think they are both Cortex-M0, right? Or is one of them an M4?

US (00:27:10):

So the two officially supported ones are-

EW (00:27:13):

Officially?

US (00:27:14):

Both M0. There is an unofficially supported one. I think it is the L432.

EW (00:27:20):

Ooh.

US (00:27:20):

If I am not wrong. Which is M4. But nobody except you, Chris, and a couple of people now knows about it yet.

EW (00:27:33):

<laugh> We will keep it quiet.

CW (00:27:34):

Yeah. No one will hear this.

US (00:27:36):

<laugh> Thank you.

CW (00:27:38):

If I remember correctly, you have written the simulators for all of those processors. These are not things that you bought somewhere <laugh> and then put in an IP core. You actually reverse engineered these processors.

EW (00:27:51):

And they are processor simulators, not board level simulators. You are dealing with actual assembly instructions.

US (00:27:59):

Yeah, we all have trouble to deal with. These are my troubles.

CW (00:28:04):

<laugh>. It is just amazing the pace you actually have managed to do these things, and it is super impressive.

US (00:28:12):

Thank you.

EW (00:28:14):

It is super handy too. I mean, I taught the Classpert course, and we used Wokwi some, especially when we were talking about hardware that we did not all share. Or when a student would ask a question and I could not reproduce it, I could ask, "Could you give me a minimal example on Wokwi," and usually that solved their problem <laugh>.

(00:28:37):

But I also could share my own code that I wanted them to use. Like, I have a command line interface, and I could prove that it worked on Wokwi, "You can certainly make it work on your system." It was really nice for that.

(00:28:54):

But it was all- At that point it was Raspberry Pi Pico and I was using the SDK, which was pretty cool. I had not used it before, and the SDK was really well written. But one of the things the Raspberry Pi Pico has going for it, is that it was an only child at that point. Now there is the Wi-Fi version. But STM32 has hundreds of different processors, siblings and cousins, and M0s and M4s, and...

CW (00:29:27):

Sevens.

EW (00:29:28):

M7s, R92s, I do not know. How can you support that infusion of new processors all the time?

US (00:29:44):

That is a good question. First of all, I am trying to, I am not always very successful at that. But I am trying to support use cases, rather than microprocessors or peripheral. So, I am trying to see what people want, and maybe we do not have to support every single part that STM has ever created, right? Like with AVR, we do not have every single AVR board that was ever created. We just have the most popular ones.

(00:30:27):

If there is some customer that tells me, "Hey, I need this specific STM part, and I am willing to pay for it," then yeah, that is a good reason for me to go and work on that.

(00:30:37):

So it is a fine balance. How do you make it useful enough, that it gives people at least a good way to work with the STM ecosystem? At the same time, how do you not dig yourself down into this rabbit hole, of implementing every single feature or supporting every single microcontroller in this huge family?

EW (00:31:09):

Are there tools to help you? I know there are the SVD files, and MicroPython has their alternate pin CSV files. Are you looking at being able to support a large number of boards by using these automated files? Or is that just not interesting to you? It is really not about that yet. Or ever.

US (00:31:39):

Come on. I am a developer. I am an engineer. I am lazy. I am always looking for ways to automate things, and remove, eliminate, repetitive work. So the first thing I tried is just to use those SVD files, and let the magic happen. There is even- I am pretty sure you are familiar with Renode.

EW (00:32:03):

Mm-hmm. <affirmative>

CW (00:32:04):

Yes.

US (00:32:06):

So Renode is interesting, because it is an open-source project with a permissive license. It actually comprises two parts. The first part is the core simulation, the actual instruction set. They implemented it using TLB, which is a part of QEMU. It is just like the simulation engine of QEMU. And, if I am not wrong, it is written in C maybe C++, one of them. And then on top of that, they built all the devices and peripherals in C#.

(00:32:52):

So they have a lot of mileage and a lot of code that simulates peripherals in their repo. So the first thing I said, "Okay, they have this code in C#. Maybe I can run C# in the browser, and just use Renode to simulate all the peripherals." And I tried that. And then I said, "Maybe I could just convert some of their code from C# to TypeScript." And I tried that as well.

(00:33:25):

But eventually the biggest problem is not really creating the code, it is making it behave correctly. And especially with peripherals, which are sometimes very complex state machine, that have a lot of parameters that need to work correctly. If you get one thing wrong, then this can just ruin your life. I could spend half a day hunting for a bug, that happened because I misinterpreted a single bit in a peripheral, or I did not get a state machine right.

(00:34:07):

So getting the SVD files or converting what Renode did to TypeScript, could save some time. Like it is easier to get the registers from SVD files, than copy-paste from data sheet. And it is probably less error prone. But usually the hardest part is actually understanding the underlying logic. And sometimes things are not really documented.

(00:34:41):

One example, I implemented the ESP32 SHA peripheral. So there is a peripheral that calculates SHA hashes. And there are several lengths of SHA hashes supported, like 256, 512. And you can tell the peripheral which kind of SHA hash you want.

(00:35:07):

Looking at the documentation, I thought there are different modes. Like you configure the peripheral to calculate hash SHA 256, then you put in the data, you tell it, "Do your magic," and you get the output, right? But apparently a few of the SHA modes, or a few of the SHA links, share some state.

(00:35:40):

Only by spending two days, and comparing my behavior with the hardware, I realized that if you initialize- I do not remember the specifics, but if you initialize one of the SHA modes with some state, then you can switch in the middle to another SHA mode, and it will continue the calculation, and give you a different output. Compared to if you just started with the original, with one SHA mode, and stayed into it.

(00:36:13):

I am not sure I explain this correctly, but the specific are not important. The point is that there is some shared state, that one would assume does not exist, but it does. And data sheet does not tell you that, right? Nor the SVD files. And that what takes most of the time, finding those places where things are not as documented, or not as you assume they would work.

CW (00:36:43):

Yeah. That is important, because people tend to either rely on those behaviors without realizing it, or they are debugging something and they say, "Well, let me try this on the simulator". And maybe if the implementation on the simulator is not exactly the same, their bug does not show up. So you have to make the thing work like the actual thing, not just go off to a generic SHA function and come back and say, "Okay, we did it." Right?

US (00:37:17):

Yeah. I mean, do you know what is Galois multiplication?

CW (00:37:21):

I probably used to.

EW (00:37:24):

Galois?

CW (00:37:24):

I never heard-

EW (00:37:25):

G A L O I S E.

CW (00:37:28):

No E.

EW (00:37:29):

No E.

US (00:37:30):

I do not even know how you spell it. That is fine. I did not know what it was, until I had to implement- I think it was for the RSA peripheral.

CW (00:37:38):

Sounds right.

US (00:37:40):

It is this specific thing that you only use for this. If you Google it, you will see that you will always use it for a specific algorithm that speeds up this RSA. The hardware is expected to implement it, and you need to do it exactly the same way the hardware does.

(00:37:59):

Usually when you have hardware peripheral that accelerates some kind of computation, it will not do the whole things. Like it will not just calculate RSA, because if you just had to do, I do not know, encrypt with private key or decrypt with private key, I could just use some off-the-shelf library and give it like the inputs and get the outputs.

(00:38:26):

Usually it only does part of the algorithms in hardware. And in order to simulate that, I have to understand how the algorithm works, how the parts are put together, and which part the hardware does. And deal with things like Galois multiplication.

CW (00:38:49):

<laugh> Yeah, that reminds me of working with a graphics accelerator that we had on a Cortex-M4 that nobody else had. It could do a lot, but like you are saying, it went three quarters of the way there, and then you had to understand how it worked, and take the results and do the rest in software. Because they were not going to do it all for you.

(00:39:10):

There was a lot of matrix math and stuff like that. It was like, "Oh, cool, you are doing this rotation. Oh, but I have to set up the matrix for you ahead of time, and do some fixed point stuff, because you are not going to do that for me." Yeah, I think that is extremely common in these quote "accelerators."

(00:39:26):

People think, "Oh, I got an accelerator. I can just say, "Compute this. Give me a yes or no." And it is like, "No, you have to read a long data sheet." And so making something that only partially works, also must be complicated <laugh>.

EW (00:39:42):

Do you ever have to read the errata in order to break your implementation <laugh>?

US (00:39:49):

So wait. Chris, you say you have experience with that, right?

CW (00:39:52):

Yeah.

US (00:39:52):

Okay. I know who is going to do the next one, I guess. Thank you.

CW (00:39:59):

Oh, no, I am retired. <laugh>

EW (00:40:02):

That is not true.

CW (00:40:03):

I am retired until next week.

US (00:40:06):

Yeah. We will unretire you <laugh>. Yeah. But I think I am mostly done with- I hope I am mostly done with all those peripherals, or with the most important ones, at least for the time being.

EW (00:40:21):

So I2C is a protocol that has a lot of state that most people do not realize. Where SPI is a simpler thing from a hardware perspective, from a chip perspective.

CW (00:40:33):

And it is just better. <laugh>

EW (00:40:38):

As you look at different processors, does this peripheral change much between the processors? Or have you mostly standardized on a Wokwi SPI peripheral that you can move...

CW (00:40:54):

Drop in. Yeah.

EW (00:40:54):

Drop in from instance to instance of different processors?

US (00:41:00):

I wish.

EW (00:41:01):

<laugh>

US (00:41:03):

Yeah. So just the two STMs, or at least one of them that I support, decided that it would be a great idea to combine a SPI and I2S into one peripheral.

CW (00:41:15):

Wait, what?

EW (00:41:16):

No!

CW (00:41:17):

Why would you? What? Hmm.

EW (00:41:19):

I mean not I2C, but I2S.

CW (00:41:22):

I know. It is the audio thing. Yeah.

EW (00:41:23):

Audio. Yeah. Okay.

US (00:41:25):

Yeah, each one has- Or the ESP32 decided that it would be nice to give the software a way to break down a SPI transaction into address phase, transmit phase, receive phase, damage phase. So you can actually configure all those parts with different buffers, and tell it, "Hey, now do your thing." Instead of just giving some generic interface. Because when you work with SPI flash or SPI RAMs, then you actually use those phases when you talk to them.

(00:42:08):

So even though SPI is quite simple, and the AVR SPI is heaven, it is super simple, just "Send this byte," or "Get this byte," and we are done. My other MCUs are creative, and they find way to make their own SPI unique and shine above the rest. So yeah, unfortunately even for something as common as SPI, or as simple as you would guess a SPI. By the way, what about QSPI?

EW (00:42:46):

And FIFOs and DMA. There are all sorts of ways you can break the simple SPI.

CW (00:42:51):

Yeah. Every time we talk to you, I just keep shaking my head. I do not understand how you do any of this. It is so much work. <laugh> It is so intricate. It is really cool.

EW (00:43:02):

Is it harder to support a new microprocessor, or to support a new language? Because you support a lot of languages.

US (00:43:10):

Yeah. We added Rust since the last time we talked. A few more, but I think Rust is the most interesting one for me.

(00:43:18):

Probably the most requested, I would bet. Yeah.

(00:43:24):

I do not know if it is most requested. It is the most community is willing to help to add this to Wokwi language. Community is really pushing to get it into Wokwi.

(00:43:36):

New microprocessor is hard. I think it would be the hard- If I had to choose, it would be new microprocessor, because in theory you need to support instruction set. So that would be, if it already exists, it would be between I would say a week and a month of work, depending on- Like M0 is probably a week to do, or RISC-V the basic one. And then if you wanted to do M4, it has over 250 different instructions, or Xtensa is also crazy.

(00:44:19):

Other than that, you need a basic set of peripherals. For STM that would be RCC, UART, SPI, maybe timers, I2C, maybe ADC, DMA. And that more or less got you covered.

(00:44:37):

But then in practice, there are a lot of other things that you have to do or to get right in order for this to work. So the first thing you need to do is set up the dev environment. Install all the software, learn all the tools, how to use them, how to run blinky. Usually have a physical port, so I can compare and know if the problem is in the code, or in the simulator.

(00:45:07):

And then there is a lot of undocumented stuff. For the ESP32, we had Wi-Fi that was I think six week effort to reverse engineer. And I talked with Infineon about doing their chips, and luckily they dropped the ball on this, so I do not have to worry about it anymore. That is fine. Yeah.

CW (00:45:37):

<laugh>

US (00:45:39):

But Infineon has- They have those ROMs in the chips, which they hide. So it is another thing that I would have to reverse engineer or work around, if I wanted to simulate that. That is another complexity.

CW (00:46:00):

Well, and if you wanted to do PSoCs, that is a whole other mess. You would have to bring in your Tiny Tapeout tools to make that all work too. <laugh>

US (00:46:09):

Yeah, even with the Pi Pico, we have the PIO which is unique. Or with ESP32, there is the RMT peripheral which is unique. And then there are things like figuring out how the pins are wired, how the clocks are distributed in the chip. The interrupts, how they are wired. The information is out there, but usually it is scattered, and you have to navigate multiple data sheets, some with thousands of pages.

(00:46:44):

On the surface, I could break it down into a list of simple steps. Implement the instruction set, then do these basic peripherals, then get blinky to run, run those set- We have a set of example projects, that should cover the most basic use cases, get them to work, and you are done. But then there are a lot of specific, and a lot of complexities, that hide under the surface and beat you when you think you are done.

(00:47:19):

Yeah. Adding a new language is not that easy as well, because again, you have to set up the tool chain. When we wanted to support Zephyr, it was half a day just to set up a Docker container with all the dependencies that would just build stuff. And since we run things when you press play, we compile your program interactively in the cloud, we want it to be fast. We do not want you to wait ten minutes for things to download and to compile. So there is a lot of work on reducing container sizes, caching things, so compilation goes as fast as possible. I think that is one of the biggest challenges, when I am adding new languages.

(00:48:08):

And then there is stuff like partition tables. If you are on ESP32, then some language or environment or RTOS might not use the standard setup, and you have to worry about that. Or MicroPython and CircuitPython, they expect a file system with your files. CircuitPython has the thing where it implements USB drive, a storage device where you drop your code into to upload it to the chip. So you have to worry about those behaviors, and figure out how they fit with the user experience of Wokwi.

(00:48:50):

And of course there is getting syntax highlighting to work, and getting the indentation right. Because people with Python prefer four spaces, people with Arduino two spaces, somebody prefers stops.

(00:49:10):

Getting dependencies. So with Rust or with Arduino, you want to install third party libraries, because we do not want to reinvent the wheel, or copy paste thousands of lines of code into our main C file, just to get things working right. I think Elecia, you yourself requested three times to add new libraries for the Pi Pico SDK, right? When we started.

EW (00:49:41):

That sounds like something I would do. Yes.

CW (00:49:42):

<laugh>

EW (00:49:42):

Yeah. I also requested some additional peripherals, I think. Or the things that I wanted most.

US (00:49:51):

Yeah, supporting a language is more like supporting ecosystem, with its own convention and user experience. And the way different systems or environments or different platforms upload their code to the board is sometimes different. UF2 versus HEX versus whatever, BIN files. So yeah, I think microprocessor is more complex, but language has its own set of problems and complexities.

CW (00:50:30):

Because languages are not just languages anymore. They are frameworks. They are package systems, and it is a whole ecosystem that comes with language. It used to be you get a compiler, and if you wanted a library, you had to go find a library somewhere else <laugh>.

US (00:50:44):

Now it has cloned the universe.

CW (00:50:45):

Yeah.

EW (00:50:45):

Yeah.

US (00:50:49):

There is sort of dilemma that I am having, which is Wokwi lives on the web, and we want to make it as simple to use as possible. But at the same time Wokwi also lives now in Visual Studio Code.

(00:51:07):

With Visual Studio Code, we do not have to worry about many of those complexities with adding new languages. Because if you are working with Visual Studio Code, then you probably already have some tool chain set up, and you are compiling the firmware yourself, and then Wokwi becomes just a simulator. It does not have to worry about syntax highlighting and dependency management and all of that.

(00:51:34):

So I always have this dilemma, where should I draw the line? What goes into the web? And at what point I tell you, "No, this block project is complex enough. Go work in VSCode. I am not helping you with-"

CW (00:51:50):

You should put up a little thing, "Congratulations! You have graduated from-" <laugh>

US (00:51:56):

"You have graduated the web. Move to VSCode."

EW (00:52:00):

I missed that you were doing VSCode, until I started preparing for the show. I really like that it is in VSCode, but it does have the problem that now I have to have my own tool chain set up. And that was one of the beautiful things about the web, but it also has the bonus of now I can use my own tool chain.

CW (00:52:24):

Yeah. Moving to the actual hardware becomes...

EW (00:52:26):

Simpler.

CW (00:52:27):

Moving back and forth becomes much simpler.

EW (00:52:30):

One of the things I saw with the VSCode is that it is in beta now, and that some of the features will be "pay for" later. Is this how you are going to pay for Wokwi? With VSCode plugins? Or is there-

CW (00:52:41):

Always asking how people are going to pay for things.

EW (00:52:43):

It is open source.

CW (00:52:44):

I know.

EW (00:52:45):

You can start an open source project, and be incredibly passionate about it. And then three years in, you are tired of doing it. There is nobody else who has enough passion to take it over.

CW (00:52:58):

Right. And we really want this one to live on.

EW (00:53:01):

And we want this one to live on.

CW (00:53:02):

So how can we keep this one going?

EW (00:53:04):

I want it to have a profit center, at least enough to pay somebody else to manage it.

US (00:53:09):

Yeah. Visual Studio Code is actually one part of the strategy. Let us zoom out for a moment. And let us look at who is using Wokwi nowadays. What does the user base look like? I do not have very accurate statistics, but rough statistics based on the users that are actually paying right now, about half of them are hobbyists.

(00:53:39):

Hobbyists are great customers. They are passionate. They stick around for a long time, and I love having them. And it is also fun to work with them, at least with most of them. And then about one quarter is students, and you can imagine what working with students is like.

CW (00:54:05):

Do not have to.

EW (00:54:07):

Well, the hobbyists have enough money that it is not a hardship. But students probably see paying for it as a hardship.

US (00:54:12):

Yes.

EW (00:54:12):

And they are whiny, and they want you to finish their homework.

CW (00:54:16):

Hey, come on. We have all been students. Come on. <laugh>

US (00:54:18):

Yeah. I am not saying students are bad. I say they are baddest customers.

CW (00:54:23):

Yes <laugh>.

US (00:54:24):

And then about 10% are professionals, and 10% more or less are teachers. Most of them are universities, some are schools. This is the breakdown of the paying users. By the way, if you look at non-paying users, then teachers grow from 8% to 21% of the users, at least those who respond to surveys, and students shrink from 22% to 10%. So the relative percentage of students is much higher in the paying users, versus all users.

(00:55:13):

I think this is one thing that I would like to see happening. I would like the university to pay, and not the students. If we keep getting or if we keep focusing on education, that is also a good question. Should we keep focusing on education, or try other bets? But if we do, I think that one of the goals would be to get universities on board, so we do not have to get money from students. We do not have to have them as customers, but as happy users.

(00:55:50):

The other thing I would like to try, is to get more professional users to use this professionally. And then hopefully they will also be able to afford this, to pay for it, and stick it with us for a long time. And there are two ways that I am trying to make it happen. The first one is the Visual Studio Code extension, which Elecia has just discovered about. A new toy to play with. And can you guess the second one?

EW (00:56:24):

Tiny Tapeout?

CW (00:56:25):

Please do not say an IAR extension.

US (00:56:28):

No, I would not do that.

EW (00:56:29):

<laugh>

US (00:56:32):

I have to keep this fun for myself as well, right.

CW (00:56:34):

<laugh>

US (00:56:37):

Yeah, so the second one- Tiny Tapeout is totally separate thing.

EW (00:56:42):

Yeah.

US (00:56:42):

But under the umbrella of Wokwi, the second one using Wokwi for continuous integration.

CW (00:56:51):

Oh, geez. Yeah, that is huge.

EW (00:56:53):

Okay. Yes. Edtech is pretty separate from this sort of continuous integration. These are going to be very different customers.

US (00:57:06):

Right. So the idea is that if you have a setup that works inside VSCode, it is super simple to just take this project setup, and if you can build it automatically let us say in GitHub actions, then you are already halfway there. All you need to do is just- It is currently in alpha or beta or pure C, I do not know how to call it.

(00:57:33):

But there is a Wokwi CLI which you can install locally or in your CI. It can take Wokwi for VSCode project, like the same folder structure, and run it in- It runs remotely on our servers. So it is being simulated in the cloud, and you can get the output.

(00:57:56):

You can also write scenarios, which are YAML file that interact with the simulated code. Like, "Push this button. Now wait 500 milliseconds. Now check if the serial output contains this string. If it does, great. If no, fail." So it is still very early stage. And I actually wanted to share this in the Embedded Slack. Maybe I will after the episode goes up.

EW (00:58:37):

You totally should. But a lot of professional companies who like these sorts of things, do not want things to run remotely. They would rather have their CI systems not have their buggy code out in the world anywhere.

CW (00:58:56):

Ah, all the Fitbits are running on AWS.

EW (00:59:01):

Well, AWS is kind of special.

CW (00:59:02):

Okay.

US (00:59:04):

Okay. Yeah. I also want them to run it locally. So the idea is like this, you start with the cloud because it is super easy. You do not have to set up anything, just to install a CLI, or there is even a GitHub action that you can use in your GitHub automation. Just five lines of YAML code, and you get the simulation.

(00:59:27):

So you can tinker with it using our cloud. And then when you feel like, "Okay, I am ready to use it. I want to use it on my production code." Then you can just purchase an on-premise license, and then you are running it on your whatever infrastructure. We are just providing the software. No more worrying about infrastructure for me.

CW (00:59:56):

<laugh> Right.

EW (00:59:58):

Do you have- Classpert has mentioned that they wish that there was something they could run.

CW (01:00:08):

Classpert being the educational company that you teach your class through.

EW (01:00:12):

Right.

CW (01:00:13):

People might not know.

EW (01:00:15):

So should I be going to Classpert and say, "You know, Uri is ready to take some of your money, and you can run it locally"? Or are you focusing on the locally for CI, instead of edtech?

US (01:00:33):

So, how do I choose what to work on?

EW (01:00:35):

Yeah.

US (01:00:35):

I think we touched it last time. So it is a combination. It is a fine combination of what brings business value, what brings value to the world, and what brings me fun. I have to find the right balance. So if Classpert is willing to pay, and it is going to be fun for me, and it brings value to the world, then we have three checks, and yes, it can happen.

(01:01:00):

Make the connection, let us see what happens, how it goes. I mean, you already made the connection. Just make Felipe- That was his name, right?

EW (01:01:10):

Yeah.

US (01:01:10):

Felipe. Make Felipe listen to this podcast, to this episode. And if he says at the end, "Hey, Uri, here is my money. Just make this work." Yeah, we can talk. We can talk anyway even without money. I sort of like that the guy-

EW (01:01:29):

You cannot say that. You cannot say that you are ready to take his money, and then say no, you do not really need his money. You have to be fierce. Give me all the money.

CW (01:01:37):

Not sure negotiating contracts on podcasts is effective.

EW (01:01:40):

Not with me, no <laugh>. I do have a couple of short listener questions.

US (01:01:44):

Sure.

EW (01:01:46):

Some of which we have already talked about, but Peter Griffin would like the Teensy 4.0 or 4.1 to be supported as a processor/board. Is that on the roadmap?

US (01:02:00):

Yeah, so the roadmap- The way we work with the roadmap is that there is a public GitHub repo, where users can suggest the features, and then users can vote for them. Teensy 4.0, I do not think it has been suggested so far. 3.2 was suggested, it did get some votes, but not a substantial amount.

(01:02:25):

Since this is a pretty complex microcontroller, it would need a substantial amount of work from my end. So we would need a very good business case. That being said, I think there has been some guy who wanted to create or to implement it as part of his thesis, but he since has disappeared.

EW (01:02:50):

Yeah. Grad students.

US (01:02:51):

Yep.

EW (01:02:54):

You can buy votes, by being part of the Club. Then if you want to vote for something, you can totally stack the deck.

US (01:03:05):

You can totally.

EW (01:03:09):

A question from Dana. She wanted to know more about the dancing servos, which I want to know anything about the dancing servos.

US (01:03:19):

Well, Dancing Servos is why I love this. Why I love Wokwi. It is one of the best examples of how creative engineers can get when you give them the tools. The person who made this, I am not sure why he created that.

(01:03:40):

He did all sort of other crazy things with Wokwi. Like, he had another project where he wanted to show how you can use multiple I2C buses with Arduino Mega. So he took 30 LCD displays, and created a seven-segment four digit display out of them.

CW (01:04:05):

Okay. <laugh>

US (01:04:07):

Each LCD screen would be one segment, and when you turn it on, it would be lit like this segment is on. And when you just throw the screen blank, it would be off. So create a seven-segment display out of discrete LCD screens. Again, I am not sure why he did it, but it was hilarious.

(01:04:32):

In both cases, the seven-segment display from 30 LCDs and these dancing servos, it shows you the power of the simulator. Because you could get really creative with engineering, and create really- I do not know, I do not even have the word to describe it - extraordinary, out of the box, or useless, but super cool things.

(01:05:03):

But doing it with real hardware would be- I mean, where would you get 32 servos, or 30 LCD displays just to test this idea? How would you power them? What would you do with them after you finished your project? Would you just sell them? Give them away? Or just have a big pile of projects that you build, just because you wanted to show it is possible? Fill up your house? And how could you share this with others? By taking a video and then scrapping the project?

(01:05:44):

Now all of those problems are gone with Wokwi. You can just build whatever project you imagine. And then if the purpose was just to show that it is possible, or just to experiment with the limits, then you put it there on Wokwi for other people to see. And then come up and ask questions on podcasts about, "What is those dancing servos? How did they come to be?"

EW (01:06:13):

I think I have found the right project. I think it is called "ServoOverdone."

US (01:06:18):

No, that is- I am actually not sure. Maybe it is. Let me check. It is linked from the home page, and it has like- Yeah, this is the one, yeah, with the circle of servos.

EW (01:06:31):

It is very amusing. I understand what you are saying. It allows you to do something absurd, just for the fun of it, just for the joy of it, that would be expensive or...

US (01:06:48):

Impractical.

EW (01:06:48):

Too silly, impractical to do live. And yet, looking at this, it kind of makes me want to make a live one, because it would be exceedingly charming <laugh>. But I would not want to do-

US (01:07:04):

So do it. <laugh>

EW (01:07:05):

Exactly. <laugh>

US (01:07:08):

That is the power of it. One person had the idea, but he could tell you about it, and maybe you would get a message across. But with Wokwi, he could show you his idea, and then maybe somebody else who has the time, money, or I do not know like ambition, could actually make the project. Making the connection between the idea and the person who can actually create it. That would be amazing.

EW (01:07:35):

And as a team thing, it lets multiple people add their piece to it, without having to be in the same room.

CW (01:07:47):

Yeah. You know you can get servos for just a couple bucks, right? So you are talking about a hundred dollars worth of servos maximum.

EW (01:07:55):

And the power-

US (01:07:55):

And power supply.

CW (01:07:56):

Big deal. Power is easy.

EW (01:07:59):

Power is not.

US (01:07:59):

For you. <laugh>

CW (01:08:00):

Power is always easy. <laugh>

EW (01:08:02):

You are going to blow up that poor little Arduino so fast.

CW (01:08:04):

You just buy a giant wall wart. <laugh>

EW (01:08:07):

A whole bunch of-

US (01:08:08):

Yeah. Just power them from the five volts of the Arduino. That would be fine <laugh>.

EW (01:08:13):

What could possibly go wrong? Well, you have been working on Tapeout since we talked to you last, and you did not tell me. Is there anything you are working on now, that you want to tell me?

CW (01:08:22):

<laugh>

EW (01:08:22):

Do you have any new projects?

CW (01:08:27):

In between all of this stuff that we have discussed, that obviously takes-

EW (01:08:30):

Oh my goodness.

CW (01:08:30):

Amazing amounts of time. What else have you been doing? <laugh>

US (01:08:36):

I think I spent a month this year, reading a web serial. It is called "Worm." But yeah, if you value your time, do not get into this. It is a huge time sink. I think, "All work and no play makes Jack a dull boy" is really true. You have to know how to take breaks. Even working on two projects on the same time, Tiny Tapeout and Wokwi sort of allows me to take breaks.

(01:09:12):

So I can for a few days just focus on Tiny Tapeout. And I do not know, try to add a new USB CDC peripheral, and- I would not say forget about Wokwi, but put it on the back burner for a few days. Or just sit for a week and read a web serial, and try not to do too much on the other projects, other than the essential. At least for me, that what works, and helps me stay with this for a long time, in this business of doing complex software.

EW (01:09:55):

Yes, sometimes working on something else is as good as a break. Not always, but sometimes. And it is good to have the two. Before we let you get back to these projects, which again, I want to say are very cool. Do you have any thoughts you would like to leave us with?

US (01:10:17):

Yeah, two things. One of them, one thing that changed in Wokwi- I prepared the list for the talk, of the most important changes that happened since last time. So one of them, and this is where I would love the audience to come in, is we recently released the Customs Chip API, which allows you to create new parts for Wokwi. You can write code in C, or in any other language that compiles to WebAssembly, like Rust.

(01:10:48):

Basically you can create- We have seen people creating e-paper displays, the one-wire temperature sensor from Dallas, and somebody even created a better real-time logic analyzer, and a scope using this Custom Chips API. I would really love to see more cool things that people do with this. Not only creating new parts, but also creating new tools for the users of the simulator. So that is one thing.

(01:11:26):

One maybe more generic thought, "Relax for the same result." Look for this blog post by Derek Sivers. It is something that I am also trying to apply when working on Wokwi, Tiny Tapeout, or any other project. Do not stress yourself too much. Relax for the same result.

EW (01:11:49):

I think you are in the enviable position of truly enjoying what you are working on. And I am excited about that, because you are working on neat things.

US (01:12:00):

<laugh> Thanks.

EW (01:12:02):

Our guest has been Uri Shaked, Maker and serial warranty voider. You can find his simulators at wokwi.com. That is whiskey oscar kilo whiskey india .com, and tinytapeout.com, which is spelled just as it sounds. There will be links in the show notes, of course.

CW (01:12:24):

Thanks, Uri.

US (01:12:26):

Yeah, you are welcome. By the way, you forgot to ask me, or we did not talk about, the oddest feature that has been requested.

EW (01:12:36):

That is true. What is the oddest feature that has been requested? I hope it was not my, "Can we add Git to this somehow?"

US (01:12:42):

Oh, no, that is-

CW (01:12:43):

That is not odd.

US (01:12:43):

Certainly not the oddest. Yeah, I spent half an hour today going through the feature list, trying to hunt for the oddest one. I think there have been a few, like there is magic smoke, that comes up every now and then.

CW (01:12:58):

<laugh>

EW (01:13:00):

That would be cool. I want fire! Yes. Okay.

US (01:13:05):

Or fire, right. And then there was someone who just open an issue with the title, "Good Morning," and no other information in it.

CW (01:13:12):

<laugh>

US (01:13:16):

But I think the most jaw-dropping features that I got, is somebody complained that I put privacy behind paywall. Because when you save a project, if you want to make it unlisted, you have to join for the Club. So he explained to me why it is wrong to put privacy, like "You can take money for other features. But do not take my money if I want to not to share my project publicly by default." So that is the most jaw-dropping feature.

(01:13:49):

And I think the most "what the hell" feature I got, is user complaining that printing code from Wokwi does not work.

CW (01:14:03):

Like on a printer?

US (01:14:05):

Yes! On a printer. Apparently.

EW (01:14:09):

Okay. I am sure there are ways people could solve that, that do not involve you having to do anything at all. <laugh>

US (01:14:16):

Right.

CW (01:14:17):

Yeah. They could use the custom peripheral thing, to make a simulation of a 1980s Epson dot matrix printer. And it could form feed out on the screen, and then you could take a screenshot of that, and print it out.

EW (01:14:33):

<laugh>

US (01:14:34):

I like how fast you apply things that you have just learned. Amazing. Yes! Use Custom Chips for everything.

EW (01:14:45):

Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listener Slack group for their questions. And thank you for listening. You can always contact us at show@embedded.fm. Or hit the contact link on the embedded.fm website, where you can also find show notes and transcripts.

(01:15:03):

And you know what? I am afraid that the quote also went on vacation with the lightning round questions. I do not know what is happening there, but I wish them well.