Embedded - 328: Debugging Like a Monkey

Episode Date: April 23, 2020

Christopher (@stoneymonster) and Elecia (@logicalelegance) discuss listener questions about USB, thesis projects, prototype iterations, motivation, and processor cores.  Chris has been using audiomovers.com to mix audio remotely in real time.

Welcome to Embedded. I am Alicia White, and I'm here with Christopher White and our little dog, too. Hey, everybody. The dog's not going to say anything. Don't worry. It's not April Fool's. If he does, I'll edit it out. So it's just going to be us this week. We have a few listener questions, which we did no research on. So the answers will be, I don't know.

All right. Talk about movies. It's been kind of stressful here. I don't know about the rest of the world, but yeah, it's been stressful. And I'd love to do a show about how to motivate yourself when you're depressed and scared and generally exhausted. But... I'd listen to a show like that, maybe, if I got motivated about it. Yeah, I don't know what to say. I have an attention span. It is measurable. Like an R-toss. It's measurable in microseconds. So why is our little dog here?

Because our other dog passed away. It sucked. And the little dog does not understand. Yeah. Neither do we. You can't be away from anybody for greater than five feet. Yes. It's super fun. We're going to work on this.

Well, shall we try to answer some of these questions? Is there an alternative? Yeah, we can say, see you all. Hope you're doing well. Goodbye. Only a two-minute show is going to cut it. I can still read Winnie the Pooh. All right. Let me know when you're doing well. Goodbye. Only a two-minute show is going to cut it. I can still read Winnie the Pooh. All right.

Let me know when you're done. Yes, let's launch into listener questions. Well, first we have a listener point. In the John Saunders interview about Short Circuit, Nova Robotics was filmed at the Bonneville Dam Visitor

Center on the Washington side. All right. It's always nice to have facts. Important trivia. Peter asks about USB, specifically USB 2.0. Would like to know why people don't use it. Why would you rather use a UART? Why?

How? People don't use it. Why would you rather use a UART? Why? How? People don't use it? Well, it is more complex. It requires more firmware support. But he wants to know if it's really that hard. He wants to know what we think about it and what should engineers like him know about USB and USB implications.

I would, yeah. So I've used USB. I used it much too early, like the 98-ish. It wasn't that early. Really? Yeah, it was like 2004. It was on like the first laptop in 1998. But it was too early anyway.

Yeah, you were trying to do, what were you doing? You were making a data logger. Yeah, a serial port to USB thumb drive logger. And the thumb drives were completely non-standard. And the Atmel library I was using just wasn't ready. A lot of problem with the thumb drives, now that we're on a tangent that will take up some of the show time, was they implemented SCSI over USB.

And so there was all this incompatibility with how SCSI worked, and you'd get different commands would do different things, or the behaviors would be different. I remember having this problem at one company I was at. We wanted to use USB thumb drives, much the same way you were doing for logging and for firmware updates and stuff. And we were using Greenhill's RTOS on an x86 single-board computer, and everything should have worked fine. But, you know, we had a USB driver that did, quote, mass storage compliance, which is supposed to work with everything that's a disk drive. And it just didn't. There were some thumb drives that worked, some that never mounted, a few that worked perfectly. And so we ended up having to say, okay, field organization,

this is the one to buy. The one, yeah. And, you know, if you can't find it, well, then we'll qualify a new one. But it was a real pain. But that was a long time ago. And I don't know. I don't know that anything has changed, except perhaps drivers have gotten better. I mean, when I think about USB, I usually think there is some sort of RTOS component because it is more complicated, and it has timing requirements beyond what a UART

with a circular buffer and some interrupts do. And I think I was not the only person who was burned. I think there are a lot of people out there who adopted USB a little too early and then discovered, oh, look, thumb drives sometimes come with hubs in them for no reason at all. Right. Yeah, that was another major problem. It was like internal, why are you doing this? And so enumeration was super weird.

