Embedded - 449: Soldering the Ukulele

Episode Date: May 11, 2023

Chris and Elecia talk about internetting your thing, motivating yourself with cheese, a pile of scrabble letters, an electric ouija board, and a supervillain origin story. Elecia will be on a Memfault Panel on June 1, 2023: From Concept to Launch: What It Takes to Build and Ship a New Device  Elecia was on Alpenglow’s Industries Solder Sesh #60 with Carrie Sundra. See the highlights (or the whole thing) on YouTube. Chris has been working on building a baritone ukulele from a StewMac kit. The conversation about uninteresting projects reminded Elecia of one of her favorite blog posts: Resilience Is a Skill  Classpert will be offering a self-paced version of Elecia’s Making Embedded Systems course. Sign up on Classpert to be notified about the details. The O’Reilly Learning System will have the first looks of the second edition of Making Embedded Systems. The full book should be out in the fall. Transcript

Hello, and welcome to Embedded. I am Eliseo White, here with Christopher White. This week, we're going to talk about all the things we talk about. Are you ready, Christopher? I am ready to talk about all the things. Are you actually you, or are you a chat robot? I'm not an electric Ouija board, no. Where do you want to get started?

Well, maybe we should start with the things you've been up to. Announcements? Announcements and some things you've done and things that are coming up that you're going to do. Just go through all the things that you're going to do from now into perpetuity. I only have one upcoming engagement, and that is with the Memfault Interrupt folks.

We are doing a panel about, from concept to launch, what it takes to build and ship a new device. Basically, it's all the software and firmware you have to write that isn't the software and firmware you have to ship. All the software and firmware you have to write that isn't the software and firmware you want to write. Exactly. That will be June 1st. It will be live. There's a sign-up.

And then I think they start sending you their newsletter which is easy to get off but it's also kind of cool so maybe I will be on that panel I think with Tyler Hoffman and definitely with Philip Johnston cool are you looking forward to that? I think so, I've been chucking things

into a file to talk about, my perspective was immediately very different from theirs. They were more focused on the... I mean, Memfault does the monitoring software. And my response was, oh, you mean the manufacturing and production software? And so it was just such a different conversation.

We passed like ships in the night until we realized that, oh, yeah, it's all one conversation. I also recently did a solder sesh with Carrie Sundra of Alpenglow, where she asked me questions like, how did you get into STEM? And I answered things like, I don't know. Hmm, scintillating. Exactly. But it does include my supervillain origin story. I thought it was superhero origin story. Well, when it's Exorcist Barbie, I'm pretty sure that's a villain story.

So that was kind of, yeah. And we did a little bit of origami, and we just chatted, and I showed off some of my toys. I mean, actual leapfrog toys. So it was fun. There's YouTube evidence of such a thing. And there was one thing that I announced on there. That was long, right?

It was a couple hours, right? It was at least 90 minutes. A longish video podcast, if you've ever wanted to see. They do all of the audio as a podcast, even though it's a video podcast. And then on YouTube, there are highlights, which are like 10 minutes long. And I don't know if they kept the highlight where I told the secret that I'm about to tell here. You're giving up on computers forever. No, that's your secret. Not a secret.

So I have started a second edition of my book, Making Embedded Systems. Yay! I have an O'Reilly editor. I'm up to chapter 5 of 10. It should be on the O'Reilly Learning System this month. In early access. In early access. You're not finishing the second edition this month. No, no, no, no. And you will get to see the messy, terrible drawings before the artist gets a chance at them. So that might be a reason to look in the early access. And I'm pretty excited about it. It's going along. Sometimes it's, oh my goodness, how did I write it this way and not realize that was terrible. So tell me a little bit about what doing a second edition means, because I'm not sure. I probably, you know, when I buy a second edition of a book,

I don't know what I'm looking for necessarily. And I'm not quite sure what's changed sometimes. It's not just you going through and fixing typos and changing all the references from PIX to STM32? No, although I did change from NXP LPC processors to ST processors. But no, no. I mean, yes, you do go through and fix all the errata and all the typos and all the things you wish you'd fixed. But teaching Classpert, I came up with things that I wish I'd put in the book.

Okay. Some of it was just a different way of looking at some piece or a diagram that I liked, that I developed for class that I hadn't done for the book. But some of it was things that I didn't know then. There's the chapter about, well, there's the introduction chapter. It's like, hello, welcome to embedded systems. They're not as easy as you think. By the way, you need cross compilers. Cross compilers are hard. And stuff like that. And then I also, the main question I get from so many people is how do I take my Arduino project and ship it? And so I added that to the introduction. It's only like a page and a half of here's what you do beyond the simple Arduino and here's why that might not work for you.

And by the way, go read Alan Cohen's book. So are you adding a lot of stuff? Some chapters get a lot more than others. Is there anything that you're adding that is, so there's stuff you wished you'd put in, but is there anything you're adding that's like, oh, this was 12 years ago and now this is new and different and this is updated? Oh, yeah, of course.

So chapter five, which is all about state machines and how the system flows, talked about, I mean, he talked about interrupts, talked about state machines, talked a little bit about RTOSs, but he never really said how to set up a main loop. And that was one thing we did in Classpert where it's like, okay, well, here's the polling version, here's the interrupt version, here's the event-driven version, and here's like Miro, Samix, ActiveObjects, because that's just something that when you get a vendor code base, that's so common. And the first time you see it, it's just mind bending because it's got inversion of control, which is all software-y, but it's really important. But it's also kind of hard to break down. And if you go look at Active Objects, one makes sense.

