Embedded - 454: Printf Hello

Episode Date: July 6, 2023

Uri Shaked surprises us with a chat about silicon design when we were expecting to talk about a web-based board simulator.  If you want to try your hand at silicon design, check out Tiny Tapeout, a way to possibly get your design on to real silicon. The digital design guide is a great way to start looking at how chips work. If you aren’t quite ready for silicon, Wokwi has a Verilog simulator where you can learn to do the digital design. The Verilog Simon Game on Wokwi is amazing.  Wokwi is a web-Based simulator, simulating processors, boards, and peripherals. You can build a whole system there, from Dancing Servos to 7-Segment display from 30  LCDs and Arduino Mega to Raspberry Pi Pico boards you can program in C when you click More Options on the front page. You can also create your own peripheral using the Chip API. Or learn to use Zephyr on Wokwi. And now there is Wokwi for VS Code.  All that and Wokwi is open source: github.com/urish Uri recommends reading Relax for the same result by Derek Sivers Previously on Embedded 396: Untangle the Mess Transcript

Welcome to Embedded. I am Alicia White, here with Christopher White. Our guest this week is Uri Shakad, the creator of Walkwee. That sounds familiar. Well, he's been on, but we have so much more to talk about because Walkwee has grown so much. Hi, Uri. Thanks for joining us again. Printer, hello world.

Could you tell us about yourself? Yes. So I don't watch TV. I don't 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. And throughout my career, I've started as a web developer, more or less, and expanded to other areas. I did blogging, live streaming, and even tried my luck with a hardware crowdfunding project.

It didn't go very well, but it was fun. And now I'm working on two projects, WalkWe, which you already know, and TinyTapeOut, which Chris knows about, but hasn't shared a tote with you yet. Well, Lightning Round is on vacation this week. Partied too hard last weekend. And so let's get straight to all of the questions I have about these things. Let's actually start with Tiny Tape Out, since you guys surprised me with it right before the show started. What is that? So Tiny Tape Out is something that sort of happened out of the same conference where you and I met. That was the Hackaday conference two years ago.

And I really loved your talk about Ramlandia. And I think other than your talk, there was another guy, Matthew Venn, which I think I connected you a few months back. And Matthew gave a talk about designing ASICs, so custom chips with open source tools. And 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 uh you go to college

and study this or you have a lot of money to throw with it and you just uh throw uh tens of thousands of dollars on software and uh manufacturing costs And then it will probably fail because you have no idea what you're doing. So you're probably going to make all the trivial mistakes. So Tiny Tape Out is trying to solve it. And it's a part of a bigger thing, which is it's open source slowly creeping out into this whole subject or area of custom ASIC design. And Tiny Tape Out 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. All right.

Well, that seems kind of impossible, so there must be some kind of trick involved here. I worked at a fabulous semiconductor company, and we were probably making much more complicated things than people make on Tiny Tape Out, but I remember it being very hard and very expensive. And it involved flying to TSMC and arguing with people. So, okay.

So, how do you do this? Yeah. Yeah. Yeah. It's simple, but it's also like there are a lot of moving parts that have to work together for this to happen. And I think the first one is open source. So fabs are starting to open source their PDKs, their 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 like buy licenses for expensive software before you

could even like start actually working on your design. And nowadays there are, I think, already three different fabs that have open sourced their digital PDKs. And there is a growing number of open source tools and solutions 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. So 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.

The other problem that is left to be solved is costs and complexity. Like, even though these tools exist and the PDKs are open, it's pretty complex to set up all the things on your computer. And Tiny Tape Out tries to tackle these two subjects. So for complexity, we have set up a GitHub action that wraps all those tools. 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 don't know Verilog,

we extended Workweek to support designing stuff with Logigate. So you can just drag a few Logigates, connect them, and create your digital design visually in Walkway. And then the GitHub action takes either the Walkway 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 style. uh dl hell hell style um and then i think the more intriguing part which is uh what chris asked about is how is it possible to make it so cheap i i am boggled because i've worked with companies