And then you have the whole problem with file systems right well that i actually had a so i was fat 32 at that time was yeah kind of the standard um but really what i wanted to ask was if anybody out there really knows usb usb2 specifically well and could maybe contact us and talk about being on the show and telling other people about USB and why we should stop using UARTs. I mean, I've used it a little bit in the past, in the recent-ish past, because it's good for higher speed stuff than UART. And it's, you know, if you're doing a consumer product that plugs into a computer for firmware updates and things like that, it's kind of a requirement, especially if you're going to do rescue kinds of things with a firmware image that's quite sizable. And it's really nice also for debug interface. pretty simple USB drivers on the host side for things like,

if you abuse the HID class, the human interface device class, you can put any kind of data you want in that. And so it's pretty straightforward to make a USB HID debug interface. So you can just plug the device into USB. You don't have to have a JTAG thing or a SEGGER or whatever, or expose an FTDI UART. Well, there are a lot of these JTAG units that have an internal UART as well. Yeah, yeah.

And that's super handy to have both your debug and your serial console on your IDE. Right. And there's a continuum of stuff you can do with USB, right? I mean, if you do HID, everything's real. Like, I've done a ton of HID stuff because you can just abuse that. Or you're just faking out being a camera. Sorry, faking out being a keyboard. Keyboard and mouse. I've done that with touchscreens.

I've done that with, I made a little remote control for a medical device, a prototype. It was supposed to be like a little handheld thing that could attach to a hospital bed while the doctor was doing a procedure so they could push some buttons and not have to have a keyboard for this basically PC thing. And I've made a little, just, you know, back then it was some little Atmel 8-bit chip that did usb hid and turned it into a keyboard with like five buttons um so that's that's on the low end side and then i remember doing stuff at fitbit with like the cdc class which is more complicated that's kind of a roll your own throw any data you want in but it's it can have multiple devices over it and that's the one where you kind of can multiplex serial and a bunch of other things. That's when you start getting into stuff that I don't really understand.

So people definitely use USB 2.0 on embedded devices. I'd say it's easier to deal with than Bluetooth. You have more experience with Bluetooth. You don't have radio involved, but it is a pretty thick stack. Bluetooth was always intended to be unembedded, and USB was a computer thing. Yeah. So I don't know that it's simpler than Bluetooth. We'll fight for it.

Okay, so anybody out there USB master or somebody who's researched it recently and is thinking about it? Journey person. Journey person. It doesn't have to be a master. No. This is not a master level show. into this next question from Daniel, who is currently working on an EE tech degree and masters in energy and electromechanical systems. Okay.

And Daniel says, I have some basic experience in embedded systems, but I'm still new to development. I chose an embedded system topic for my senior design project that most likely will feed into my thesis. He's researching how to improve IoT hardware security using RISC-V physical memory protection, PMP, and user modes. Okay.

He goes on to talk about Rust and the OS called Talk and Userand, and Hi5 from Sci5, and ESP32, and MQTT. And his focus is on demonstrating a simple security model that isn't an end-all solution, but a solid example of how security strategies shouldn't be ignored due to fears of overcomplicated implementations. Do we have any advice on certain attributes that Daniel should focus on, like secure boot, signing, encryption protocols, etc.? Should Daniel use an RTOS or think even simpler? Well, okay. So there's a lot there. There really is a lot there.

The first comment I make, which I don't want to be a criticism, because he's already on this path and that's fine. It does feel a bit like he's trying to build seven space shuttles. Usually you should pick one hard thing to do. I remember when I first interviewed at Xerox PARC, they said that they liked to do projects that had a minimum of two impossible features and a maximum of three. Yeah. So it makes me a little nervous to hear risk five plus rust, plus a new RTOS,

uh, plus sci-fi. Uh, it's just a lot of new, I mean, on the one hand, it could be good because those are unexplored and it's easier to make an impact.

Um, on the other hand, it seems really hard to deal with a bunch of stuff that's brand new. That aside, gosh, what's a good suggestion? I mean, the Secure Boot is super important. Firmware update and signing, that's super important. Embedded encryption protocols, it would be nice to have. I mean, I know they exist.

I use them, and yet still I would like more information. And I would say if this is a thesis, just from my experience, it's best to pare things back as far as possible. So, you know, my advice being worth nothing, the question, should I use an RTOS? I would think no. I would stick to a very basic demonstration of, say, a secure firmware update. Yeah, yeah, I would. Or, oh, sorry, no. In the same vein, I would just say choose one or two things and not try to do everything. You can always add more to it once it's working.