Like, okay, I understand the message pump, but how does this make a system? And so I had a lot of difficulty doing the diagrams for that chapter because everybody wanted me to do the classical message pump task thing. But what I really wanted to show is, okay, you have three of these. How do they work together? And you have- Because you're going to have, you might have three independent parts of the system. Tasks, yeah.

Tasks or sensors or things being fed. So that's new. And then chapter six is where I am now. So we shouldn't talk about that because it's kind of in a state of, I've taken it all apart. All the pieces are all around me. I did not take a video as I took it apart.

So now I don't know how it goes back together. You just have a Scrabble board on the floor with all the letters. Basically, yes, I have a pile of Scrabble letters and I'm not sure how to put them back together. But the next chapter, chapter seven,

which used to be just updating code, which, I mean, is kind of important. And at the time, I remember that was new. But now it's changed a lot. But now it's changed so much. So some of the things that I'm doing for the panel for Memfault, one of the reasons I'm starting early to put things in a folder is like, okay, these are the things I also want to talk about for a chapter about cloud computing and IoT and devices and distributed systems. I don't know what I'm going to call it. I don't want to call it IoT. Things of the internet.

Distributed systems doesn't really make anybody very excited to read that chapter. No. Yeah. So I don't have a name. Most of the titles are a verb something. So like updating the code is the name of that chapter, but. Internetting your thing.

No. Clouding your thing. Nope. Clouding. So yeah, clouding something thing? Nope. Clouding. Yeah, clouding something would be good. Contributing to the cloud. I don't know.

Is there anything you're removing from the book? Well, not a lot. After this conversation, your acknowledgement to me. No, no. Although, rereading that, it was pretty cute. So, I'm in the peripherals chapter, and there's a really big section about RS-232 and null modems and DB9s. Even the reference to cross compilers that you just mentioned is like, nobody calls them that anymore. When was the last time you said cross-compiler for anything? Well, part of the book is that it's for software engineers

who get into hardware, and they don't really know what that means. Yeah, I know. It's absolutely the right term, but it's something I haven't heard anybody say in a long time because now it's just, since everybody does it, it's a compiler. Sure, I guess so.

No, it's not an important point. So yeah, I have lots of things to add. I have, I think the map from my maps talk, the pretty map, is not going to make it in the book. It doesn't look good without color. No, you need a three-page fold-out color insert. The centerfold will be the memory map. O'Reilly does those, right? So, yeah, I mean, lots of little things.

Updating the computer science terms for the hardware engineers who read the book and want to know more about software and why we talk about modularity so much. So, are you enjoying the process? How long have you been doing it? It's a couple months, a month, couple months. We signed the contract in March. Couple months. I think maybe late March. I don't remember.

Okay. But yeah, I've been doing it for a couple months and I've been light on client work. So I've really been doing it. I say that and I totally worked on client work. Briefly. I've really been doing it. I say that, and I totally worked on client work this morning. But, yeah, and so I got way ahead of my editor, and that's caused problems. But it's fine.

It's kind of fun. It's fun reading the book because I truly don't remember writing it. It's hilarious when I look at it and say, that's really good advice. Why didn't I do that? And you've caught me laughing at my own jokes, which is slightly embarrassing, but I don't remember them. And that whole section about the triceratops, that really was awesome. I don't know what I was channeling that week, but wow,

or that month. So yeah, that's, that's that for announcements to continue. Class part is going to do the solo paste, self-paste, self-paste version of the class. Paste yourself.

Just paste yourself, cut and paste yourself everywhere. Yeah, so I have to finish a couple things for that, but that's going along. So should you want to listen to me or want to read what I've written? You have multiple

avenues. Listen to me blather on a panel. You can have all the me you want to have. Since people are already listening to us, I think we've selected the audience appropriately. Let's see. I got the Flexar board from Carl, but I haven't

tried it yet. What are you going to do with it? Well, since the video was origami, I figured I would start there. Yeah, but I mean specifically, what's your plan? Carrie wanted to, when we video was origami, I figured I would start there. Yeah, but I mean, specifically, what's your plan? Carrie wanted to, when we did the solder session, she wanted to do butterflies. So I'm a little tempted to make a flapping butterfly just as the first thing. I want a whole mobile, mobile, mobile.

I know, that word. Anyway, I want a whole mobile of flapping butterflies. So it slowly rotates, but they're also flapping. So do that. I mean, I made my first mobile only a couple of weeks ago. I'm not sure we can start. Hey, if you don't set high goals for yourself, you won't be motivated to achieve them or something.

Yeah, I mean, motivation's been the problem the whole time. The problem the whole time. The problem the whole time. Well, for the last... But you have been off work for... A few weeks. Since the beginning of April. There was a slow drop-off in April, so I think mid-April was where I was kind of done.

Yeah. Yeah, but I saw what you built for April, so. Wow. I know. There were discussions and stuff. It takes some time to, you know, get fully in the mode of. There were other things going on, if you recall. Yeah, I've been off.