who wanted to make chips and i've worked with companies who wanted to make chips. And I've worked with companies who have made chips. And it's 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 $2 million sitting in cash for ARM to take? Because if not, you're not doing this. Well, that's for an IP core. Right, but that's for an IP core. But then even 8051s, it still is hugely expensive, and it's partially

the engineering cost of putting it together and testing it, but it's also largely just working with the vendors in the silicon. Well, I think we're making simpler things. Right, right. I mean, I saw on the website that it's like adders and barrel rollers. I got that. Okay, okay. But I'm just, the base cost has always been hundreds, if not millions of dollars to get started in this area.

And I mean, hundreds of thousands or millions of dollars. And now you're telling me that I can do it for hundreds of dollars. And I'm just. Yes. I mean, that's more than Moore's law. I mean, that's wow. Okay. I'm done being shocked. So you can go on.

Okay, so the basic trick is that usually you don't need a lot of area to test something, if you just want to test something like, let's say, UART peripheral or even a small microcontroller core, you don't need a whole DAI area. But it's not really easy to buy just the amount of space that you need. And I haven't 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... Osh Park. Is this Osh Park for chips? You nailed it. In a way, this is Osh Park for chips.

It's 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's not like we can create a different version of the chip for anyone who submits the chip. 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.

Because chips are so small, unlike Oshpark, you don't need to deep analyze them, you just ship everyone the whole thing. But doesn't everybody need pins? I mean, and it isn't just the silicon, you do have to put it in a package. Yeah, so that's one of the reasons we are shipping. That's the other reason we are shipping everyone the same copy or 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. 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 8 plus 10, so that's 26 IO pins. Or that's 10 inputs, 8 outputs, and 8 bidirectional pins. And you can do whatever you want with them as long as it's digital. 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 like it takes months if not years to iterate and get our designs made so it also like it also means that we can 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. What happens if one person's design is flawed and it takes over the chip? Do you end up nobody else can use the chip? Or how are you preventing that? That would be a disaster, right? Right. 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 isn't really a reason why your design would create a disaster for the chip. We are also looking at what people are submitting and it doesn't 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 don't have short circuits and you comply with all the design rules. 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's not active. So even if you did something really horrible, as long as someone else doesn't activate your design, then nothing bad happens, right?

And with Walkway, it's very much simulation. But this is simulation of code running on boards and chips. But this is physical. Is there a level of simulation to Tiny Tape Out? So, yeah, Walkway is a simulation, and the core of Walkway, and we didn't even explain what Walkway is, so if you don't know, bear with us. That's a good point. So, the core of Walkway, other than the microprocessor simulation, there is a digital simulator.

And if you want to simulate digital logic, then it fits. Like the engine, the digital engine of WOC, we can also simulate like AND gates and OR gates and NANDs. And we even have like, and I have this on my list of features that I will mention later but later but we even have uh some basic very log simulation support so you could even run like very low code

and create like a chip inside wokwi and simulate that that's really cool thank you with tiny tape out i see that there are puzzles I could do to help me understand how to put together the logic gates. Is that the best place to start? Or do I need to have an application in mind? Where do I start? That's a great question. And I think the answer is always in engineering, it depends. What are your goals? Are you an enthusiast looking to get like 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 like design something meaningful? Or I wouldn't say meaningful, more complex. So it really depends what your goals are. If you want just to play Tinker and sort of close the loop with the simplest thing possible, then just go over the tutorials and use Walkway with the visual editor. And you could create a project that, I don't know, like 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. If you want to learn Verilog or other hardware design language, then I would start with taking some course, which we currently don't offer, but some training on how to write Verilog. And then we have like an example project in Verilog where you can just drop your code and get it through the flow of generating a GDS2 file. And I think the most important resource is the Discord server of Tiny Tape Out,

where you can just pop in and start asking questions and 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. But you've had three tapeouts? Yes, we had three tapeouts, but none of them has returned from fabrication yet. The chip that I got was an experimental tape out of Google in combination with eFabulous, which is the contractor we are working with to do the manufacturing. And it had a surprisingly low turnaround time of just six months.