Yeah. The other thing I was going to mention was you could do some sort of communication protocol that's secure. Like if you have an IoT device that's sending a record to a database. That's the sort of thing with signing you could also do. But I would definitely pick one of those big areas to kind of do a demo with. And then, like you said, if you find that super easy or not compelling, you have more time to add more stuff in. But I found with thesis work that things went a lot slower than you expected.

And the more you have to kind of figure out that's a mystery, the harder it is. Daniel said the goal was to improve IoT hardware security using RISC-V physical memory protection and user modes. I think you should look at those words and try to focus on those. And I think you should look at what already exists on the Cortex cores as a contrast comparison basis for starting out. You're going to need a section in your thesis about other possibilities, other methodologies. Because the MPU on the

Cortex-M4s is fairly powerful as well and it's probably similar. I think RISC-V may be more sophisticated. I haven't really looked at that in great detail. But that would be a useful thing to just look at and say, oh, this is this model that I came up with using RISC-V. Here's how it differs from what's available on the ARM cores. And I know we occasionally do.

We're not huge Rust fans for no reason other than it's one more thing to learn, and there are so many things in this world to learn. There are other reasons. Please don't email us. That may be a good direction for you, but it may not be. Yeah, that's one of the things I feel like, okay, you're adding too many things in. That's one thing. It's like, okay, do you already know Rust? If you already know Rust, then yeah, that's a good direction. Sure. But if you're learning Rust 2, if you're also learning RISC-V, if you're also learning... TACOS or whatever, RTOS.

Yeah, it's a lot to learn. And now is the time to learn, but your thesis is to show that you have already learned. So you need to balance new stuff with with what you can accomplish in the time you have yeah especially since you mentioned um doing a port right of taco west oh i didn't notice the word oh yeah it is a port from esp32 to risk i wouldn't even i wouldn't touch that no Get stuff running with what exists. Because focus on what you want the thesis to prove, right?

And thesis is, I want to prove that this is a good security model that I've developed. Does porting a bunch of code for an RTOS from one architecture to another help you with that? I don't believe it does. It just wastes time. Yeah. Make a mission statement one architecture to another. Help you with that? I don't believe it does. It just wastes time.

Yeah. Make a mission statement. Stick to it. Not really what I usually do, but, you know, do what I say, not what I do. Yes, I should caveat this that I stopped doing my thesis and went to a oral exam exit for my master's degree. So, you know, for what it's worth. Okay, Marcus has a question for our show. About prototyping iterations, how many iterations are normal,

depending on the complexity of the project? How can one improve to think about errors in advance in order to reduce iterations? Marcus made a relatively simple project and had an issue and sounds like maybe he doesn't realize we all do. It sounds like a mechanical issue that he had. Yeah. Well, hmm. Okay, so we've talked to Alan Cohen about his prototyped production book. Yeah. Well, hmm. Okay, so we've talked to Alan Cohen about his prototyped production book. Yeah.

One of the things he does towards the early chapters is to try to get you to think through what's happening. And we've talked to James Grunning, who says you shouldn't be a debugger. You shouldn't worry about debugging your system if you unit test it properly. So when you're thinking about boards, what would a unit test be? Part of it is mechanical. So maybe if you have a 3D printer, you print out the board and make sure it goes where you want it to or maybe you build it out of paper i've definitely built it out of paper or even just do 3d render that allows you to manipulate a little bit sometimes you can catch stuff that way but it's like you say it's

i think a physical artifact is a lot better i just i mean yeah the screws are never quite in the right place for me. It's like they always catch on something. Even when I think I have them far enough away from my connectors. This is why I think sometimes doing what you know really well is better. As for how many iterations are normal, I mean, I can say for professional big consumer products, two or three is what it seemed to be the mode, and that was with a large EE and mechanical team behind it. You'd start with the easiest thing to do, which is a non-mechanical prototype, right? The board is huge,

doesn't match the form factor. This is only if you have the money to do it, right? And this is the kind of thing in a big company that you do. You make a non-form factor. It's quite large. You know, it might take up the size of a book on a desk when the final product might be the size of a postage stamp. But that allows you to have a lot more test points and visibility into the system. And then moving on from that, you have smaller form factor prototypes. But usually there's not too many of those, although mechanicals do go through a lot of iterations, if I remember correctly, from a lot of products that I've worked on. Well, you were talking about the big board. I've had companies that call it the elephant board.