What about it? What's it like living the life of leisure leisure i'm really bad at it are you that comes is not a shock to me i i'm having some trouble so uh the trouble is i have a lot of things i want to do i have a lot of music stuff i'm working on or think i'm or i have a lot of things in the queue that i poke at i have some music classes i'm doing that are self-paced i have i went through yesterday the day before all the songs i have in progress and i'm like a whole ep of my own songs i could make i have three or four or five maybe half the next 12 x7 written album that that i could do i have a dozen songs and i'm and it's hard to pick one and focus on it. But you did do some studio work for other people.

I have done some session work for some other people and that's out and I'm done with it. So that's true. You know, I forget about stuff I do too. So it's like, oh yeah, I spent many, many hours doing that. But that's done now so it no longer exists in my brain. So I'm still hard on myself, even if I accomplish things, because the accomplishments dissipate like a little cloud.

Yeah, once you're done, it was easy. It's over. I'm trying to relax while I'm trying to do classes or educate myself or do hard things. It's hard. So, yeah. When I took some time off, I had to do the relaxation first. And then once I was relaxed enough, the hard stuff started to sound like fun. Maybe. I mean, these are things that should be fun, though. They're like the ukulele project I'm still working on. That should be fun. It's just woodworking. There's nothing hard about that.

Except that it's been cold in the garage and you've had to solder or you've had to sand a bunch. I should not be soldering the ukulele. you know, tricky putting it together and then having to sand away the edges without hurting anything. I mean, it's just, yes, it should be fun, but most fun things have an element of they have to be fun enough to get over the hurdle of... I guess, I don't know. It's just, you know, I find myself, I find myself wasting whole mornings and I'm not doing stuff It's just, you know, I find myself, I find myself wasting whole mornings. And I'm not doing stuff that's relaxing necessarily. No, not when you're playing on the internet.

Playing, yeah. I just, you know, I think there's a longer stretch of, maybe I need to disconnect from the internet or something for longer periods. But my dopamine system is not calibrated properly but you're going to get some from the ukulele soon because it's starting to look like a ukulele yeah sanding is hard like i have so so the step i'm on the body's put together and i had some problems with that but the body is basically some curved wood sides that are very thin in the shape, you know, the outline shape of the instrument body

and then it has two, a flat top and a flat bottom. And you have to glue all that stuff together. And gluing it together is difficult for a lot of reasons. Clamping is difficult. You have to do a lot of, you have to apply a lot of force to glue the top and the sides together. And I screwed up and I cracked the top when I was doing that. So that was frustrating.

But it's a little tiny crack. No, it's about five inches. Well, yes, but the other direction, it isn't open. Well, no, it's not a hole. It's a crack. Okay, yeah, yeah. But it's still significant. So I had to figure out how to kind of fix that.

I'm not sure I did. But then the top and the sides, the top and the bottom have a little bit of an overhang. Because, you know, you don't want them to be exactly the right size because you'll never get it glued together even. So they have overhang, which has to be dealt with. And that's just a very slow process because if you screw it up, you'll dig into the sides with whatever tool you're using uh whether you're using a chisel or a knife to kind of carve that away and then you want to get that down low enough that i can now sand it flush and i think i have but sanding takes a really long time so i was just going slow and i'm trying to go slow partially because i don't want to screw it up and go too far.

So anyway, it's not that exciting, but that sort of thing should be the perfect relaxation exercise because, you know, I can put a podcast on or something or watch an old episode of Star Trek with, you know, a sanding block. But I'm not bringing myself to do that. You spent like two hours on that the day before yesterday. I just forget these things. Anyway, so, yes, I am a month-ish into some time off, and I'm still

mad at myself. But Zelda comes out tomorrow, so then I can just excuse away the rest of my time off by saying I was playing Zelda. That's probably actually good. Let's see. Oh, I did want to mention that I was doing better with the whole burnout, and then I started to get worse and very droopy.

And Christopher finally said, you know, you're really droopy. Maybe you should talk to your doctor. And it turns out there are vitamins and minerals which you actually need to function. Huh. What are some of them? Well, there's salt. Salt? Salt.

Salt. Were you low on salt? No. I was low on iron. You were under-seasoned? Makes sense given my diet and gender. Low on iron. Low on iron.

Okay. But I mean, there's vitamin D and potassium and magnesium, all these things, bees and stuff. Those were all fine. Yes, but I'm saying that at some point you really should see like a doctor and say, are there chemicals I'm missing? Yes, you're very low on plutonium. Monofission? No, plutonium. Zircon. I don't think so.

They have a test for like those. I mean, you do need some weird trace elements do they have tests for like you know zircon or iodine well iodine yes this is that's that's yeah that's fine i mean it's really important but now that we're all eating gourmet salts we don't get as much iodine as we used to like we all are all are. Oh, come on. I did a taste test between the blue box with the yellow person. The umbrella. The umbrella girl. Yeah.

Versus like different. This podcast brought to you by Morton Salt. Different salts. And wow. That salt tastes terrible. So you prefer the pink dirt salt? Do you want to share the information you have about the pink dirt salt? Himalayan salt is just dirty salt from some—it's not from Himalaya.

It's like some scam that somebody came up with to sell— It isn't pure enough to sell as salt. To sell garbage salt, yeah. But it's probably got a lot of iron in it. With the pink there? Yeah, maybe. Okay. Let's see. You picked up some questions from Slack. Do you want to... Sure. There's a lot of them, and some of them are very broad and could be topics of whole shows. What exactly is GDB? Yeah.