So this is a design I submitted in December, surprisingly low turnaround time of just six months. So this is a design I submitted in December and I got it back two days ago. And 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? Doing tiny tape out? Sure. I'm going to ask the same question about WalkWe, but I have more detailed questions. Let's start with tiny tape out sure i'm gonna ask the same question about walkway but

i have more detailed questions okay let's start with tiny tape um so with tiny tape out um it's sort of like you say like uh we want to be the osh park of um open source or of ASICs. We'll start with open source. Maybe eventually we can also offer a similar solution for commercial users. So our product is selling you space on the chip. If we manage to sell enough of those, we are going to be profitable. If we don't, then it's been nice goodbye tiny tape out i hope

the first one will be uh actually even if uh it doesn't work uh it's still been so far a very fun ride and i met uh matthew and working with matt van is like uh so much fun. I learn a lot. So even if it doesn't work out, I'm good. But that's the plan, just selling slots on Silicon, selling pieces of Silicon. It seems like it would be a fantastic teaching resource, but the 12-month turnaround means it's 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?

Yeah, so it's a good question. We are still like 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 Tape Out, 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. But yeah, I mean, 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 don't want to be too optimistic and give a number and then we won't 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 won't be as fast as PCB that you can get in like 24 hours. No, it won't ever be there. But let's say a couple of weeks might not be impossible. That would be... Very hard, yes. I don't think it would be impossible. And it can't be the 24-hour PCB times, because silicon chips like this have real chemistry they have to do.

They're grown in dank caves. It takes a long time for the crystals to grow. Kind of, but not you also need unicorn dust when manufacturing them and that's really hard to obtain yes exactly but there are physical limitations to the time frame. How does this, well, actually let's go back to walk. We, um, could you explain what that,

what that, what walk we is? Uh, just a moment. I need to switch this, my mind to turn the switch to the other mode now from tiny tape out to walk. We, uh,

can I get a good sound effect from you, Chris? Okay. Yeah, I remember last time you had to play samba. That's right. Okay, so Wokwi. So for those who don't know Wokwi yet, yeah, what Wokwi is, let's start by describing the problem that WorkWe 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 like all those heavy tool chain and IDEs that you need to install. 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 don't have years of experience doing so. So OQI 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, PIPICO,

Arduino, and many common electronic parts like displays, sensors, motors, even Wi-Fi. Logic analyzer? That was my surprise for later. Oh, I-Fi. Logic Analyzer. That was my surprise for later. Oh, I'm sorry. Yeah, Logic Analyzer. I love the Logic Analyzer. No, that's fine. 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 don't have to fiddle with tool chains. And 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. And any other person opening this link can just run your project and pick it up from the place or from this state where you saved it. So sharing electronics, embedded projects

become very easy, just sharing a link. 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. You can't blow up your web browser. Oh, I can do that.

You can, blow up your web browser. Oh, I can do that. You can, you can. I can even tell you, if you want, how you can create a circuit in WorkWeb that will kill your browser tab. Well, there's no magic smoke that comes out. It doesn't stink up your office. It 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 generic projects on Raspberry Pi Pico and STM3. And as far as I understand it, you've done all of that.

Is that right? And more. So you can basically do anything you can do on a dev board on Walkway first, pretty much. Well, the two STM32s are supported as nucleoboards. And I think they're both Cortex-M0s, right? Or is one of them an M4? So the two officially supported ones are both M0. There is an unofficially supported one.

I think it's the L432, if I'm not wrong, which is M4, but nobody except you, Chris, and a couple of people now knows about it yet. We'll keep it quiet. Yeah, no one will hear this. Thank you. And if I remember correctly, you have written the simulators for all of those processors. These are not things that you bought somewhere and put in an IP core. You actually reverse engineered the processor. And they're processor simulators, not board-level simulators. Right. You're dealing with actual assembly instructions.

