Embedded - 489: Constructive Cat

Episode Date: November 16, 2024

Chris and Elecia discuss her origami art show, ponder PRs for solo developers, attempt to explain GDB debugging, and make a to-do list for getting rid of Kanga. Elecia is having an Origami Octopus Garden art show at the Aptos Public Library for the month of November, 2024. The postcard advertisement is below. There are more pictures on her Instagram (@elecia_white). The python tessellation generator is here. Memfault’s Interrupt Debugging Firmware with GDB post is a much more considered explanation of GDB and includes pointers to other resources (including using Python with GDB). Transcript Memfault is a leading embedded device observability platform that empowers teams to build better IoT products, faster. Its off-the-shelf solution is specifically designed for bandwidth-constrained devices, offering device performance and product analytics, debugging, and over-the-air capabilities. Trusted by leading brands such as Bose, Lyft, Logitech, Panasonic, and Augury, Memfault improves the reliability of devices across consumer electronics and mission-critical industries such as access control, point of sale, energy, and healthcare. To learn more, visit memfault.com.

Hello and welcome to Embedded. I am Alicia White, here with Christopher White. This week it's just us. And that's all I have. So, we need to poop? Yep. And it's 4.15 in the afternoon, so we're late. And this won't drop until another day.

And also, it's late enough that I should have brought my reading glasses to look at this computer. So, I don't even know if we're recording right now. Well, that part does seem important. It looks like numbers are going up. Okay. We have a contest going on, or we did, for folks who were interested in getting a copy of Looks Good to Me by Adrian Tackett and Ben Comby. Nathan Orff and Ralph Hempel have won. And I will be sending you all emails.

Thank you for the nice things you said about Memfault. Wait, what? Oh, right. Right, that was... Confusing. Yeah, I know. Nathan also asked a question. Last episode about code reviews was interesting.

At his company, they often have only one embedded software engineer working on a project. And it gets more difficult to get a review or give a review. Do you have any advice on how to code review when projects are worked on by a single developer? There's no other developers? There's just a single developer? Let us say that it is one developer in a team of developers, but they only ever work on their own thing. Kind of like you and I.

We don't really work on the same projects right now, so asking you to code review one of my things would mean that I have to spend 10 hours explaining what it is I was supposed to be doing, what the code is trying to do. I don't think it would take 10 hours, but that was going to be my suggestion, is to incorporate a small design review at the head of code reviews. Because if people are always unfamiliar with code, then the kinds of things they're going to be looking for are not as deep as the kinds of things you want to be looked for. Right. Walking into a code review where you don't know anything about the system makes you far less effective.

But that's pretty common anyway, even on teams that are more tightly knit. Because sometimes there's areas of the code that you just don't walk into. The only times you see them is during code reviews. So I think it's a common problem. It's just made worse by the fact that if there's fewer developers or only one developer in a particular area,

maybe all the other developers are app developers or something. So then it gets even trickier if like, oh, this isn't even a language I'm really familiar with. Hmm. So I have been working some, trying to figure out code reviews better. For a client. For a client. But also just because this is a question I have had. I mean, like, do I talk to Philip over at Embedded Artistry and ask, you know, maybe he code reviews for me sometimes and I code review for him, but then we have to do NDAs and...

And then you can't do NDAs on behalf of another company and, yeah, that doesn't really work. And then we run into the problem of either we have to do it often or you don't really remember what the project was. So one of the things, there are a couple of things that have helped me. One is to, okay, number one, do the whole get branching thing. I didn't used to be in favor of this, but I am becoming more in favor of it. You have the main or

the dev branch, and then you pull a branch called feature, blah, blah, blah, and then you merge back, and you have a PR to merge back into dev. That PR is actually really useful.

Pull request. Thank you. Pull request. Which doesn't actually help explain what it is at all. No, no. Because it's all Git terminology and it makes zero sense at all because actually it should be a push request.

No. You're requesting other people pull your code. But you're requesting to put your code in. You're right. It should be a push request. Anyway, this is one of my... But it is at this point as you are doing this PR

which we're not going to define now. A PR, it's your collection of... It's a peer review. Sure. But it's your code in a format on a website that people can look at and approve or make comments on. And it may be one commit or it may be enough commits to make this feature mostly done. Right.

Okay, so you have this thing. You've collected a couple of commits. You've pushed them to the server on a branch. And now you would normally, if you were in a team, send that out. You'd fill out a PR and then other people would come and review your code. Okay. But you're by yourself. If you still do this, you do a couple of the checks for the PR system.

Usually as part of a PR, you compile and test on the unit. Well, hopefully you did that. You look at the differences and make sure they are as intended. If you hadn't already done that during your commits, sometimes you're like, oh, right, I have a to-do in there, or a fix me, or I don't check in. is the point where you you actually have you can you can do your own reviews for those things i have found that looking at them looking at my code in that format versus in the editor where you can see the changes and they're highlighted differently yeah and it's not in your editor that you're used to and you kind of i don't know gloss over things because it looks like your editor sometimes just changing the