But that's because that's what we see in software. On the other side, there are looks-likes. There are the looks-likes prototypes that don't do anything. They just have all of the pieces put together. And is that an iteration? It is kind of, but it's a milestone iteration. So it's not a mistake iteration. I wonder if Marcus might benefit from thinking about that. There are intentional iterations that prove the idea, prove out what you're doing, and then there are mistake fixes. And those are different.

Yes. Can you reduce all of the iterations? I don't think so. But if you can make the mistake iterations go away in favor of the intentional iterations, you'll be in a better off spot. Because you'll be thinking about how to test what you need to test how to make sure that your sockets aren't too close together how to make sure that every piece of firmware can be tested before it needs to go into something the size of a postage stamp

yeah i remember before 3d printers we used to make stuff out of wood just to see what does this feel like what is the shape where do Where do the connectors go? Is there enough space? But for the specific kind of problem he's talking about, there's no substitute for having something mocked up in modeling clay. Who cares? Just dimensionally accurate so you can see, oh, this needs to move. A piece of paper. Yes of paper yes a piece of cardboard actually we did it at a cardstock yeah yeah yeah and and then put all the connectors on um and that was pretty helpful because you can print out the board onto the cardstock at the correct scaling i don't know yeah it depends on if you're doing it on your own or in a big company and what your budget is. And I'm sorry, there's no real answer. But I think, like you said, iterations that are because of errors, you really want to reduce that.

If you have a lot of iterations due to mistakes, that suggests you've missed a step, a cheap and easy step. Of thinking about it? Yeah. Of designing it and designing for manufacturing? This doesn't go for software. Software is a different kind of mess. Designing for testing? Yeah, yeah, yeah, yeah.

This doesn't go for software. Oh, the software is continuously, you know, we've evolved into this weird programming methodology that doesn't have a lot of stopping points. Anyway. Oh, my God. I'm working on this client code, and I didn't start out understanding the code.

It was in a language I didn't understand, and it was in a section of the code that I wasn't familiar with, but I really needed a feature out of it, and the person who was doing the feature got called off into another project. So I'm working my way through it, and I'm totally, totally debugging like a monkey. I don't understand it. I'm trying to print out on every line to figure out what's happening here, what's happening there. I have the old version and the new version, one that works, one that doesn't. And I'm trying to compare them step by step and try to figure out what's different. And it's just, man, I really like it better when I understand what I'm doing. And now I'm finally reaching the point where I really do understand what I'm doing.

What I want to do is just scrap it all and start over. Maybe tomorrow I'll be a little more optimistic about it, but it's been really tough to do the iterations purely by error, to just fumble around. Well, that's because of the cheapness, the perceived cheapness and easiness of doing that in software that's what we fall into is kind of a local minimum right and it is a local minimum it's not the most optimal way to work it just feels like it a lot of times because it's low cognitive effort with the potential for a

high payoff if you manage to if you get lucky monkey type the right thing, right? Yeah, making a unit test was the smartest thing I did. And we do that in a lot of areas. But I think that's not as easy in mechanical because you know, you can't just move things around six seconds in most things

like that and say, oh, that didn't work. I mean, you can before you get it made. Right, right. But after, it's a lot harder. Well, I don't think we answered that question either. Let's go on. Scott has a request for talking about different ARM microcontrollers.

They seem similar if you ignore the vendor IDEs, which vendors seem incentivized to promote as different. The compilers are all ARM or GCC. Some peripherals are shared between families and the core mechanics tend to be the same. But what is the fundamental design differences in the system on chips? Bus structures, clocking connections

pin mux scenes i have no idea oh i mean as far as i understand it they the the cpu core is all that's really common the rest of it they can do whatever they want i mean they kind of licensed the ISA, right? And the instruction set and all the associated core IP that drives that. But things like peripherals, pretty sure that's all a grab bag of their own IP. Yes, it's true. Clocking is entirely different. And so on one system you might get, or on one chip family, you might be able to have a single clock that drives everything. On another, it may split into three clocks where one is half the speed the others, and you can't run the SPI as fast. Even though you have two chips that are both running 48 megahertz on a Cortex-M4, one can only run SPI at 1 kilohertz, and the other can run SPI at 100 kilohertz. And that's where a lot of the power numbers come from. They do all that stuff differently, and they have different ways of different power domains.