Yeah, we all have trouble to deal with. These are my troubles. It's just amazing the pace you actually have managed to do these things in. It's super impressive. Thank you. It's super handy, too. I mean, I taught the class perk course, and we used Wakwisam, especially when we were talking about hardware that we didn't all share, or when a student would ask a question and I couldn't reproduce it, I could ask,

could you give me a minimal example on Walkway? And usually that solved their problem. 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 Walkway. You can certainly make it work on your system. It was really nice for that. But it was all, at that point it was Raspberry Pi Pico and I was using the SDK, which was pretty cool. I hadn't 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's the Wi-Fi version. But STM32 has hundreds of different different processors, siblings and cousins and M zeros and M fours and M sevens are 92s. I don't

know. Uh, how, how can you support that infusion of new processors all the time? That's a good question. So I think, first of all, I'm trying to. I'm not always very successful at that, but I'm trying to support use cases rather than microprocessors or peripherals. So I'm trying to see what people want. And maybe we don't have to support every single part that STM has ever created, right?

Like with AVR, we don't have every single AVR board that was ever created. We just have the most popular ones. And if there is some customer that tells me, hey, I need this specific SDM part and I'm willing to pay for it, then yeah, that's a good reason for me to go and work on that. So it's sort of 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? And 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. Are there tools to help you? I mean, 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's really not about that yet or ever.

Come on. I'm a developer. I'm an engineer. I'm a developer. I'm an engineer. I'm lazy. I'm 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'm pretty sure you're familiar with Renode.

Yes. So Renode is interesting because it's an open source project with a permissive license. It actually comes or it actually comprises two parts. The first part is the core simulation, the actual instruction set, which is using, or they implemented it using Tlib, which is a part of QMU. It's just like the simulation engine of QMU. And if I'm not wrong, it's written in C, maybe C++, one of them. And then on top of that, they build all the devices and peripherals in C Sharp. 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 Sharp. Maybe I can run C Sharp in the browser and just use Reno to simulate all the peripherals. And I tried that. And then I said, maybe I could just convert some of their code from C Sharp to TypeScript. And I tried that as well. But eventually, the biggest problem is not really creating the code, it's 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 mean, I could spend half a day just hunting for a bug that happened because I misinterpreted a single bit in a peripheral or I didn't get a state machine right. So getting the SVD files or converting what Reno did to TypeScript could save some time.

It's easier to get the registers from SVD files than copy-paste from datasheet, and it's probably less error-prone. But usually the hardest part is actually understanding the underlying logic, and sometimes things are not really documented.

One example, when 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 and looking at the documentation

I thought there are different modes like you configure the peripheral to calculate SHA-256 then you put in the data you tell it to do your then you put in the data, you tell it to 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. And only by spending two days and comparing my behavior

with the hardware, I realized that if you initialize, I don't 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 sort of continue the calculation and give you a different output compared to if you just started with the original with one charMod and stayed into it. I'm not sure I explained this correctly, but the specifics are not important. The point is that there is some shared state that one would assume doesn't exist, but it does. And, well, I mean, that actually doesn't tell you that, right? Nor the SVD files.

And that's what takes most of the time. Findings, those places where things are not as documented or not as you assume they would work. That's important because people tend to either rely on those behaviors without realizing it or they're 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 doesn't show up. So yeah, 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? Yeah, I mean, do you know what's Galois multiplication? I probably used to. Galois, G-A-L-O-I-S-E no E I don't even know how you spell it that's fine I didn't know what it was

until I had to implement I think it was for the RSA peripheral this specific thing that you only use for this like if you google it you will see that you will use for this, like if you Google it, you will see that you will always use it for a specific algorithm that speeds up this RSA. And the hardware is expected to implement it.

And you need to do it exactly the same way the hardware does. And usually when you have hardware peripheral that accelerates some kind of computation, it won't do the whole things. Like it won't just calculate RSA because if you just had to do like, I don't know, encrypt with private key or decrypt with private key, I could just use some off-the-shelf library and give it the inputs and get the outputs. Usually, it actually 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 call-up and multiplication.