context can make let you see things that you wouldn't normally see when you were coding. So yeah, I totally agree that just going through that process gets a lot of things noticed by yourself. And I've been looking at Adrian's pull PR templates. So whenever you're adding a feature, you have to fill out this little form. Like, does this feature cause any backward compatibility problems? Of course, you should have been thinking about that.

But a checklist really is quite helpful here. And it also makes you think of this feature as a single feature and not as three weeks worth of code. You are committing an enclosed thingy-bob and not randomness, which that sort of structure is good for programming. It means that we aren't just randomly running around the code changing whenever we want. And then you set up your PR for Friday. And on Monday, you come back and review that code and wonder, what idiot wrote this? But then you have to admit that you're the only person on the project. It's always surprising to me how quickly I forget what I'm working on. I mean, I would normally

say if you can wait a couple of weeks, that's plenty. But you can't probably. So even a weekend is enough for you to get a little bit of distance from your code and then you do your own code review. And again, going back to Adrian's book, because that was where this conversation came from, there are checkboxes, a checklist of what you would do as a reviewer. And you can pick and choose what's in her book, whether or not a reviewer is supposed to test it or compile it themselves, whether a reviewer has some automated tool to make sure that you confirm to standards,

which hopefully Jenkins is doing for you instead of some other person or even yourself. It's just... Along those lines, I would recommend setting up even if it's just you, some static checking on the pull request system,

whether it's GitHub Actions or Jenkins or whatever, that do a build, if you can, and maybe some unit tests, and maybe do a Clang format or something like that. A lot of this is more important because you're by yourself. But it's nice because if you set that stuff up, what you're saying about the checklist is some of those things just happen. And it won't let you put it in if some of those things fail. And you don't have to worry about, oh, did I do that checklist item?

So just setting some of those things up. Just, you know, if you're by yourself, yeah, just get the easy things. The hardest thing is to find, you to find the deeper, weirder bugs that somebody coming with fresh eyes will see. That's going to be less likely unless you just do a mind wipe, like you said, or have a head injury between pushing the PR and reviewing it. And maybe there the rubber duck analogy is the best thing to do,

is to to you know all right if i'm going to review this and nobody else is going to look at it maybe i should do a presentation to nobody about this code i mean definitely you could have two or three stuffed animals and each one could have their own little quirk that's going to be triceratops. That's going a little too far, but sure. The nitpicking mongoose. You know, you can have whatever you want. The no narwhal. This sounds silly. And it is. It's not. But it also isn't. There is value

to having to articulate your inside ideas to the outside world. But I'm going to say that it takes a great deal of self-discipline, which I don't have. So much. And, you know, so if there is a way to find, if you're on a team that doesn't have, that there's nobody else, well, then there's nothing else you can do besides these things we're describing. If there are other people who are at least developers of some kind, I think it's valuable to give a presentation to them

instead of stuffed animals, even if they're not familiar with the code base or the code. Because then, you know, usually they're smart people and they will have questions about just how things work and did you think of this? Or, you know, things you might not have thought of because everyone has blinders. So it's worth having at least a design review or a walkthrough, maybe not a formal code review if they're not up to reading the subsystem in detail, but just a walkthrough and are there know, are there any questions or have I missed anything kind of things? Because the goal here is not to perfect code. Because guess what? There isn't any perfect code. The goal is to find obvious things, find things that are going to cause problems later that you might miss on a cursory walkthrough

to find the cursory walkthrough stuff, typos and gross errors and compile errors and unit test failures. And then beyond that, just have a different set of eyes on the problem so that people can maybe notice something you didn't notice. Because that's the key. We're all focused on what we think is a full understanding of things, but we tend to get very narrow. And so outside input of any kind is useful, as long as it's constructive.

Constructive cat. Constructive cat. Constructive cat. Yeah. So I think it's possible. I think it's worth doing. I tend to think that if you want comments from me that are about spaces, if a comment can be made by a robot, I actually refuse. There shouldn't be comment-stuffed spaces, because you should have a formatter that just does that. Yeah. I mean, we should be beyond code style, unless it's egregious stuff.

Clang formatter does a good job. And so if you can find somebody else, and it's going to be a trade, and it's not going to be a worthwhile trade in the beginning. I mean, I guess. I don't think of it that way. I mean, if you're in an organization, it's not a trade. It's a, this is your job. Yes, but I'm asking you to stop doing what's obvious on your job and to work on my job for a little while. That's management's job to say you have to do this because...

It's easier to trade with someone. that empowers teams to build better IoT products faster. What that means is that if you have just realized that you're going to build 5, 10, 100, 50,000 units and you need to keep track of them, they'll let you create your own dashboard to observe how your system is doing in the field. Memfault gives developers a more scalable and sustainable process. This accelerates the timed market

and de-risks product launches. You can cut product costs and deliver more high-quality software. Trusted by leading brands such as Bose, Lyft, Logitech, Panasonic, and Augury, Memfault improves the reliability of devices across consumer electronics and across mission-critical systems, such as access control, point of sale, energy, and healthcare. Thanks again to Memfault for sponsoring this show. Check out memfault.com and the Interrupt blog, which is filled with incredible amounts of information. Okay, so let's see. What else did I have on my list? Seriously, we should just go straight.