Yeah, maybe that's a whole show. So let me start with an easy one from, and I apologize if I mispronounce your name, I think it's Guirandi Jongil. I recall an episode where you talked about installing an antenna to talk to your dad. How did that go is going? See previous section about how my projects are going. I have purchased all the elements for this system and they have arrived. I have a receiver that I need to solder together, which I just remembered now. And I have an antenna and stuff.

And I still need to learn enough Morse code to actually do this, which I'm also not doing. See, this is the thing. But you got up to like five letters. Five letters. There's only like 40 more to go. So I'm doing good. At this rate, I'll be done in 2063. Why do you think there are 45 letters?

There's 26 letters. There's 10 numbers. And there's a whole bunch of other little symbols and garbage. And then short little things. So it's around 40. Okay. Anyway, there's a whole bunch of little 10-minute-a-day tasks I should be doing, like maybe three of them,

which if you do the math on that, that's 30 whole minutes. And I'm not doing them. I don't understand why I can't motivate myself to do something for five minutes, 10 minutes. Anyway, that's not going. Thank you for reminding me. And I will, I will, I will. Maybe he'll start soldering the kit together.

Maybe I'll start soldering the kit together. The weather's nice. Maybe if the kit is done, I'll be more motivated to learn Morse code. You know, you could make a little device that would take typing and make it into Morse code. Sorry. Yeah, and I could just, you know, call people on the phone. I mean, that's not the point. I understand.

I do understand. I'm not sure. I'm just trying to, you know, where the blockers are. I don't think that's how you're supposed to do code. I mean, yes, I could plug it into a computer, but what... No, no, you wouldn't plug it into a computer. Yeah. You'd, like, use the Flex wouldn't plug it into a computer. You'd like use the flexor, flappy

paddle to hit it. And then how would I understand what people were saying to me? I don't know. That I have no idea. Next question in descending order of complexity. Let's see. From Steve... Steve... This is why I only say their first names. From Steve.

Steve Giggle, I think. Yeah. Let's go with that. I think it's Giggle. I doubt it is. Steve G-I-G-L, I apologize. Tips on getting back up to speed with development systems. IDE, compiler, debugger, you haven't worked with in a while.

Step one, install. And if it's Cubemex, go have lunch because it's, yeah, anyway. So, and then there's a parenthetical addition to this question, sort of separate topic, things you've never worked with. I mean, the short answer is they're all kind of the same they i mean most ide's anyway are organized in a similar way where you've got the editor and then you've got you know various panes they're all single window kind of things and you've got a debug pane or maybe a view that switches between panes and, you know, you've got compile and run and all that stuff. They aren't that different.

I think debuggers are where things get real different, but that's mostly a front-end kind of thing. Like the IAR front-end, the debugger, might look different than you're used to from GDB, kind of thing. Like, the IAR front end, the debugger, might look different than you're used to from GDB, but even then, GDB front ends tend to graphicalize things when you're sitting in an IDE. I don't know. I mean, this is not something I think about a lot,

because once I dive into an IDE, I kind of remap what functions are where, and they're all sort of the same functions. Do you have a better? No, I agree with you. I mean, VS Code actually is weird compared to historical IDs. That one took some more getting used to

because it's more like Emacs in a way, in the way it looks and behaves and the way it's customizable versus something like IIR, where I think of IIR as like the canonical graphical IDE, same as every other one that's been around since 1990. I guess I agree with you. I'm thinking of the ones that I've used in the last 18 months.

And there are two areas of difference. The first is configuration and setup. Yeah, yeah. areas of difference. The first is configuration and setup. Not just the configuration you can do with VS Code, which is extensive. But how do you set up a board? The difference between an IR compiler setting up an ST

board versus a Cubemex versus Kyle. Versus VS Code, board versus a cube mx versus uh kyle versus doing it from scratch versus vs code which is totally the hardest one on that that be getting easier but yeah and so that part is difficult and i don't think there is an easy way to translate between them no i mean, the Cypress thing was similar to Cube in some ways, but also was very idiosyncratic and different. Yeah, in terms of jumping back into ones you had used before and getting up to speed. It's a matter of time in chair. It's not, there's no trick.

I mean, if you're using one that has a lot of key commands, you know, printing out a cheat sheet is always helpful. Printing out a GDB cheat sheet if you need one because you've been using graphical. If you're motivated, reconfiguring all the key commands if you can to be a set that you always use. I would never do that. Sometimes you can do that. That means that your coworkers can't come up to your desk and do anything. Exactly. Yeah, exactly.

First of all, if coworkers are coming up to my desk, now I'm calling the police. Because they're trespassing. Ah, yeah. So the other big thing is the debugging. Yeah. And that, I think it breaks into kind of a GDB style that's less graphical and a like ozone style that is entirely graphical. And for me, that's, you know, when I have to do GDB, I usually have a worksheet up. And I have the weird habit of, you know, typing GDB worksheet into Google and then searching and then choosing a different one each time so that I can find the commands that I wouldn't otherwise find. So that's my strategy.

It's not a great one. I mean, there are some things with compilers occasionally. Once you get down to that level and you're kind of tweaking the build system or flags and stuff, like IRs had limits on... File path name? Multi-processor stuff, yeah. And Clang is a little different. But really, once you're at that level, it's, you know, I try not to have to remember things that I don't need to remember.