Yeah, that reminds me of working with a graphics accelerator that we had on a Cortex-M4 that nobody else had, and it could do a lot. But like you're saying, it kind of went three-quarters of the way there, and then you had to kind of understand how it worked and take the results and do the rest in software because they weren't going to do it all for you. And there's a lot of matrix math and stuff like that. It was like, oh, cool, you're 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're not going to do that for me. Yeah, I think that's extremely common in these, quote, accelerators.

And people think, oh, I got an accelerator. I can just say, you know, compute this. Give me a yes or no. And it's like, no, you have to read a long data sheet. And so making something that only partially works also must be complicated. Do you ever have to read the errata in order to break your implementation uh so wait chris you you say you are you have experience with that right yeah okay i know who is going to uh do the next uh the next one i guess thank you oh no i'm retired

that is not true i'm retired until next week. Yeah, we will un-retire you. Yeah, but I think I'm mostly done with, I hope I'm mostly done with all those peripherals or with the most important ones, at least for the time being. So I2C is a protocol that has a lot of state that most people don't realize, where SPI is a simpler thing from a hardware perspective, from a chip perspective. And it's just better. processors, does this peripheral change much between the processors? Or have you mostly standardized on a walk-wee spy peripheral that you can

move, drop in from instance to instance of different processors? I wish. 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 SPI and I2S into one peripheral. Wait, what? No. Why would you do that?

I mean, not I2C, but I2S. It's the audio thing. Okay. Yeah, I mean, like, each one has, or the ESP32 decided that it would be nice to give the software a way to break down a SPI transduction into, like, address phase, like, a transmit phase, receive phase, dummy phase. So you can actually configure all those like parts with different buffers and tell it, hey, now do your thing instead of just telling it like giving some kind of generate interface. Because when you work with spy flash or spy RAMs, then you actually use those phases when you talk to them. So even though spy is quite simple,

and the AVR spy is heaven, it's super simple. Just send this byte or get this byte, and we are done. My other MCcus are creative and they find a way to make their own spy unique and shine above the rest so yeah unfortunately uh even for something as common as spy or as simple as you would guess a spy and by the way what what about Q-spy? And FIFOs and DMA. There's all sorts of ways you can break the simple spy. Yeah. Every time we talk to you, I just keep shaking my head. I don't understand how you do any of this. It's so much work. It's so intricate. It's really cool. Is it harder to support a new microprocessor or to support a new language?

Because you support a lot of languages. Yeah, we added Rust since the last time we talked. A few more, but I think Rust is the most interesting one for me. Probably the most requested, I would bet, yeah. I don't know if it's most requested. It's the most community is willing to help to add this to Workweek language. Like community is really pushing to get it into Workweek. And new microprocessor is hard.

Like I think it would be the hardest. Like if I had to choose, it would be new microprocessor is hard. Like, I think it would be the hardest. Like, if I had to choose, it would be new microprocessor. Because in theory, like, 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, like the basic one. And then if you wanted to do M4, it has over like 250 different instructions

or extensa is also crazy. And then other than that, you need like a basic set of peripherals, like for STM, that would be RCC, UART, SPI, maybe timers, I2C, maybe ADC, DMA. And that more or less got you covered. But then in practice, there is 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, like install all the software, learn all the tools, how to use them, how to run Blinky. Usually I have a physical board so I can compare and know if the problem is in the code or in the simulator.

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

Yeah. But Infineon has, they have like those ROMs in the chips, which they hide. So it's another thing that I would have to reverse engineer or work around if I wanted to simulate that. And that's like another complexity. Well, and if you wanted to do PSoCs, that's a whole other mess. I mean, you have to bring in your tiny tape-out tools to make that work too.

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

So 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 those sets. We have a set of example projects that should sort of 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. Yeah, so adding a new language isn't that easy as well because, again, you have to set up the tool chain. When we wanted to support Zephyr, it was like 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 press play we compile your program interactively in the cloud we want it to be fast we don't want you to wait 10 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 and i think that's one of the biggest challenges when I'm adding new languages. 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 a USB drive, a mass storage device where you drop your code in 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 WalkMe. And of course, there is like getting syntax highlighting to work and getting the indentation right