I mean, we left off on how to get rid of Kangaroo. Let's see. Origami. Origami. That's why we had to do a show. I mean, actually, I had somebody scheduled and then I messed it up, but that's all fine. It'll all happen soon. But we're going to have like three shows Thanksgiving weekend. Don't tell Christopher. But I have an origami show going on. Tell me about your origami show.

You went, didn't you go? Several times. Yeah, I need to go by again today. So I have two book of octopus and jellyfish and random weird curvy coral sponge wave things and books. And on the left-hand side is order, which are all the symmetric things. And on the right-hand side is chaos, which is all of the, where the octopus start lifting their legs and get all squiggly and stuff.

And on the order side, I have natural history books that they're all reading because it's a library thing. And I was really excited to add books to it. On the right-hand side, it's art books, origami books, really, and my book, but that's kind of hidden in there. And on the top, there are the light colors and on the bottom, there are the dark colors so that it has the effect of going down the ocean. And it's really better if you see it from the side because that's where the kids would see it and those are the ones who came in and get excited about it and it's all designed and folded by me so like I'm not the first person to put sign patterns together but definitely everything was stuff I made out of not other people's patterns there was one pattern I actually

really wanted to put in, and then I realized, oh, this is actually somebody else's pattern. I can't put it in. And instead I just took that origami book, flipped it to that page, and put an octopus on top of it. Because it looked like starfish. I could only do minor mods, and then I was like, this is somebody else's pattern. I got cards.

I decided. Somebody actually offered me money for one of the jellyfish recently. And I was like, no, absolutely not. It doesn't matter how nice you're trying to be about this or if you have somebody you want to give it to, just ask me for another one. You're a friend and a neighbor, just fine. Because they can't pay me

what it would be my engineering rate to make them. That would make them cost prohibitively the amount. Guess what about art? And yeah. And so I don't want to make this business.

No, you already went down that road with something else and didn't enjoy it afterwards. It meant, I mean, when I give something to somebody now, it's like It meant, I mean, when I give something to somebody now, it's like, here, I made this. If you sell something, you have to look and say, oh, the legs aren't quite perfect. Well, there's that, and then there's kind of,

you're doing it for your own enjoyment, exactly. It totally is for my own enjoyment. But it's a different pathway, right? It turns it into a job instead of, I don't know. I mean, we all like to get compensated for things that we do like this. But compensation comes in different ways, and it's not always money. I went to the library last week, last Friday afternoon, which was not a hopping time at the library, basically just to snoop. So I sat in a chair that was a ways from where the display case was. And I just watched people

walk in and I folded a jellyfish while I was there. And I just wanted to see if anybody actually noticed. And because when I was there with other people, people noticed, but I didn't know if they were noticing because other people were standing around it, you know? Sure, yeah. So, you know, people came in. It was kind of interesting, people watching. But then this little girl came in. She must have been about 10. And she walked in. The display case been about 10. And she walked in. The display case is near the door.

She walked in. And she stopped. And she put up her foot. And she put both hands on her cheeks. And she smiled and just was so gobsmacked. And I loved it. And so I gave her the jellyfish I was working on, which if I was selling them,

I don't know if I could. No. Yeah. Well, I mean, yeah, yeah, no,

I think that's, that's great. And I think, I think it's fun. You went down there to, to see what people, I would be embarrassed, not embarrassed.

I would be, I felt totally like a creeper, but yeah, not like a creeper, but I would just be hesitant. Cause I worry about, like, oh, what if... I mean, they're library kids. I know. They're the kids that are excited about things.

But I did do, I mean, like, I made postcards. I wasn't going to because, I mean, why? But I wanted to feel like this was real. Like, how do you feel if something's real? Just make it real. I mean, what would be differently real? Like, you have an art installation in a public place. That's it.

It's real. But it's not because, and I hesitate to say this because one of our listeners said, oh, it must be really nice that somebody accepted this. So the way that I got an art installation at the library was I went into the library

and said, so those display cases, how do people fill them? And they gave me a form. Yeah, yeah, I know. And then I wrote in the little form and she said, oh, that sounds like fun. And then she put it in the folder and said, how do people fill them? And they gave me a form. And then I wrote in the little form and she said, oh, that sounds like fun. And then she put it in the folder and said, how about November? It wasn't a juried art show. That's fine, but there's a lot of stuff like that. But that makes it feel less like an art show. No, I kind of get that. But if you had held a

reception at your house or your studio, would that have been less? Imagine you had a studio and you held a reception and invited house or your studio, would that have been less? Imagine you had a studio and you held a reception and invited people. I know. Would that feel any different? You set that up. One of my artists. You bought the studio. Friends did suggest having a closing.

No, but you know, get what I'm saying, right? Oh, oh, if I had an opening at my, if I had a studio,

if I had, yeah, that would feel fake too. Well, I bet most artists don't, had... Yeah, that would feel fake too. Well, I bet most artists don't feel that way. So anyway, I think it's cool. And I did a little artist statement and I did a bio. I don't know. It was kind of cool.