Like, I don't have a bunch of GDB flags in my head that I want on a build process, and the difference between those and the same kind of things on Clang. I just look it up. So I think the short answer for me is, okay, look stuff up when I get stuck. And maybe that's a flip answer.

I will say that in the last few years, instead of always using the client interface, I am doing more programming in VS Code and then swapping over to Compile. Well, that's just because the editor is better.

Yeah. I think that taking VS Code away from me now would be very hard because I'm just so used to how it searches through files and how it deals with Git and differencing things. I'm just... These are the tools I needed.

Just to be able to... The way it does split windows and stuff, which, again, is not a novel feature, but it does it in a nice way that I like and appreciate. Because you can have as many as you want. And remote SSH, which, depending on the projects you're working on,

is really super important. Okay, Steve. I don't think we answered your question. Nope, sorry. Good luck. What's next? I'll't think we answered your question. Nope, sorry. Good luck. What's next? I'll let you choose the next one. I'm just going to go down to the next one on the list, which is from Ben.

When should you put the interface for a project directly on the device, and when would it make more sense to support a remote control or control by phone? I asked follow-up on this whether he was talking about personal or product. Mostly personal, but I think for product is also a question. I think, I mean, for me, from a design point of view, it depends on what the device does. Let's talk about lights because this is something that we have in the house that do both.

I mean, we have lights that you control with the phone and you can change them in different colors and turn them on and off. We have light switches, which, you know, been around for a long time.

And we also, for the outdoor lights, we have the little remote that you go and you point the complicated remote at each of the lights to get them to do whatever it is you want. But that's just to change their color and stuff, not to turn them on and off. But yes, yes. That's an IR remote. And so the light switch is like the direct interaction.

The phone is a remote and the remote is a remote. Wow, that was really good. I would even argue that a light switch is a remote. Okay, unscrewing the light bulb, is that where we're going? Just in terms of geographical proximity, it's not, you know, you're not going up to the light and tapping on it. I mean, to some extent, using the little handheld remote to change the colors is more directly interfacing. We have no LEDs, no lights that have embedded display controllers.

That's correct. Because why? And yet I can totally think of reasons why. No, you wouldn't. I'm just staring into a bright bulb trying to look at the display. Okay, where are you headed with this analogy? There is no... It depends.

We have something that is super common, ubiquitous, everybody has them, and we have all of the interfaces. Yeah, yeah. So that's why I was saying, when should you use one versus the other? And because we have the different interfaces for a very good reason. We have some that are very simple to use, like light switches. We have some that are very complicated to use and can be used to do

programmatic things, and those are the remote things. And we have the outdoor lights with the remote that have a special feature that if you tried to put it on the device, it would be too complicated. And so you use this complicated

thing to go from device to device. I think that's a key point. So thinking about your device and complexity, it used to be there was no choice. If you wanted to have a device that you interacted with or customized in some way, you would have to put an interface of some kind, even if it was a knob, a set of rotary switches, or depending on the complexity, a, with a menuing system and buttons. And that's all hard to do on an embedded device. It's not hard, but it's a lot of work. And cost, if you're talking about production. for lack of me thinking of a better word, a lot of that complexity and display to something that isn't on your device, your phone, at the cost of implementing a communication protocol like Bluetooth. So I actually have...

The should is kind of a mix of what makes for a good interface and also what makes for difficult development. Like an example, I have a little guitar practice amp I just got. Yes. And if you think of guitar amps, they usually have a lot of knobs and controls and stuff. But this is very small. It's about, I don't know. Smaller than a bread box.

Twice the volume of, it's like half the size of a Kleenex box, maybe a little bit bigger. So it's really small, and it's great for practicing. It's got a rechargeable battery, so you can just take it anywhere. But it has like three knobs. It doesn't have any tone knob.

It doesn't have any, you know, bass, treble, drive. It doesn't have any of that stuff. It has one knob for switching between uh amplifier models one knob for the volume control of your guitar sound and one knob for the volume control of anything that's being streamed over bluetooth that you're listening to while you're practicing that's it those are the controls um and so it's very minimal from a guitar standpoint. But it has tons of controls that you can access through the phone where it brings up this whole virtual amp with...

You can have as many pedals as you want. Dozen pedals, and all of which have virtual knobs and an amplifier with all of the normal knobs on it, a dozen knobs. So that's a case where it's kind of form dictating your interface because there's just not enough room on there for them to put that many knobs. Or if they did, they'd be tiny little fiddly things that would be very uncomfortable to use. Little tiny buttons.

So I think sometimes form will dictate whether you displace those interfaces to some remote device. And as it gets easier to make smaller things, I think that just becomes a lot more of a common choice where, okay, even if you're making something like an LED display thing, say in a big LED array or a piece of wearable jewelry, you don't want an interface on those things because that gets in the way of their form. And so we have to take function and move it somewhere else that's not on the device.

And since that's become easier, I think that's just going to become more common. Thinking about Fitbit and interfaces there, there were three products I'm thinking about. The smartwatch, which had all the interface. The one, which had a screen about the size of your finger, half the size of your finger. It depends on how big your finger is. And it had one button that you toggled through things.

Yeah. And then there was one... It was mostly just display. There was nothing you could do with it except display. And then there was one... I don't remember what the little tiny one was. It had no display. It had LEDs. It had four LEDs that told you how...