because people with Python prefer four spaces, people with Arduino, two spaces. Somebody prefers tabs. Getting dependencies. So with Rust or with Arduino, you want to install third-party libraries because we don't 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, Elisa, you yourself requested like three times to add new libraries for the PyPico SDK, right? When we started. That sounds like something I would do, yes. Yeah, I also requested some additional peripherals, I think, were the things that I wanted most. So, yeah, so supporting a language is more like supporting an ecosystem with its own convention and user experience

and the way different systems or environments upload 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. Because languages aren't just languages anymore. They're frameworks, and they're package systems, and it's 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 the library somewhere else. No, it's clone the universe and then. Yeah. There is a sort of dilemma that I'm having, which is WorkWe lives on the web, and we want to make it as simple to use as possible. But at the same time, WorkWe also lives now in Visual Studio Code. And with

Visual Studio Code, we don't 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 Walkway becomes just a simulator. It doesn't have to worry about syntax highlighting and dependency management and all of that. So I always have this dilemma. Where should I draw the line? What goes into the web?

And at what point do I tell you, no this plot project is complex enough go work in vs code i'm i'm not helping you with you should put up a little a little thing uh congratulations you've graduated from you've graduated the web move to vs code i was i missed that you were doing VS Code until I started preparing for the show. And I really like that it's in VS Code. 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. Yeah, moving to the actual hardware becomes...

Simpler. Moving back and forth becomes much simpler. One of the things I saw with the VS Code is that it's in beta now and that some of the features will be pay-for later. Is this how you're going to pay for Walkway with VS Code plugins? I'm always asking how people are going to pay for things. It's open source. I know.

You can start an open source project and be incredibly passionate about it. And then three years in, you're tired of doing it. There's nobody else who has enough passion to take it over. Right. And we really want this one to live on. And we want this one to live on. How can we keep this one going? I want it to have a profit center, at least enough to pay somebody else to manage it. And we want this one to live on. How can we keep this one going? I want it to have a profit center,

at least enough to pay somebody else to manage it. Visual Studio Code is actually one part of the strategy. So let's zoom out for a moment and let's look at who is using WorkWe

nowadays. What does the user base look like? I don't have very accurate statistics, but rough statistics based on the users that are actually paying right now. So about half of them are hobbyists. And hobbyists are great customers. They are passionate. They stick around for a long time and i love having them and it's also fun to work with them at least with most of them

and then about uh one quarter is students um and you can imagine what working with students is like. Don't have to. Well, the hobbyists have enough money that it's not a hardship, but the students probably see paying for it as a hardship. Yes. And they're whiny and they want you to finish their homework. Come on, we've all been students. Come on. Yeah, I'm not saying like students are bad.

I say they are bad as customers. Yes. like students are bad. I say they are bad as customers. And then about 10% are professionals and 10% more or less are teachers. Most of them are universities, some are schools. And this is like 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 service, and students shrink from 22% to 10%. So the relative percentage of students is much higher in the paying users versus old users. And 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's also a good question. Should we keep focusing on education or try other paths? But if we do, I think one of the goals would be to get universities on board so we don't have to get money from students. We don't have to have them as customers, but as happy users. And then 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 like two ways that I'm trying to make it happen. The first one is the Visual Studio Code extension, which Alicia has just discovered about, a new toy to play with. And can you guess the second one?

Tiny tape-out? Please don't say an IAR extension. No, no, no. I wouldn't do that. I mean, I have to keep this fun for myself as well, right? Yeah, so the second one, Tiny Tape Out is totally a separate thing. But under the umbrella of Walkway,

the second one is using Walkway for continuous integration. Oh, geez. Yeah, that's huge. Okay, yes. EdTech is pretty separate from this sort of continuous integration. I mean, these are going to be very different customers. Right. So the idea is that if you have a setup that works inside VS Code,

it's super simple to just take this project setup and if you can build it automatically, let's say in GitHub Actions, then you are already halfway there. All you need to do is just, it's currently in alpha or beta or POC, I don't know how to call it, but there is a Walkway CLI,