And Chris came and took pictures and got lots of moody shots that are really fun. Moody? I wasn't shooting for moody, but okay. Well, yeah, but you got like one octopus really well in focus and some of the others not in focus. So it makes it look like that one is more alive than the others. Right. And you got some of the curvy things. I don't know.

I liked the pictures. So what have you been up to? Work. Drumming. I worked a lot today. I built more hours today than I usually do. Civic duty. I'm so glad your civic duty is over.

And trying to not go insane um some of those things are going okay i'll leave it to the listeners to figure out which how's your drum class going it's good it's you know it keeps it's a lot of work and it's slow progress and focus on very minute details of technique and stuff so it's it's a challenge but i have to do a cover this it's divided into modules there's 10 modules for the whole course and it's supposed to take anywhere from six months to longer than six months it's taking me longer than six months because i'm on module six and what was six months to a year yeah and you're but uh in this module module six there's a mid project, and that's to do a drum cover. And I think I've picked the wrong song, so I need to spend some more time thinking about maybe changing her.

Did I hear you say it was an old Satriani song? Mm-hmm. I'm telling you, Dr. Worm was way better. I mean, old as in newer than Dr. Worm. Oh. Fine. But it's a little too fast for me to uh endure for the four and a half minutes uh without building up some some stamina on my right arm so yeah i know it's fine the drum the drum thing's good uh working on some new songs uh still working on new songs for the band.

Someday we'll have a new record. Not maybe this year. Maybe. No, not this year. Maybe. What year is it? It is currently 2024. We're speeding into 2025.

For some reason I thought it was like April. Probably next year. Probably next year. Definitely not this year. And yeah, and I have sort of ramped up on an older client because they have more stuff for me to do and adjusting time with the other. So things are kind of balanced. But yeah. Do you still hate computers? I don't know that they were... I'm becoming less and less happy about computers as the weeks go on. But I have to work on them.

I am doing stuff for this client. It's kind of fun and working on UAVs again and doing some CAD stuff, which the problem is I don't do very much of it. So if I do it once a year, I have to climb the learning curve every damn time. So luckily for this, I didn't have to, I thought I was gonna have to modify a lot, but I didn't have to modify too much.

But I have to figure out some camera mounts to mount to this UAV and that's a bit tricky. Are there skills for you that are more slippery than others? Oh, yeah. Yeah. I mean, stuff like that where I only pick it up a couple times a year or something like that. But there are some things I can pick up a couple times a year

and still be fine with them, and I'm not sure they're simpler. They're just stickier. Anything to do with cooking is not slippery to me. Like, I can make a recipe in April, and in October, I can make the same recipe from memory or from one quick read of the recipe if I used a recipe. Yeah, I don't know. I mean, the stuff that tends to...

I mean, not to be flip, but that sounds a little simpler than the things that I lose. I don't know that I have anything like that. I'm trying to think of something that... But like, you know, Python. I have to go look up Python stuff all the time again. Every time. Python is I have to go look up Python stuff all the time again. Every time.

Python is stickier to me. Python is stickier, but there's still aspects of it. Like if you asked me to go work with Pandas, I have lost all my Pandas, even though I spent many, many hours working with it. It would be faster this time, but if you asked me to sit down in an interview and write some Pandas code, I would not be able to do it. You'd draw a black and white bear right uh yeah i don't know um certainly physical things like like you know musical drums and that kind of stuff some some parts of that are sticky and some are very not sticky like if i don't do something every week i'll lose it. Certain techniques and things. I wonder if it is just complexity and whether or not it builds off existing knowledge well. The things I tend to lose are like, I mean, really, really badly, like applications that

have a thousand buttons and stuff, you know, so the CAD program, it's got, you know, a row of a hundred icons at the top and all these modes and stuff, or keyboard shortcuts, and just a lot of, there's just a lot of stuff to remember. There's an origami program that I want to use, and I opened it, and I looked at it, and there were more buttons than Photoshop, and then I just closed it. And I want to learn it, but I don't want to learn it enough

to have to look at all of that while I'm trying to learn it. Yeah, I mean, it's tough to want to know how to do a lot of things because to some degree you have to keep refreshing that knowledge and once you know how to do too many things, you run out of time to refresh. Yeah, I've been thinking about that with some robotics. Some robotics is sticky and some of it's just

I just keep I don't know why I can't make it stick. And I can't make it stick from week to week. So if I get interrupted I get a little well, I guess maybe I don't truly understand some of it and then

I get interrupted to do something else. And then I believe I understood it better than I can't do it. And I wonder why. I also find that there's kind of two aspects of stickiness. Like, just to use an example, if you ask me any of the 26 letters in Morse code, I can tell you, I know them all by heart.

It's fine. But my speed with copying them, if I listen, if I don't practice a lot, it goes away completely. And suddenly I can't keep up at a very slow rate. And so, yes, I know. Why would you have to use the ASCII chart to communicate? Why would that be more helpful? It's just easier to remember with A at 41, 61. Okay. Can you do that at 12, 12 words per minute? Anyway, what was I talking about? Morse code. I'm sorry.