or five LEDs that told you how full your exercise was. Yeah. But it had no other display. Right. And I think it didn't even have a button. Didn't you tap it? It didn't have a button. It had accelerometer taps which would show you the lights. And some of the difference between

those is cost, which is pretty obvious how the cost there will be balanced. And some of it was form, because the little tiny ones they were talking about putting into jewelry, which never happened, and that was always so sad. And the watch is a watch, and you have to want a watch.

Right. If that form is okay with you, then you get some additional interface capabilities. It's a four-man cost. Yeah. So there's that axis, and then there's the other axis of how many devices do you have? Because if you have a lot of complicated things you want to do, and you're going to have 10 devices, it's simpler to have one interface. But if you have a lot of complicated things you want to do on one thing, like the synthesizers, you kind of want it to be there. That's, okay, so that's a point that I wanted to bring up, which is direct control.

When direct control is important, because it's a pain in the butt to use your phone to talk to things. I mean, it can be nice, but phones are all touchscreen, and so when you put these skeuomorphic interfaces up with knobs and things, you kind of, you know, poke at them and it's not great for things the synthesizer is a good example because for when you're using a synthesizer you're often performing or recording something and each of these knobs does something to the sound that you might want to do in real time. And so the more knobs you have, the more immediacy you have, and the more options you have without diving into a menu, you know, three levels deep to find, oh, I want to set this filter to X.

Or even having a virtual control where there's a knob that's assignable. Sometimes that's a pain in the neck. So that's the other kind of consideration is what kind of a device is it? And is it something where you're going to be changing parameters a lot? And if it's something where you're going to be changing parameters a lot, that's something you want to have as a primary direct interface if you can. Okay, so cost, size, immediacy of change, the complexity of the interface, and the number of units you have.

The immediacy of change, I guess a corollary to that is how much you actually have to do with it. Is it something that you put in a corner and it monitors things and you just go talk to it once in a while? That thing probably doesn't need any interface. You don't want to go look at it ever. Like a

thermometer or a humidity sensor or weather station. You don't want to walk up to a weather station and look at it. You do though, don't you? It doesn't have anything on it. I know, but if the rain gauge had a little rain output sensor thing that

displayed what it's current? I don't know. Why would I want to do that? So you had an excuse to go wander around in the rain? Yeah, exactly. That's enough trouble being filled with spiders.

Let's see. Okay, Ben, I hope that was an answer. And that's not to say that the remote stuff is easy because if you do phone stuff, then you've got to write an app at minimum. I mean, and if you want to have it web-interfaceable, you know, if you're doing home things. Well, that's another way to do it, and that's getting easier, yeah.

But that's still, you have a website you have to interact with. Well, I mean, the CircuitPython, I showed you how easy that was. That's true. You don't have to write an app, I guess, if you're doing... But you do have to have Wi-Fi. Right. Which means that it may not be easy to get to from your phone. It depends on where you are when you want to use it.

Anyway, good question. If you control it remotely, how do you make it user or future-proof? I don't. Versioning. It's very important. I don't know. Versioning and end-of-lifing. Nothing's future-proof, is the answer.

Sorry, I'm reading a lot of Kurt Vonnegut. Oh yeah, that's going to make you happy. It's actually, in a twisted way, it does. We've got a few more questions here, some of which are long-ish. I think, Slla, we should bank those questions for a different time, because those all kind of go together, and that would be a good

whole show, I think. Do it with the documentation one. At the end. Scylla Ozer says, ah, documentation tips and tricks for legacy software and how to deal with uninteresting projects.

I don't know if you've been listening, Sia, but I have enough trouble dealing with interesting projects. Documentation tips and tricks for legacy software. There's applications that help with that, I think. Chat GPT? God, no. Okay, so how to deal with uninteresting projects. You're just going to skip the documentation one.

Okay. How do I deal with uninteresting projects? Go for it. Tell me how to do it. Okay. So there is internal motivation and external motivation. External motivation is your salary, but you forget about it, so it doesn't really work. What about your manager who might yell at you?

External motivation might be good, but the manager's going to yell at you either way, so why bother? Wow, okay. I haven't had a manager in a long time, but I've had some really good ones. But I've also had some that would yell at me either way. So you have to figure out why you are doing this, not why you are doing this for the company, but why you are willing to do this. And a good part of that is because they pay you, in which case make that more immediate. If I work on this for six hours, I will buy myself some small thing. If I work on this for a whole week, and

I make visible progress, I will buy Christopher a new amp. Why are you buying me things for doing your work? Because it's way more fun to buy you things. Wow, this is a good scam. How do I get this to... If you are doing it to get to the next thing,

if money isn't your motivator or snacks, then try to do the same thing. You're bribing yourself. You're trying to, you know, I'm going to work on this for two hours and then I'm going to look at the new stuff, I'm going to work on this for two hours and then I'm going to look at the new stuff and work on this for a few, few hours and then I'll get to look at the new stuff. Yeah. I think that's key is not trying to do it all at once too. Yeah. I mean, admit you're bored and find ways around that. I used to get new albums. That was like the best thing

for documenting stuff. Back when getting a new album was kind of exciting. And that's kind of sad that it isn't. Lots of new albums. Yeah, but I don't acquire and consume them the same way.