which you can install locally or in your CI, and it can take Walkway for VS Code project, like the same folder structure, and run it in... It runs remotely on our server, so it's being simulated in the cloud, and you can get the output. And you can also write scenarios,

which are YAML files that interact with the simulated code, like push this button. Now wait 500 milliseconds. Now check if the serial output contains the string. If it does, great. If no, fail. So it's still like very early stage. And I actually wanted to share this in the embedded Slack,

but maybe I will after the episode goes up. You totally should. But a lot of professional companies who like these sorts of things don't want things to run remotely. They would rather have their CI systems not have their buggy code out in the world anywhere. All the Fitbits for running on AWS. Well, AWS is kind of special. Okay, so yeah, I also want them to run it locally.

So the idea is like this. You start with the cloud because it's super easy. You don't 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. So you can tinker with it in using our cloud. And then when you feel like, okay, I'm 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 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. Right.

I mean, do you have... Classpert has mentioned that they wish that there was something they could run. Classpert being the educational company that you teach your class through. Right. People might not know that. So should I be going to Classpert and say, you know, Uri's ready to take some of your money and you can run it locally?

Or are you focusing on the locally for ci instead of ed tech um it's so how do i choose what work on i think we touched it last time so it's a combination it's a fine combination of uh 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's going to be fun for me and it brings value to the world, then we have three checks and yes, it can happen. Make the connection. Let's see what happens, how it goes. I mean, you already made the connection. Just make Felipe. That was his name, right?

Yeah. Make Felipe listen to this podcast, to this episode. And if he says at the end, hey, Uri, here's my money. Just make this work. Yeah, we can talk. We can talk anyway, even without money. I sort of like that guy. You can't say that. You can't say that you're ready to take his money and then say, no, you don't really need his money.

You have to be fierce. Give me all the money. I'm not sure negotiating contracts on podcasts is effective. Not with me, no. I do have a couple of short listener questions. Sure. Some of which we've already talked about, but Peter Griffin would like the Teensy 4.0 or 4.1

to be supported as a processor slash board. Is that on the roadmap? Yeah, so the roadmap, the way we work with the roadmap is that there is a public GitHub repo where users can suggest features and then users can vote for them. TIN C4, I don't think it has been suggested so far. 3.2 was suggested. It did get some votes, but not a substantial amount.

And 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 his sense has disappeared. Yeah, grad students. Yep. You can buy votes by being part of the club.

And then if you want to vote for something, you can totally stack the deck. You can totally stack the deck. You can totally. A question from Dana. She wanted to know more about the dancing servos, which I want to know anything about the dancing servos. Well, so dancing servos is why I love this, like why I love Walkway. It's one of the best examples of how creative engineers can get

when you give them the tools. The person who made this, I'm not sure why he created that. Maybe he did all sorts of other crazy things with Walkway. He had another project where he wanted to show how you can use um multiple i2c buses with arduino mega so he took 30 lcd displays and created a seven segment uh four four-digit display out of them. Okay. Each LCD screen would be one segment,

and when you turn it on, it would be lit, like the segment is on, and when you just draw the screen blank, it would be off. So create a seven-segment display out of discrete LCD screens. Again, I'm not sure why he did it, but it was hilarious. And 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 don't know,

I don't even have the word to describe it, extraordinary out of the box or useless but super cool things. But doing it with real hardware would be, I mean, where would you get 32 servers or 30 LCD displays just to test this idea? How would you power them? What would you do with them after you want you finished your project like 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's possible fill up your house and how could you

share this with others like just by taking a video and then scrapping the project now all of those problems are gone with walkway you can just build whatever project you imagine and then if it the purpose was just to show that it's possible or just to experiment with the limits then you put it there and walkway 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? I think I have found the right project. I think it's called Servo Overdone. No, that's, I think, I'm actually not sure.