So no, but like, so I have the knowledge of Morse code where I can rattle off any of the characters, but my proficiency with it as a skill, which is separate from the knowledge, goes away quickly without practice. And that's true of a bunch of stuff, I think, like music and code and other things like that. Like, yes, I can tell you all about all the keywords in C and how C works. But if you ask me to do a particular, like, small container class of some kind in C++ or something, I might not remember how to do that. Anyway, I don't know if that made any sense. But I think there's multiple aspects. I think that's how people feel about function pointers. Function pointers. It's a syntax. It just doesn't. It's horrible. It's a really bad syntax.

Although I think I finally memorized it after 20, 30 years. And I no longer use them anymore. Exactly. Oh, oh, I want to go back to origami. I'm sorry. Is that okay? I don't care. This show is about nothing.

I'm really sorry. Usually, I mean, it will be better next time. I promise. That's fine. So a friend came out of town and asked about, and was surprised by the display because it was jellyfish and octopus. And I mostly have talked on the show about snails, which I had been working on for a long time and had a lot of Python scripts to generate snails. And then I had the biology in there. And then if you cut the origami snails in half, they look like if you cut a snail shell in half, which was all very intentional. And yet there were only a couple of snail shells kind of hiding in my display.

So she was surprised by that and asked about coding and what this had for coding. And I do have quite a bit of software that goes with generating. generating um but it's more it's more in line with how do you make patterns change okay so like a lot of things start with uh sine waves if you put a sine wave uh you have three parallel sine waves and you fold mountain fold valley mountain fold. And then you end up with this nice undulating curve sort of thing. Okay. How far apart do you put those sine waves? How close together can they be? How do the undulations of the paper change? And I'm not modeling anything with this. I mean, I could use the origami simulator

to model some of it. I just have an easy way to change these things and keep track of them. And to make sine waves or to make different forms of Gaussian-based waves. So not quite sine, just a little bit

different, more spread out, less spread out. Okay. And it's not just about amplitude. Anyway, most of the software around these has to do with being able to make repetitive patterns in a repeatable way with lots of different variations. Okay. I mean, I can have a sine wave and then a straight line and then a sine wave, and it gives me a totally different pattern depending on how far apart those are.

Sure. And whether or not the sine waves are in phase or out of phase, or just a little bit out of phase. I did a lot with just a little bit out of phase. That's fine because it makes the paper compress, which makes the paper kind of shiny. Anyway, there is software. There's Python scripts.

If anybody is interested in those Python scripts, I'm always happy to share. That one in particular is a parsing problem plus the kernel shapes. Kernel shapes. So like I said, Gaussian versus sine versus... The basis functions of, I guess, what you're doing. Okay.

And then sometimes I can multiply functions too. So I can have a sine wave that is slowly getting larger. All right. And that makes a nice pattern. It makes a really nice pattern, though. Yeah, so I was trying to remember what people had said when they saw it. And, yeah, it's not snails. Although, if I was going to do this again, the temptation to do the art and science of snail shells would be so high.

But I also kind of want to work on flower patterns. I know it sounds kind of girly girl, but I think there is some maybe interesting science with the flower patterns. But it would still be one piece of paper. Anyway, anyway, this is what I think about before I go to sleep. It would still be one piece of paper. Anyway. Anyway. This is what I think about before I go to sleep. How do I make flower patterns in origami?

How do I make them structurally similar to actual? You include the stem too. I wasn't. Sounds harder. I mean, I kind of know how to, but I, yeah. Anyway. Anyway. Anyway. Anyway. Anyway.

Anyway. Should I read, should I read Winnie the Pooh? I don't think so. We got a lot of time left to fill. How much time do we have? 25 minutes at least. We're going to need another technical question, aren't we? Okay.

Do you want to talk about debugging or pull requests somewhere? It depends on the debugging. What's the debugging question? How to debug? What exactly is GDP? No, no, I don't know what GDP is. It's a mystery. Boy, I don't know if I can speak to this off the cuff. I don't even remember how this stuff works.

Do you remember how they work? At the lowest level? Well, that's one of the things that has changed over our career. I'm not including hardware debugging. Like, even just on a desktop debugging an application. Oh, I was thinking including hardware debugging. Like, even just on a desktop, debugging an application.

Oh, I was thinking the hardware debugging. Maybe hardware debugging is easier to explain. No, definitely not. Oh. Okay, so GDB, when you compile your program, you're right, let's just start with just a program. You start out with a.c file, hello world. And that goes to an object file. With an intermediate step, but yes.

And then the object file has all that code, but it doesn't have printf that comes in a library. And so it gets linked by the linker, which a lot of us call GCC the linker, but it's not. But GCC can invoke the linker. So we don't really care. Okay. So you have the linker and the linker takes this Hello World code, and it takes the printf standard library code. And it puts them in the same file, and then it tells them how to find each other. So the first thing it says is where to start. You want to start at main. Okay, so we're going to go to this address because this is where main was defined. And then you step down, and it says printf.

Who says? What says? Oh, your program counter. Now we're running. Yes. Okay. We're running without debugging. We're just running.

So you invoke your program. It goes to main because that's where it says to go. And it goes through. Your object file has the actual machine code of your op processor. Your executable has the, yeah. Well, so does the object file, but the executable has the machine code, which is a list of instructions, which are op codes, which are very small. Push, pop. Instructions that run natively on the processor.