Maybe one chip has a whole bunch of different power domains, one only has a few. its own or can turn off spy and i squared c and that goes to the clocking there might be multiple clocking domains or just a few uh so all that stuff is up to the vendor and i'm sure there's reference stuff from arm but i i think they probably you know that's not optimal and they probably throw most of that out. The thing you get with having the same core, like the Cortex or the Cortex M0 or M4F, is actually the compiler. You are compiling for the same processor. Everything around it could be different. The memory structure could be different. So you do, those vendors do a lot. And Chris is right. If you look at the power numbers,

that's really a differentiator. It used to be that one company's I squared C was implemented as a state machine in hardware and another was in a state machine in the driver. And so for best results, you were better off using the hardware version. But now, I mean, not only do you have this core that's the same, the CMSIS is a hardware abstraction layer that is between multiple vendors. And they create hardware abstraction layers within their own within a single vendor. And so you have all these layers and they start to look the same. And sometimes they even act the same. But underneath, everything else can be different. Even the way you access memory can be different. Whether there's a cache, whether there's

not. Whether program memory and data memory are separate. It is only the core that's the same. Yeah, I've worked on some really strange ARM chips with all kinds of memories all over the place that work to different speeds and could talk to certain peripherals quickly, but not other peripherals. And DMA was a giant mess because you could DMA from one place to another, but not from vice versa. So it gets really complicated. And that's why they have multiple vendors. They can differentiate and do different things.

Yeah. They can make their processor power efficient for this application or super fast for that application. They can throw a graphics coprocessor on it or a DSP and stuff. Yeah. Scott goes on to ask about lifecycle for the work we do. How much code is shared

between existing projects and new? Seems like vendors and HALs are targeted towards new projects with their wizards and code generation. CubeMX and whatnot. Okay, so for us, between clients, there is no shared code. Right.

The only exception to that is code that I write for myself, unbuild, and then can reuse for clients. Like command processors, things like that. My command processor, which is on GitHub, and anybody can reuse for clients. Like command processors, things like that. Which is my command processor, which is on GitHub, and anybody can use it. But it's, yes, no. If I write code for one client and I realize that it would be useful

to have that same code for another client, as much as I would like to copy it, the first client owns the copyright of that code. Yeah. So I rewrite it. As painful as it is. But what about the vendors and HALs? Yeah, I mean, one of the best things about reusing a processor I know

is that I'm pretty familiar with the HAL already. Yeah, in most companies, there's a bit of momentum and inertia behind whatever chip you chose for product A. And product B is a follow-on to that. It's tricky to argue that you need to move to a completely different chip and architecture because there's a lot of software work that has to happen. But a lot of, you know, I've seen all those things happen, all those kinds of scenarios, and still

reuse a lot of code. More the further away you get from the hardware. Yeah, the application layers are more reusable than the hardware layers. And if you do a good job with your HAL, if you're doing your own HAL, which I've been a party to, then you can switch that stuff out.

You have control over it. But yeah, no, I agree that the IDEs and stuff are very code wizardy and stuff, but that's not how... None of the professional projects I've worked on start with those. Maybe because they're too big. Some of my little ones have started with those. But they're not the kind of thing where you're going to have six products following on.

No, they're not usually. Or if they are, they're small changes. I mean, the reason that sort of thing is targeted towards new projects is because the complaint for a long time has been, I can't get started. We can't get started with your chip. We don't know where to start. We can't port it. We can't port what we have to your chip.

And so the vendors have reacted to that by creating code generation and wizards and whatnot. And it is helpful. It is actually really helpful because you get code that works. Now, is that code optimized for your particular processor? Is it fast? Is it clean? Is it error-free? Those are all things you're going to have to figure out as you go along.

Straight off, it's probably less good than you could do on your own, given infinite time and resources. And more good than I can do if I don't read the manual. Yeah. But yeah, yeah, a lot of code is shared between projects, especially if you're doing it kind of right. If you've designed your system well, there's layers where you can break things off and carry over. But you shouldn't be rewriting,