Music is more background for me unless I'm doing something specific with it, which is kind of sad. Let's see. There's also motivating yourself with... Who are you doing this for? Why did the word cheese just pop into my head? Christopher thinks you should use cheese.

Motivating yourself. There's also motivating yourself with cheese. I don't know why. That just popped in my head. Sorry. Continue. This is the way. Sorry.

That was a show title. I'm sorry. Okay. So who are you doing this for? There's a good argument to be made for realizing that what you're doing is helping other people, in which case do it so that it helps other people. If you're documenting something and it's boring, put yourself in the shoes of the new programmer who has to take care of this and try to be nice to them. Not only try to make it thorough, but also understandable.

Challenge yourself with making it interesting. Challenge yourself with making it educational. Gosh darn it. I know documentation is stupid and boring and everybody hates it, but I'm going to do a good job. And this is going to be better than anybody else's documentation they've ever seen. Or there's that, although don't polish the turd too much. But there's making it interesting for you by giving you a different perspective.

Yeah. Let's see. But more tactical tips and tricks, I think. I mean, when I see documentation tips and tricks for legacy software, what I hear is somebody has dropped into a code base that's not well documented and asked to document it. Or wants to document it so that they understand it better so they can work with something they're unfamiliar with. Oh, like Doxygen call trees? I love those. Yeah, but assume it doesn't have Doxygen.

Well, you don't need Doxygen to do the call tree part. Okay, so that's one of the tools I'm talking about. Oh, actual tools. So starting with getting a map for the software layout. I mean, the first map for the software layout is the file system. Yes. And so look at that, print out the directories, and then kind of categorize what each file is. And those will tell you, hopefully, what the modules of the system are.

And then you can start kind of writing a block diagram. So maybe for every.c and.h pair, you would draw a box. That works. And you can go the other way with the schematic and do it that way first so that you know what boxes you need to fill in. Assuming there's a schematic. Assuming. And then you can start looking at those files. And the H files, again, if it's properly organized, has the APIs and the interfaces.

And so then you can kind of start drawing lines between those boxes you've drawn based on that slightly deeper information to see how those modules connect. And then you can go from there and kind of drill down and do kind of an iterative process in each file the same way. Like, okay, here's the list of functions now. And how do they interact? But yeah, that's kind of a kind of broad breadth first kind of search thing block block first and i wouldn't go too far on that i would get that to a state where okay here are the blocks and maybe some some arrows and then you want to find main that was what i was

going to say follow the control follow where main goes and um you can do some of that by just walking through the code, which I have to say is probably the best thing you could do. But if you can put it with a profiler of some kind, like there's already a profiler, don't invent one for this. But if there's an easy way to profile it, where's the code spending most of the time? I mean, that's kind of an interesting question of what's most important. And then looking at where there can be layers, this is kind of once you have the blocks, can you separate it into a hardware abstraction layer,

a data layer? User interface, data model. Yeah, just kind of tear it apart because once you have that, it will be simpler. And I like diagrams a lot because it doesn't feel as much like documentation. It feels like doodling, which I admit I do when I'm reading boring things anyway well and a visual representation is a lot better than text for a lot of technical things especially when you've already got 10,000 lines of code the other option is to step through

probably later is to step through certain sections with a debugger when I am bored of just trying to read the code the debugger step is really good because it feels different than just trying to read the code, the debugger step is really good because it feels different than just trying to read it. It kind of feels like you're being led along a path. So I guess that goes back to as you're trying to figure out motivations, switch what you're doing relatively often so you don't get too deep into, okay, this is the 57th file I've opened today, and they all have 10,000 lines in them.

That's actually really good advice, and it's advice I just learned and hadn't really thought about from a class I'm taking in guitar. That's because that's all I do. But it was about how to practice and stuff, and the guy said, don't spend more than five minutes on anything. I don't go that far. No, but it wasn't. No, it's exactly what you're saying.

It wasn't. And this is different for music. It's obviously slightly different. But it was more of a mix it up some. You know, don't sit there playing a scale for 30 minutes or 45 minutes. Do five minutes of one thing and then five minutes of another, or 10 minutes, whatever. But if you find yourself sitting there for six hours,

going through the file system, you're going to burn your brain out. So maybe do 20 minutes of that and then 20 minutes and then kind of have each of these pieces come together. But I'm actually finding that that yeah one of my problems with practice is like i spend too long on any given thing and this is practice related but you don't see improvement right not until you get to the end of a class and you're like oh and now i can do all of these things it was pretty hilarious when you started a new class and it's like this class used to be so hard and now I can do all of these things. It was pretty hilarious when you started a new class.

And it was like, this class used to be so hard and now it's easy. Because you've taken three other classes between them. If I spend an hour on an exercise, I'm not going to be good at it at the end of one hour. But I'm going to be more tired than if I spent 10 minutes on it five times. And I let my brain, you know, reset in between. There's interrupted learning, I think is what it's called. And that's supposed to be one of the best ways to do it is to learn a little and then come back to it. Like for languages, you shouldn't take five years of Spanish. You should take one year of Spanish separated by

a year and then another year or whatever. I don't think it's a year even. Sorry for the diversion, but you reminded me of that by saying don't spend too much time on any one thing. Because I think that's just broad advice. People, I know I get locked into stuff and like after a couple hours of working on one thing, it feels bad. I mean, that's why I get so excited when I actually am in the flow state and it doesn't feel bad. Yeah. Like, oh, I can make this all dance to my tune. I can make it all work the way I want.