Push H into this register and then take this register and put it on the screen. Or do... No. I'm taking the screen as an entirely... Okay. That is its own... But they do math,

they do arithmetic, they do comparisons, and they can do conditionals. And there's a lot of these instructions in it. You know, early computers had fewer of them. I feel like we're pretty far from GDB now. We'll get there. It's very important because this is what GDB is stepping through. Okay, okay.

And your program is stepping through. Your program is not stepping through C code. No, it is stepping through assembly code. It's going to be very confusing. Okay, go ahead. So it steps through the machine code instructions. The processor does this. It's incrementing the program counter and doing it.

So there's nothing else happening. The operating system isn't walking through your program. The program is running on the processor. And so it's following these instructions that are these opcodes that are run on the CPU. The CPU is doing its thing. Okay. Sorry. Okay, now, next time you compile, you compile with dash G to get debugging available to you. When it didn't have debugging,

it didn't put the name printf in there. Right. It just put the address. But now that you're going to have debugging, it's going to say, you know what, not only do you want to go to this address, by the way, it's called this.

Right. And it may include additional information like, and it is defined in this file. And it's this line of code. And this line of code. And this is the debug information. You can debug without that. But let's not. You better know how to read assembly code and know what all those, you know, yeah, yeah.

Because it's not going to have any hints for you. It's just going to be the raw code. So your debug-enabled executable has extra information that tells GDB all this other stuff. Otherwise, GDB only has access to the list of low-level commands. Not C, but much lower level. And when you have debug-enabled, GDB can go through and say oh, okay, yeah, so I'm going to print on the screen that you are at the line of printf. I'm going to show on the screen What's GDB? GDB is a program

that you can send your executable to. So you say gdb myprogram.exe or gdba.out. And now GDB is taking the place of your processor. It doesn't act as a VM, though. No, it's not taking the place of the processor, but I think it halts. If you're in step mode it halts because when you're running a continuous mode

I don't think there's a performance hit not on a regular computer so it's when you're so what GDB does it's the good new debugger it allows you to step, to run your code

to break inside your code when it's running, to stop it, resume from there, or to step plus a bunch of other stuff. But those are the major kind of operations. And while it's stepping through, it's going to tell you where you are in the code by showing you what line from the C source file or the assembly,

depending on how you view it. And you can also interrogate things like, what does this variable value have? What does this register value have? Okay. I think... Is that okay? Okay. So we have compiled the code.

We've linked the code. We've compiled and linked the code with the debug enable option. We have used GDB to run the code and then stepped through the code because GDB allows us to put in breakpoints. And even when it isn't obvious there's a breakpoint, like it automatically breaks on main, there is still the stuff going on.

And if you you can do obj obj dump obj dump object dump and it will show you the information that is in your executable for debugging.

So you can see what GDB sees if you want to. Of course, GDB is a program, and it has a lot of memory, and you'll probably get bored looking at all those numbers. Whatever. It has the map file that I'm always going on and on about. It's all in that OBJ dump. Okay, so that is on your computer,

probably on your Linux computer because it's GDB, which is... Did we say what a breakpoint was? A breakpoint is a thing where you can say, I want to stop at this line. Hey, processor, stop here. And let me think for a bit. Or this function.

You could say, okay, main, just go. But as soon as you get to my function do stuff, it stops at do stuff. And then you can step through do stuff or continue from there or whatever. But you can do all sorts of powerful things, like sometimes watch points. Like if this variable is 42, then stop. Or you can switch between threads if you're on a multi-threaded program, all kinds of stuff.

It's very powerful. You can even script it with Python. Okay, there, done. And scripting with Python actually is important because you can do some really cool stuff with that. I haven't ever done it, but I have seen really cool stuff. Okay, so now we have DDB for embedded systems. This is where everything goes wrong.

Well, one thing that goes wrong is you can't fit all that debug information on your 8K RAM processor or with 2K of flash or whatever. It's bigger than the program. Oh, well, I guess we're doomed. We're so doomed. Yeah, so that is one of the biggest problems, is that all of that debugging information, it can't be in your executable.

If your executable is size-limited and has to be downloaded or burned or programmed. How am I going to run GDB on my PIC? That's the other problem. It doesn't fit on there. Instead of running and compiling on the same device, you have to do cross compilers, cross debuggers, where you run your GDB, you run your compiler on your computer, but you run your executable over on your little processor. How does that work? My processor's over here and my computer's over here. Magic dust.

Okay. Good show, everyone. Sorry. No, no. I thought I'd want to leave it there. Magic dust. I was being silly. No, I mean.

There's a piece of hardware. There's a piece of hardware. Usually there's a piece of hardware between them. Yes. Which is often called a JTAG or JTAG programmer. Usually has nothing to do with JTAG. Sometimes it's called an ICE. Sometimes it's called an ICD for in-circuit debugger. Sometimes it's called a USB cable.

Sometimes it's called a USB cable. Sometimes the dev boards you get have these built into the dev board, and then you can break them off and use them in other places. And what this piece of hardware does is, on one side, it talks to the processor. Very deeply. And has a special relationship with the processor. And on the other side, it talks to your computer and pretends that it is running locally so that you can GDB it. And I'm using quotes here.