you know, if you've got some networking stack that does your IoT stuff and it's generic for your particular product, then no, you shouldn't be rewriting that even if you go to a completely different architecture. Well, and Scott, this is actually Scott over at Adafruit who works on Circuit completely different architecture. Well, and Scott, this is actually Scott over at Adafruit who works on

CircuitPython. And he's been on the show. And so he went on to ask about cross-chip family build systems, which is a really hard problem. And I've done it in a few companies and usually it's

supporting the old products. Like, we're not doing active development on multiple chip families at a time. We are starting a new chip, and we want to keep the old chip's information. Cisco, we had this a lot, because various... Yeah, I know. iOS, the router operating system, was the same across the entire company, but there were just a ton of different chips, MIPS, and PowerPC and all kinds of stuff that it targeted.

So it was kind of like any other thing like Linux. You know, Linux compiles for various architectures, so you have that same problem. How do you manage that? That's a really, really good question. How do you manage that? Well, since we weren't online on Slack when Scott asked this, because it was in the Patreon Slack, somebody else replied that Embedded Artistry has a whole online course

on how to deal with build systems of this scale, using Automake, CMake, and Mezon? Mezon? Mezon. Mezon. Automake, yeah, I remember

doing a lot of Automake. CMake I haven't used that much. I've used CMake a few times. Gives me a weird pain behind my eye. Write it? Yes. I don't mind using it, but writing for it is not fun. I'm sure it's fine.

I'm incompatible with it. But it's good. Yes. Philip, Embedded Artistry, has done a bunch of work documenting that kind of stuff. That's great. And it is about cross-platform build systems for embedded projects. So I will put the links to that in the show notes. And since Philip is probably listening, we should say, hi, Philip.

Thank you for doing all this wonderful work so that we can just point people at your work at something. Yes, exactly. In times like these, we'd really rather point at other people's work. What else is happening? Well, the last thing I have is actually from the beginning where I said I would like to figure out how to motivate myself. And Tom suggested a method that wouldn't work for me, but might work for other people. Here is something I've been doing for self-motivation. I write a very polite, formal, and clear email to myself asking me to do something.

So no, hey, dumbass. I attach any needed data. This is the kind of email request that I me to do something. So no, hey dumbass. I attach any needed data. This is the kind of email request that I like to get. Reading it a few minutes later is bizarrely pleasurable. After I finish the task, I send a follow-up email with the results, noting that the job is done. This adds to my feeling of accomplishment at the end of the day. It makes it easier to look back and realize I finished something. What if we could just hire somebody to play the opposite side? It feels a little weird to be talking to myself.

But it's an interesting suggestion. I mean, and it hits all the things they say to do, which is to make sure that it's trackable. So you can say, yesterday I did do something, even though I felt at the end of the day like I hadn't. It's kind of like status reports. I used to like my manager's status reports weekly because yeah it was never for them it was always for myself to say oh i did do a bunch this week yeah and then when uh performance reports came around it's like oh look i have a whole stack of emails i can just cut and paste from this say say what I did. Yeah. So, yeah, I mean, for me, it's making sure I don't dig any big holes. You know, get lost in Twitter. I really should just, if it's get lost in Twitter or play Animal Crossing, I should play Animal Crossing. If it's play Animal Crossing

or bake food for us, it should be bake food for us. You know, there's this scale of things. And then sometimes I get to, okay, I'm done making cookies. I will get lost into Twitter. And it's like, no, no, you fall back to play Animal Crossing. This is a weird description of your current existence. Somewhere in there is work. Yeah. Yeah. I am getting some work done. I manage work for a while each day. And then I know I'm not going to charge clients my usual rate if I'm not up to doing my usual work. And so I haven't been billing full days. But I am doing better this week than I was last. So maybe next week will be better yet.

Well, somebody ought to. You billed hours. I billed the minimum number to be called hours. That is correct. That's not true. Well, if you hadn't done the whole 20-hour projects in two hours, you would have had plenty of work to do. Well, somebody was talking it up for like two weeks before I got started,