Maybe it is. Let me check. It's linked from the homepage and it has like a circle. Yeah, this is the one. Yeah. for the fun of it, just for the joy of it, that would be expensive or 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. But I wouldn't want to do it. Exactly. I mean, that's the power of it. Like one person had the idea, but he could tell you about it and maybe you would get a message across.

But with Walk.me, he could show you his idea. and then maybe somebody else who has the time, money, or I don't know, like ambition could actually make the project. Like making the connection between the idea and the person who can actually create it, that would be amazing. And as a team thing. I mean, it lets multiple people add their piece to it without having to be in the same room.

You can get servos for just a couple bucks, right? So, I mean, you're talking about like $100 worth of servos maximum. And the power. Happy deal. Power's easy. Power's not. Power's always easy. Gonna blow up that poor little Arduino

so fast. You just get a giant wall wart. A whole bunch of fat. Yeah, just power them from the five volts of the Arduino. What could possibly go wrong? Well, you've been working on TapeOut since we talked to you last

and you didn't tell me. Is there anything you're working on now that you want to tell me? Do you have any new projects? In between all this stuff that we've discussed that obviously takes amazing amounts of time. What else have you been doing? Yeah, I think I spent a month this year reading a web serial. It's called warm but yeah if you value your time don't get into this it's a huge time sink but yeah um i think uh all work and no play makes jack a dull boy it's really true like

you have to know how to take breaks and even um uh working on two projects on the same time, like Tiny Tape Out and Walkway sort of allows me to take breaks so I can, for a few days, just focus on Tiny Tape Out and, I don't know, try to add a new USB-CDC peripheral. And I wouldn't say forget about Walkway, 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

rather than the essential. So I think, at least for me, that's what works and helps me stay for a long time in this business of doing complex software. Yes, sometimes working on something else is as good as a break. Not always, but sometimes. And it's 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'd like to leave us with?

So, yeah, two things. One of them, one thing that changed in what we saw, I prepared a 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 Walkway. You can write code in C

or in any other language that compiles to WebAssembly like Rust. And 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. So I would really love to see more cool things that people do with this, like not only creating new parts, but also creating new tools for the users of the simulator.

So that's one thing. And one maybe more generic thought, relax for the same result. Look for this blog post by Derek Sivers. It's something that I'm also trying to apply when working on Walkway, Tiny Tape Out, or any other project. Don't stress yourself too much relax for the same result I think you are

in the enviable position of truly enjoying what you're working on and I am excited about that because you're working on neat things thanks our guest has been Uri Shakad maker and serial warranty voider.

You can find his simulators at walkwe.com, that's whiskeyoskarkilowiskeyindia.com, and tinytapeout.com, which is spelled just as it sounds. There will be links in the show notes, of course. Thanks, Uri. Thanks, Rui. Yeah, you're welcome. By the way, you forgot to ask me, we didn't talk about the oddest feature that has been requested. That's true. What is the oddest feature that has been requested?

I hope it wasn't my, can we add get to this somehow? Oh, no, that's not odd. Certainly not the oddest. Yeah, I spent half an hour today going through the feature list to try to hunt for the oddest one. I think there have been like a few, like there is magic smoke that comes up every now and then. That would be cool. I want fire. Or fire, right?

And then there was someone who just opened an issue with the title, Good Morning, and no other information in it. But I think one of the most jaw-dropping features that I got is somebody complained that I put privacy behind the 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's wrong to put privacy like you can take money for other features but don't take my money if I want to not to share my project publicly by default. So that's the most jaw-dropping feature.

And I think the most what-the-hell feature I got is a user asking me or a user complaining that printing code from Walkway doesn't work. Like on a printer? Yes, on a printer, apparently. Okay. I'm sure there are ways people could solve that that don't involve you having to do anything at all.

Right. 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. I like how fast

you apply things that you have just learned. Amazing. Use custom chips for everything. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listeners Slack group for their questions. And thank you for listening. You can always contact us at show at embedded.fm or at the contact link on the Embedded FM website, where you can also find show notes and transcripts. And you know what? I'm afraid that

the quote also went on vacation with the lightning round questions, and I don't know what's happening there, but I wish them well.