Quote, GDB it. GDB the executable that's running on your processor. So it's pretending to provide an interface. Usually there's a little piece of software in between, this little proxy that talks to the hardware and then that talks to GDB called GDB server. Right. That does that translation. And that piece of hardware is conveying all the stuff that normally gdb would be able to see like where the program counter is uh what is this variable equal to where setting break points or

that kind of thing i actually want to say that again i mean you said it fine but i want to say it again just because it's so important you have gdb and when you are using it for cross-development, you have a GDB server, and this server talks to your programmer hardware. It usually comes from your programmer hardware vendor, which is Jlink or STlink or OpenOCD. And this GDB server is from them. You can't use an ST-Link GDB server with an OpenOCD programmer. And you might be able to use an OpenOCD GDB server with a J-Link programmer, but it would be better if you used the native one. Usually you don't have to think about these things. You just install the tools that come with your programmer.

Understanding that there is a server. Yeah, yeah. No, that's important because it can be confusing. Yeah, so you have GDB, and then you have this GDB server that talks to your hardware. You might consider thinking of it as like an overblown USB driver, but since you usually have to type it

and make it start yourself, you can't just ignore it like you do with USB drivers. There's a lot of additional complexity too because all this stuff has to know what your processor is exactly. Right. Your programmer needs to know what your processor is exactly. Right. Your programmer needs to know what your processor is exactly. Your GDB server needs to know what your processor exactly is.

Your GDB doesn't really. Right. Well, GDB needs to be the right architecture. Right. It needs to be ARM or MIPS or something. You might be running the ARM GDB on your Intel thing, even though it's running Intel. The GDB is compiled for Intel, but it knows about the ARM GDB on your Intel thing, even though it's running Intel. The GDB is compiled for Intel, but it knows about the ARM architecture and how to debug it.

Right. GDB is running on your computer, which in this case we're going to say is Intel, because if we use Apple ARM, then it gets all super confusing. So we're going to say it's Intel. It's still probably a different ARM. It is a different ARM. So GDB runs on your computer. It's compiled for your arm. So GDB runs on your computer. It's compiled for your computer. GDB server runs on your computer.

It's compiled for your computer. These know how to talk to your processor. Yeah. And what it's saying. And the GDB that you're using is not just GDB. It's ARM GDB because it is doing this cross compiler talking thing. Or MIPS

or whatever you're happy to be. MIPS. Anybody use MIPS anymore? I said MIPS a second

ago. Or RISC-V or whatever. And the ARM GDB knows how to read your executable

and associated debug files. Ah, so that's the important key. Remember my first question. How does it fit? It doesn't. Your compiler says, oh, here's the little tiny itty-bitty thing you wanted

in a.hex file and here's a giant thing that has all the information in it in a.elf file. We usually call those symbols, debug symbols. Debug symbols. And the.elf file has the executable and the debug symbols. A.out file doesn't have the debug symbols. A.hex doesn't. SREC doesn't. BIN doesn't. So what GDB is doing is saying, well, that thing over there that's running on that hardware that I'm getting info about, it doesn't know anything about what these addresses mean.

But I have a reference table over here on this big computer, and I can smash them both together and tell you what source line this came from. And when the processor says, I'm at address 8,312, the GDB server tells GDB, the processor's here, and then GDB says, oh, I'm just going to look that up in my table here. Oh, you are at main, the fifth line down.

And then depending on if you're in VS Code or something else that's using GDB server or GDB, it will highlight that line. STcubeIDE uses GDB underneath. It's funny. I didn't used to have to

I guess maybe because I always used ST-Link or I always used an IDE like IAR plus a debugger that was supported by IAR. So I didn't have to worry so much about the server. It just happened. But these days, not only do I think about the server, I sometimes have to think about

the debugger itself because they know so many processors, but then they almost never know the latest processor. So if you're working on cutting edge things, your debugger may not know everything about your processor and either you'll have to make a file, usually an SVD file that describes the processor, or you'll have to do something specific with the processor and you can say, hey GDB, I want to talk to the programmer.

This next statement, it's not for you. And so you type monitor reset or monres and suddenly you are talking to the debugger itself and not to GDB. So it is really complicated. It didn't used to feel this complicated because we were using pay-for-IDEs, which only supported one program. Oh, really? Let me tell you a story about the 1990s.

How do you think GDB worked on a router from my computer at Cisco on my desk that was sitting in a data center on a couple floors down? Like with GDB servers and all this? Really? Yep, over TCP IP.

Or serial. You could do serial too, but yeah, there was a J-Link. There was not J-Link. There was a GDB and you would put in the address. What kind of programmer did it have? What was the hardware? Hardware was a MIPS computer. It was running an operating system.

And it had, it was set. I don't remember exactly how the device side worked, but it had enough code that could run a server on itself, a shim layer, to talk, to speak whatever GDB spoke over TCP IP, and you would proxy in, and you could step through stuff, yeah. And that's how the GDB servers kind of work now. For Android, too. For Android, if you're debugging on Android and you want a GDB, you hook the phone up to your thing, and then it does, I don't remember what, either USB or TCP IP to that. Because in that case, you're debugging an application that's running on it so the operating system can do the shim layer. But yeah, there's all kinds of ways to connect GDB to things.