saying, you better get started on this. This is going to take forever. It's really hard. And then it turned out you had actually done all of the legwork beforehand for a previous project, and all I had to do was type go. Well, it's for the same client, so, you know. But I thought it, yeah, okay, sorry. I thought it was going to be harder. No, I'm not complaining.

I mean, you know. What else is going on? Have you seen any good TV shows lately? Picard was good. I know it's funny. I've been reading more about it after having seen it and a lot of the Star Trek people

really hate it. Like, if you go to any of the stuff on YouTube, the comments are just universal hate, torrent of hate. But whatever. I kind of enjoyed it.

I thought it was a different take on things. I liked it. If there were more, I'd watch them yeah I it isn't of all the shows that are currently running Zoe's

Extraordinary Playlist is one that I'm like oh that's on tonight okay cool but that's definitely kind of a weird thing although although if you work in san francisco you really should watch at least one episode because they have the whole what it's like to work at a tech startup in san francisco it's even worse it's even worse because i'm pretty sure the building they chose is supposed to be located right where fitbit was because they go have lunch in the

embarcadero oh yeah no we totally saw places we'd been. They're walking around in places I used to walk around. The company was making a smartwatch in the first week. It was all very deja vu and strange. And funky architecture inside. Yeah. But they did capture the whole San Francisco. It's amplified by quite a bit.

But they did capture the whole San Francisco startup thing pretty well. The later episodes, they don't go outside as much. So you're not seeing as much of the city, but I thought that was pretty funny, but it's a family drama. So it's not really a tech show so much, but they do throw out the right words.

Occasionally like in the last episode, they said that we're having a problem with get and stuff. So somebody is consulting who at least has a familiarity with stuff. Yeah. But yeah, part of our coping mechanism has been to turn off the lights and watch television every night with no devices near us, starting at around 7.30 or 8. It's worked out okay so far.

Yeah, I think they're not having devices near us and focusing on family time. Let's see. Movies lately haven't been that great. Frozen 2 is still on the list. We could watch that tonight. We watched Onward. I remember nothing about it.

I think we watched it a day ago. Other than that, my project, Sitting Idle. Oh, I've been doing some music. So I picked up a little bit more music. The cool thing, my brother and I have been working on a record for a long time and it takes a long time because we both theoretically have jobs uh his job is a lot more real than mine right now but um it's challenging because we work separately and we do the parts separately and then they come together and one of us produces an initial mix and

things uh and logic and with whatever gear we have in our respective studios uh and then we send files back and forth like a draft mixed down he sends me over dropbox and i listen to it and make comments and notes and then send it back and we we, you know, iterate like this and it takes quite a long time. Uh, he discovered this thing, uh, that allows him to stream his studio at the output of his studio mixing board at full quality. So not MP3 or internet compressed, whatever.

So it's 96 kilohertz, uh, 24 bit full quality. And I can listen to the output of that while we have a zoom session up and we can mix together. And it's super cool uh and it's allowed us to like we just did finished off one song it took we spent about two hours on it together it would have taken weeks of back and forth and like well that didn't work and try this and okay move this track up one dB. And it's from Audio Movers, and it's called Listen To. And the way it works is it actually works as a,

if you do any music stuff, most of the software you use is the DAW, the Digital Audio Workstation, Logic, Reaper, Ableton, those kind of things. And you just include it as a plug-in on your track, and it takes the output of that track, whether it's the master bus or a particular track, and snarfs it over the internet, and then there's an app that goes with it. It can go to a browser or whatever.

It's not free, but there is a free week of it. And it's a pretty niche thing, but, uh, we found it really, really useful. And you could, he's been using it for his guitar lessons too, uh, cause you can stream his guitar to students and they don't have to hear crappy zoom quality. Um, so quite useful if you need to stream, uh, high quality audio, not just cause usually when you're streaming audio, if you want to do stuff kind of on your own, you have to have, uh,

there used to be something called, uh, ice casts. And there's similar things like that still where you have to have a Linux server somewhere and then it'll stream it to people. Uh, but it was never super high quality. A lot of podcasts use that kind of thing for broadcasting live.

Um, but this was, this high quality. A lot of podcasts use that kind of thing for broadcasting live. But this was, this was really cool. So. What about other projects? I sit on the couch and plunk on guitar. Well, and we share our animal crossing person. So,