But I think that flow state is just an extension of that. I think flow state is when you're working on something where you're seeing little changes and it's maintaining its novelty as you work on it. Whereas documentation, I believe there is no flow state. Okay, and then if at the end and you're working on documentation and none of these other things have worked, set yourself a stupid goal. Like, don't use the word the. I am serious. If you want to have a hard time writing, don't use the word the,

or keep the number of Es to a certain number in a sentence. Just stupid game crap. And if you're just grinding, I mean, it's not going to make great documentation, but it will amuse you for those times when you just can't get any further. That's the thing. Sometimes documentation just needs to be done.

Depends on what you're documenting for. I mean, sometimes you just need to describe something in the driest possible way, accurately. It doesn't have to be great. Yeah. Okay. Okay. I think we need a GDB expert to come on and tell us about what it is and how you... It's the GNU debugger.

And GNU stands for GNU's Not Unix, so it's the GNU's Not Unix debugger. I feel like we've answered that question. Good job. Maybe Peter will come back and talk to us. He did the Blackmagic probe, so I think he has a lot of experience with that. Yes, so preview that question has a lot of experience with that. Yes, so a preview

of that question. What exactly is GDB? Well, that's long. How does one get started setting up a toolchain to use it for debugging? That's long. Remembering all that stuff, like loading the symbols, and if you're doing it by hand, and things.

So the thing is, IDEs are pretty good at abstracting away all of GDB's complexities. So I don't really think about that stuff anymore. Having set up GDB under VS Code recently so that other people could enjoy the abstraction, I can say that it's still not easy. Yeah, you did it for Cypress though. Yes, I did. Broken.

Multicore was interesting. But I remember, I mean, I used to do things like in the very old days, like in the 90s, if I needed a GDB something at Cisco, GDB didn't run on the thing. It had a GDB server. So you had to remote connect from your GDP that was running on your workstation over UDP or TCP using some protocol, I don't know what it was, to some little shim layer that ran on the router that

translated all the GDB stuff. So it was really weird, like, to be GDBing something that, like, and halted, but it's communicating over the network. I don't know. I guess people probably still do that, but I haven't come across that very recently. I guess it's usually over SWD and direct interfaces rather than over the network. Just doing it over the network has always weird rather than over the network.

Just doing it over the network has always weirded me out. Sorry. There's a lot of complexity with GDB you can get into. Yeah, there is. And it's interesting because it supports

so many different processors, so many different languages, so many different options, and everybody needs to do this thing and not that thing, and it it's just it's quite the bucket of tools yeah so we should have a gdp show what would you tell recent ee or cs gratis never used a debugger on an embedded system before you should use a debugger step through debugging will change your life it's kind of like you can drive a car without a steering wheel

if you had a lever that you moved with your knees. But wouldn't a steering wheel be better? I'm comparing printf debugging to... Anyway, yeah. Yeah, yeah. That one we should defer to talk about longer. So... I think that just

about covers oh well and the other long question was what exactly are the compiler and linker who

sets memory locations allocates memory which parts of RAM data and which parts of RAM are data and

program stored all the memory stuff plus how the compiler and linker uses that so I think that's a really good topic that we've kind of gone into with memory maps.

But I think you'd like my book. And we have some blog posts that cover some of that. And I think it is a much longer show that would be kind of fun to have with one of our regular guests. Okay. What are you going to do this afternoon? I'm going to edit this podcast. What are you going to do this afternoon? I'm going to edit this podcast. What are you going to do that's fun this afternoon?

You could build an antenna thingy, Bob. You could just lay it out in the yard just for fun. The antenna, I mean, that's just wire. You could work on your ukulele. Yeah. You could play music. You could just bash on the drums. You could play FIFA.

I don't know. Read a book, go to the beach, take a walk. You're all very good options. I don't know. Oh, wait,

your birthday. What about it? What do you want for your birthday? I don't know. Oh, wait. Your birthday. What about it? What do you want for your birthday? I don't know. To be six years younger. Six? Yeah, it's just a number. That's all birthdays are.

All right. Well, then Christopher doesn't want anything for his birthday. I want a cake. Really? Yeah. Like ice cream cake? Chocolate cake? Thank you for listening.

Thank you to Christopher for producing and co-hosting. If you'd like to contact us, hit the contact link on embedded.fm or email us at show at embedded.fm. And now some Winnie the Pooh. Okay, Piglet had gotten Christopher Robin because he had seen a heffalump and was quite frightened. And okay, so Piglet wasn't afraid if he had Christopher Robin with him. So off they went i can hear it can't you said piglet anxiously as they got near i can hear something said christopher robin it was poo bumping his head against a tree root he had found there said piglet Isn't it awful? And he held on tight to Christopher Robin's hand. Suddenly Christopher

Robin began to laugh. And he laughed and he laughed and he laughed. And while he was still laughing, crash went the heffalump's head against the tree root, smash went the jar and out came Pooh's head again. Then Piglet saw what a foolish Piglet he had been. He was so ashamed of himself, he ran straight off home and went to bed with a headache. But Christopher Robin and Pooh went home to breakfast together. Oh, Bear, said Christopher Robin, how I do love you. So do I, said Pooh.