Well, I think that's why we call it the GDB server now. It's because it used to actually be a server on the programmer device. Maybe, yeah. And we, I mean, the old JTAGs used to come in Ethernet variants before they came in USB variants. Well, they still, the expensive ones still in Ethernet variants before they came in USB variants. Well, they still... A lot of them still have Ethernet. The expensive ones still have Ethernet,

which is nice, because it means you can stick them on a... You can stick it on a network with a device. But I don't know if it runs the GDB server or if it runs something that talks to the GDB server. I bet the latter. I bet there's like a GDB server. The GDB server used to be something that ran somewhere else.

Yeah, and I don't know still how, like, I know there's ways to debug the Linux kernel remotely and stuff like that. So there's still other weird ways to connect and do GDB. Oh, there's lots of GDB remote options. And that's another thing, setting up your GDB. Oh, there's lots of GDB remote options. And that's another thing setting up your GDB server,

sometimes you have to tell it where its remote is, even if it's running on the same computer. Because you have this

remote debugging thing, imagine that the GDB server used to run somewhere else

and we just kept the terminology. Maybe. All right. As my drum instructor would say, did we do a thing? We did, in fact, do a thing. We didn't finish this question, though.

Oh, I'm sorry. What would you tell a recent EE or CS grad who has never used a debugger on an embedded system before? Well, now's your chance to never do it. No, I would find a nice tutorial somewhere on a dev board kind of thing. And in VS Code or a nice IDE, try it it out i think there are plenty of them we'll probably find one and put them in the show notes um but with the with vs code or the stm cube is probably the easiest to get started with um you could set up a simple program. It's really easy with an integrated IDE. They make it easy.

Once you've got stuff connected, you build your little application, even if it's blinky, and you set run and push play or stop, and it's all in in there and you don't really think about gdb so much i think this is the way to go if you ran stm32 cube with a nucleo board nucleo board has a debugger and st link on the board debugging hardware debugging hardware on the board thank Thank you. The JTAG programmer on the board, even though JTAG isn't the thing. And so the IDE on your computer, the ST-Q IDE, already knows what kind of processor and programmer you have because processor and hardware programmer on the board because it it's in their list and so it can configure the gdb server without telling you

it runs the gdb server when you put gdb when you when you debug you never really see gdb or the gdb server unless you look for them in that that bottom tab where it talks about the debugger or the debugger console. And so if I was talking to a new college grad who hadn't used cross compilers or cross debuggers before, I would hide all of the details because they're awful. Yeah, and I started out with command line GDB. GDB, if you just run it on your desktop in a terminal, it comes up and

it's a terminal program. It's text-based and you type commands to it and stuff happens and there's no graphical element. It's from, I think, the 80s or earlier and there were predecessors of GDB. There were other kinds of debuggers or other debuggers that are very similar that were terminal-based, and then GDB is still terminal-based. And you can use it that way, and I

know how to use it that way, and I kind of like it sometimes. But that's not how I would recommend most people use GDB, and it's probably not actually the right way for most people to use GDB. Graphical source level debugging is much more friendly. It really is much more friendly. Okay, that does complete that question. Okay. The next one is what exactly are the compiler and the linker? But let's not talk about that because the Nandatetris episode is coming. The compiler takes your source code in some language and turns it into... A different language, and then... And then another language, and then maybe some more languages that you don't see and that nobody even knows what they are. And then eventually it turns it into an assembly language. And then the assembler, which nobody ever talks about either,

takes the assembly language and turns it into an object file, which has the machine instructions. And then the linker takes your object file and hooks it up to all the other crap that you didn't write. Object file crap. Library crap.

And puts it in the right memory locations and stuff. They're done. Everyone forgets about the assembler. Yeah, you know, I did too. Yeah. Yeah. Thank you for joining us today. We hope we have amused you

and maybe given you something to think about, whether it's code reviews, origami, or GDB. Thank you to Memfault for sponsoring the show. And if you have any comments or questions or gosh, I don't know, things you need to tell us or GAMI articles, the address is show at embedded.fm or hit the contact link at embedded.fm. And now some Winnie the Pooh.

Rabbit has a plan to capture baby Roo. Number one, general remarks. Kanga runs faster than any of us, even me. Two, more general remarks. Kanga never takes her eye off Baby Roo except when he's safely buttoned up in her pocket. 3. Therefore. If we are to capture Baby Roo, we must get a long start because Kanga runs faster than any of us, even me, C1. 4. A thought If Roo had jumped out of Kanga's pocket and Piglet had jumped in Kanga wouldn't know the difference because Piglet is a very small animal 5. Like Roo 6. But Kanga would have to be looking the other way first

so as not to see Piglet jumping in 7. See to 8. Another thought But if Pooh was talking to her very excitedly, she might look the other way for a moment. Nine. And then I could quickly run away with Rue. Ten. Quickly. Eleven. And Kanga wouldn't know the difference until afterwards.