you know, that's not, yes. Very androgynous person um yeah no i have a pile of synthesizers here for a while i was doing a little little new outro piece for the podcast every time maybe i'll do that again for this week maybe not you'll find out soon um but uh yeah you know, it's mental. Yeah. I mean, we're so lucky we're still working.

We live in a place where we can go outside and get a little bit of exercise and see the sun and not see other people. Well, I mean, we cross the street and everything. I find seeing other people to be triggering now. Yeah. Christopher was right all long um but it's still i'm still super stressed and i'm not doing projects i'm not writing i'm not going to writers groups i'm not not editing. Are they continuing that group? They are, but it's on Zoom. And I hate Zoom.

Zoom is a category of application, not particular. Yeah. Plenty of reasons to hate Zoom in particular. But no, Skype and Hangouts and all of that. It doesn't have the right timing. I mean, sometimes when we record with guests, we have this problem where it's just the wrong amount of time that they take to respond, and it's just delays in Skype and whatever.

And with Zoom or any of the Hangouts where there's video, I feel like it's actually worse. The delays are just too long and either I don't talk at all or I end up lecturing and it's not a conversation. Even when I'm just hanging out with people not to work. I mean, to work, I can manage it. It just takes a lot of focus and energy. Hanging out with friends, I get that people do it and I'm glad for them if they enjoy it. But for me, I don't voluntarily do Zoom and my writing group is on Zoom right now. Giving feedback is hard enough without trying to have that bit of latency that confuses me. People are hard enough without latency.

Yeah. I go back and forth between blah, I don't want to do anything, to oh, there's 24 things I could be doing. They all seem kind of marginally exciting. Well, I could do this, I could do this, and I could do that, but then I want to do this, and then if I do that, then I don't get to do this. I think it's some form of stress-induced ADHD or something, but yeah, there's days where quite naturally

and probably familiarly to most people don't want to do anything, and then there's days where I'm like, oh, I have 30 things to do therefore i'll do nothing yeah um so and i'm in trouble getting over that i'm doing a lot of gardening it's kind of like music for the you that it's i'm puttering yeah well i'm watching the strawberries grow and try to hope trying to infuse them with my hope that they'll be actual strawberries and not just little balls of seed. There's definitely a continuum of focus that music and things like that can exist on.

I can pick up a guitar and just kind of strum some chords, or I could pull up a lesson I'm supposed to work on, or a song I'm supposed to work on. But mostly it's nothing very serious. Well, shall I read the Winnie the Pooh? I suppose so. Do we have exciting shows coming up soon? Um, let's see. Well, it's hard to announce because if I haven't already sent them a mic,

it's impossible to do so. It is very hard to do so. Um, everyone in the world has decided they need a mic. I may actually change the mic we send out so that I am less nervous about things. But we have Kate at Zephyr happening really soon. And so that will be next week. And so we'll hear about the Zephyr RTOS. And in a weird scheduling coincidence, we have Joel from RTEMS the week after. Assuming nothing goes wrong.

Don't say that. Editing that out. No, I mean, assuming scheduling still works. Knock on that desk. Let's see. Yeah, I'm not going to go too far beyond that because I don't know who that's nice yet. But we're going to have some RTOS ones coming up. And someday you have to interview me.

That is true. We should have done that today. Oh, wow. We got fruit and vegetables today it was exciting it was stressful I had to see people had a great distance but still when we last left

Pooh and Piglet there were tracks on the ground and it was uncertain if there was a woozle weenie the Pooh had come to a sudden stop and it was uncertain if there was a woozle. Winnie the Pooh had come to a sudden stop and was bending over the tracks in a puzzled sort of way. What's the matter? asked Piglet. It's a very funny thing, said Bear,

but there seems to be two animals now. This whatever-it-was has been joined by another whatever-it-is, and the two of them are now proceeding in company. Would you mind coming with me, Piglet, in case they turn out to be hostile animals? Piglet scratched his ear in a nice sort of way, and said he had nothing to do until Friday, and would be delighted to come, in case it really was a woozle. You mean, in case it really is two woozles. So do we need the poo. And Piglet said that anyhow, he had nothing to do until Friday.

So off they went together. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. Thank you.