Embedded - 484: Collecting My Unhelpful Badge

Episode Date: September 5, 2024

Chris and Elecia talk to each other about setting aside memory in a linker file, printing using your debugger, looking around a new code base, pointers as optimization, choosing processors, skill trees and merit badges. Elecia’s Creating Chaos and Hard Faults talk and slides. STM32 Application Note AN4989 microcontroller debug toolbox includes semihosting. Memfault’s Interrupt blog has a good Semihosting post. Elecia and Steph’s Embedded Skills Tree. A far more detailed one pointed out by a listener: A comprehensive roadmap for aspiring Embedded Systems Engineers, featuring a curated list of learning resources.  The most influential book Elecia has never read is You Can Do It!: The Merit Badge Handbook for Grown-Up Girls.  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 and I am here with Christopher White and we are going to chat about the things we chat about. The things? The things. Okay. First up, we had a guest recently, Colleen Lewis, and we talked about pointers and stuffed animals. So I have some follow-up emails about that. Okay, cool.

First of all, the stuffed animals. Nathan, who has been on the show, said that he wanted to stock his physics classroom with stuffed animals based on the show, but he suggested that they have good names like Sir Isaac Newton and Albert Einstein and Stephen Hawking. So I guess you need specialized stuffed animals for these. Okay. Tom also had a good note on that one, on pointers. Did you see that one? I think so, but you have to remind me. Tom said, my problem with pointers

was not so much understanding them as figuring out why they were used so often. Oh, yes, yes, yes. It took me a while to realize they're used so much because C in 1979 was such a dumb language. Alright. The first hint was scan F. It would have

been easier if someone in 1979 had confessed, these pointers are terrible and will make endless trouble, but we're going all in and we'll be using them everywhere, whether we need them or not, so get used to it. I just think people maybe, I don't know. I remember computers in

1979 were not so great overall. In hindsight, yes, sure. Tom continues, pointers are like go-to statements, but for memory. Forget reasoning about code. Device drivers have too much I.O. preventing optimization anyway. If you want optimized number crunching, stick with Fortran. Uh-huh. I actually kind of liked this because it is true that we don't explain that we use pointers because of optimization.

Well, I mean, C was supposed to be a low-level language that was just a step up over assembly. There were many higher-level languages that people... Already, yes. Already, yeah. Pascal and I think Modula 2 existed around that time, and Fortran, of course, which has been around for a long time. And I don't know what the state of Ada was. I think that came a little later. But, you know, there were a lot of higher-level languages. C was designed to be a system-level programming language.

Correct me if I'm wrong, but that's my understanding of it. And so it came along with, you know, being pretty close to writing on top of assembly. And assembly, guess what, is all pointers all the time because it's all about addresses and things like that. So yeah, if there's anybody to fault, it's taking C and applying it in places maybe

it wasn't intended to because it was easy to learn to start with compared to i don't know have you been learning rust no i mean if you're taking the side that c is stupid then then you should be taking the side that rust is good, I guess. I don't know. I think C is definitely long in the tooth and is misapplied. I totally agree with that. But, yeah, I mean... It wasn't so much a denigration of C. I mean, okay, yes, the whole C was such a dumb language might have sounded like an insult,

but it was the idea that pointers are essentially go-to. All of C is essentially a go-to. It's, you know, it's a very unsafe, just abstraction on top of assembly as far as I'm concerned. I mean, yeah, C++ was supposed to be the evolution of that along, you know, from C. But C++99 still had all sorts of pointers. 99 was 25 years ago. Yes, but that's when I learned it, so it can't have changed much since then.

It's like complaining about C in 1990 in 2005 2005 yeah anyway yes i mean pointers are yes i'm agreement with most of that stuff except you know i think stuff languages and idioms and other things people there's a lot of momentum behind it, and momentum is hard to deal with compared to when you have the right argument. You might have the right argument, but the momentum of 5 million deployed applications makes it difficult to switch. You're talking about languages, and I'm still thinking about teaching pointers. And I think Tom's comment... Is don't teaching pointers. And I think Tom's comment... Don't teach pointers. Has made me realize that when I teach pointers, I need to make it very clear

that they are an optimization to avoid copying data. And that of themselves, they have no real intrinsic value. It's only understanding them is necessary to understand that optimization, which is super, super common. I partially agree. I think understanding how memory works is important. Yes. In a computer, and pointers are how memory works. But you could do that with variables and then build up to pointers

as an optimization against copying variables. Sure. Yeah, you could write C programs without pointers by copying a lot. Yeah. Okay, so that was the, I think that's what we talked about before. In my hard faults talk, which I put up a little while ago and gave at the... Some conference. Embedded online conference.

Sorry, I just realized that I may have passed their call for proposals date without submitting a proposal. So I'll have to look that up. Anyway. Hard faults talk. I mentioned setting aside memory for later use to put in a core dump or stack trace when you are in a hard fault. Yes.

How would you do that? I mean, those are fine words, but... I would usually set aside a section in the linker script and then define a struct that contains the stuff I want that points to that section. Is that the right answer? That's totally the right answer, yes. Okay, cool. Continue. That's it. That's the whole answer. That section of the memory should be in its own section in the linker script.

It should be part of RAM, but defined at the top as a separate memory section so that it doesn't move around. If you want to be fancy, you could do it in Flash if you have addressable Flash. You're in a hard fault. You don't want to be playing with Flash at that point. Okay, fine. The other thing is that you need it to not initialize. Yes, yes. And if you have a bootloader, you don't want the bootloader to have access to that memory so that it doesn't erase that memory through its stack or heap or zeroing of data. Okay. And so usually your no init

memory for this sort of thing is at the top of your RAM or at the bottom. Okay. Where top or bottom could mean the highest address or the lowest address. But you want it at a defined location. You're not going to let the linker figure out where to put it.

Right. Because you want to access it in your code and you need to be able to do the whole, hey, linker, fill in this variable address for me. Yeah. Okay. I bring that up because I was talking to someone implementing Memfault

and they needed some space set aside for Memfault which wouldn't get initialized. And so talking through how do you set up a linker file and how do you look at memory? That was the piece I thought was missing was, okay, you have 256K of memory. How are you allocating, and 512K of flash. How are you allocating each piece of this?

And if you're just looking at like three linker files to try to figure out where the bootloader is and where everything is, it gets confusing. So it's like, draw it out. Here, put it in Excel. It doesn't matter where you put it. Just make a list of what everything is and then put them in order

so you can see if anything's overlapping. You didn't do that part. No, but I'm not a linker script. Apologist? Yeah. I try not to go there if I can avoid it. But yes, if you've got, yeah, I mean, those are multiple builds, right? You've got a bootloader build, and they all may have different

or overlapping or conflicting linker scripts. You really don't want them to have a conflicting one. That's where it all goes back. Well, it depends, right? Maybe you're switching into one thing and it's going to take the memory that the bootloader was using for something else. True.

Thank you to Memfault for sponsoring this show. We appreciate their sponsorship and the work that they do. Memfault is a leading embedded device observability platform 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 time to 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.

From our embedded Slack, which some of these other questions have been from, how do you read code when you're just entering a code base? Do you have any tips or tools for that? I answered this. You did. Do you remember what your answer was? I said angrily. Yes. How do you read code when you're just entering a code base?

And his answer was angrily. Yeah. It greatly depends on the, well, it kind of depends on the reasoning that you're going into it. Right? Like, are you going in to fix, you've never seen this code based before, but you've got to fix a bug. Or, you've never seen this code based before, but now you own it. That one. Uh-huh. And you don't, you may have a hundred outstanding bugs, but you don't really understand those either. Right, yeah, yeah.

I mean, what I actually do? No, no, let's go with what you think other people should do first. Ideal case. I mean, it depends on what it's for. Do I have the right IDE, first of all? Do I have all the right tools? So you want to build it first? I don't know that I want to build it first,

but I want to see it the way that the person who wrote it saw it. And if they're not using VS Code? Use whatever they used. If there's a project structure. Oh, no, I would do that, but I would also have VS Code next to it. Sure, that's fine. But I want to see, like, if there's a layout or something that's only visible, you know, if it's totally flat a layout or something that's only visible.

If it's totally flat in VS Code, that's not helpful. But if it's something structured that's in a project file format, the word things are divided up. That makes it a little easier to navigate the first time. That makes me crazy. Because IDs do that and they don't think about it. Anyway, so yeah. And then you want to kind of get a sense for how things are organized. You can sometimes look at main, but it depends on how the project has been written. Sometimes main is just nothing. And it goes and does something else. Or if it's a C++ project, main will, you know, instantiate a single object and then nothing. You can't see where it starts. Well, an RTOS may just fire off a bunch of threads.

Yeah, exactly. And it does nothing. Yeah, so that's the other thing. If nobody's giving you any documentation, first of all, it's the red flag. Well, I do this with open source software sometimes. Yeah. Where I want to get an idea of what it is they're doing. But, yeah, like what you said, if it's an RTOS, then first, A, figure out, is this using an RTOS?

Because that's going to change how you approach it, right? You're going to look for something that defines the tasks. And then maybe you're going to write out, okay, here are the five tasks that I see. Here's the order they're launched. And then you can go look into those and see what they do. But I don't have a real prescription because it's different for every project. Like, every project is so different that you can't

really just say, here's a prescription for how to break this code down that's going to work every time. But I have a prescription here. Okay, alright, sorry. Although, I guess I did change it later and say the first step, the zeroth step, is to figure out what it is the software does.

Okay. Sure. But I would hope that... You know, if I started a new company, there are times that I don't know what the software is supposed to do. But you at least know what the product is supposed to do, or the thing, right? I know what the whole system is supposed to do, but I may not know what this is supposed to do. Alright, fair enough. Okay, so I have three

different strategies, and for me, I just switch back and forth between them as they become too frustrating. I tend to use VS Code because it's easy to search and follow paths and go up and down. But I agree with you that you need to build it. I never said you need to build it. Oh, that you need to be in the environment they are in. I do think you need to build it.

But you don't have to build it, but it sure makes it a lot easier. Anyway, treat the device as a black box. Or the firmware as a black box if you have the schematic. Make block diagrams for what must be there based on the peripherals and displays and the actuators and how it works. So basically... You're describing the system before looking at the code. Yeah. Okay.

And if you have a UI, make a little state machine, not necessarily the level of each character, but generally how it works. Isn't this just setting you up for disappointment, though? And it's funny because my next sentence here is, sketch out the idea how you would put it together. Now go see what you got wrong, was how I wrote it initially, and then I changed it. Now go see what you got right. All right. Glasses half full. Right. But yeah, you know, what should be there? Think about the system as it could be. Yeah. And I guess I do that, but I probably do it in my head. There's some value to actually sketching it out because it does give you the opportunity to think of more things. Yeah. I mean, I guess I usually

sketch it out as I go through the code, not before as a black box exercise. So, no, that's a good idea. Switching back and forth. Yeah, that's a good idea. No, I'm just thinking out loud about how I approach things. Yeah. Look at the file tree. Try to find interesting ones,

like the algorithms and sensors, and try to avoid standard hardware abstraction layers. Yes. Try to focus on the code your company has written or is otherwise product specific. It's easy to get lost. Don't go down the Zephyr tree. Don't look in there. Stay away from the Zephyr tree. And then the final one was go to main,

skim the initialization, and focus on the while loop. Walk through, ideally even with a debugger, but maybe just mentally, but walk through what the device does. And if it has threads, look at the loop in each thread. Again, initialization is really important, but if you want to understand the code, you're better off trying to figure out what the code

as a whole is doing. There were a lot of people who said that building is the actual first step, and I can see that because you do kind of want to be able to step through the code, but if you are new to a company, you don't always have all your tools ready. Yeah, or hardware

and stuff. Yeah. The number of times... It's hard for me to answer this because, and those are all good. That's much better than mine. It's hard for me to answer this because the number of times I've come in and had to own something has been just a couple, maybe three times. as opposed to coming into an established shipping thing and, like I said, fixing bugs or owning a small piece of it. And so having to understand all of it was probably a useful exercise that I should have done more often, but sometimes that wasn't even practical.

Like Cisco. I'm not going to understand the entire Cisco code base for a router because that's like understanding Microsoft Windows, level of complexity and volume. But for smaller things like a small embedded thing, that's more practical, where even if you're not responsible for everything, it's probably worth looking at everything.

But I remember one client we both worked on last year, or two years ago, sometime. I don't think I looked at all their code. Because I was, you know, they said, write these drivers. And so I hooked into what they had and wrote some drivers, but I never bothered to see how the whole system did everything. Yeah, I did some of that and then regretted it and then looked around and then kind of regretted that.

Well, it's all just regret. Well, it's about efficiency, too. Like, if you know you're not going to need to understand the entire system. And that depends on a well-architected system, too. Right, we trusted the architect for that. So if the system is not well-architected, then things that you might not think impact the part you're working on might have their tendrils in it, causing all kinds of problems. But if it's well architected, if it's using an RTOS and things are in tasks, and it's like, this is your task, and you communicate with these other tasks via messages, then you don't necessarily need to comprehend the whole thing. And when I did look around, I went to the architect and said, this seems odd. And he had great answers.

So I wasn't really disappointed. I just wanted more out of the system. Sure. Tom Anderson recommended profiling. That's something I don't do much. Because the long spots might be the most interesting part. Yeah, especially statistical profile that just tells you these are the functions that are getting called. The top 10 functions in the running system.

Those are the ones to pay attention to. Draw a block diagram, annotate the ones to pay attention to. Draw block diagram, annotate the hotspots from profiling. And there are tools, right? Aren't there tools that will kind of... Yeah, Benny suggested... Please don't say chat GPT. Source trail and source insight

for code review. Open GROK can index code bases. Actually, I don't even know what that means. I don't know. This was useful for large projects like the Linux kernel in Android. So that's large. Index, okay. That's another example.

Like, if you're going to work on Linux, don't comprehend Linux kernel. Hey, you can't. Well, I mean, you can comprehend the architecture of it and then focus on your piece. I don't know if that's true. Maybe. Depends on how high level you go. Yeah, yeah. Tom also suggests removing unreachable code, normalizing the file headers, reformatting with tools.

Now you're taking actions. Create an exquisitely detailed set of instructions for how to build. This is actions. This is not your first for detailed set of instructions for how to build this is this is actions this is not this is not your first foray and this is this is when you're well he does say that and he goes even to creating a release but then he says don't tell anyone what you did unless you want that to be your job yeah okay i don't well yeah build locally and start poking at things uh remove or fix the lies in the comments. Yeah, that is satisfying, Bailey.

These are things upon taking ownership that you want to change. That's all fine. It's funny because there are two things I think about with that question. There's our problem, which is we see a lot of codebases all the time. And our goal is to be as effective as possible and to not

try to get too far into what the client customer is doing because they've hired us for a job. Nobody's paying us to do that list of things that they just mentioned, which is why I push back on it. Because in my circumstance, if I were to go through a new client's code base and correct all their comments or remove all the reachable code or whatever, they would say, what are you doing? Why are you charging me for this? I didn't tell you to do this. So yeah.

But going through their code and creating a few documents and some block diagrams. Yeah, that's actually something I do often because clients tend to enjoy that. Okay, so what's next in our list? Okay, another quiz for you since you did very well on how to set aside memory. I got a B minus, but that's fine. Go ahead. What is semi-hosting and how do you set aside memory? I got a B minus, but that's fine. Go ahead. What is semi-hosting? And how do you set it up? Semi-hosting is where you need

to put a data center on a truck and drive it around because you're afraid that somebody's going to hack into it physically. So you put all your data center stuff on the truck. It was satellite uplinks and you drive it around the country in an unmarked truck. And then you have a roving car in case there are murder mysteries.

You can drive the car into the truck. And the car is AI. Chat GPT. You just ruined my writer for me. He was a cool AI. He didn't make dumb mistakes. He was a cool AI. He didn't make dumb mistakes. He had a cool British accent that instilled confidence and quiet determination. Semi-hosting is a hacky method of getting data in and out of your system if you are precluded from doing so by uart or a network

or bluetooth or blinking lights or screeching ultrasonic tones uh and all you've got the ultrasonic tones how did i forget all you've got is swd or jtiger one you know your programmer and what sw what semi-hosting does as far as understand it, I've only set it up a couple of times, is it puts basically breakpoints in your code, and the debugger says, hey, that's a breakpoint that says this. And then you can send data out during that breakpoint, and then it resumes communication. So basically, you can set up up your code and you can replace printf and stuff with the semi-hosted version that outputs, that does this breakpoint dance with some assembly,

and then spits the stuff out to your programmer, and your programmer outputs it in your debug session. So like your GDB session. Yeah, and then you can do some more sophisticated things like get access to files and stuff like that. If you want to get really fancy, you can make a whole console interface that way. Because it goes both ways. Yeah.

It's kind of like a UART in your JTAG or UART in your programmer. But it does have this problem that you're doing a lot of breakpoints. And it can be slow for that reason. One way to use it is to put a bunch of data into a big block of RAM, and then after some event or some command, you dump all of that, because it does have such an impact on your loop. Yeah. But it's handy in a pinch, especially if you've got

sometimes you have only one UART and you need to do two things or you're debugging the UART code or something's just not working and you're like, that was one that was useful for me. It was a couple times where I was actually

setting up UART and making a console happen and things weren't working right and I couldn't figure out what was useful to... There were other reasons I couldn't just breakpoint and debug there. I needed some output, but you can do it that way. So I set it up in STM32, Q by DE. I had to use OpenOCD because it wasn't part of the ST-Link GDB implementation. Oh, really? And it was actually really ugly because I had to make code changes and I had to make

configuration changes to the debugger. But because I knew that the speed was important, I ended up making a whole other configuration for each. Oh, okay. And it was just kind of awful. And going back and forth was... For just printf, you can kind of... Usually, when I'm doing stuff, I have a bunch of debug macros defined. Yeah.

And then you can swap the implementation with ifdef. That's... But you still need to... Yeah. But you still need to, yeah. This project had gone from a printf debug on an Arduino to an STM32. And the client really didn't, had never heard of semi-hosting, had put in a USB port that they didn't use and didn't realize that they would have been much happier if they'd put in a UART

port and just used an FTDI cable. Oh, yeah. Yeah. And so any printf was like a good thing. Of course, then they said, can you make it run faster, which is the code that's waiting for me upstairs, which I say, not if you want new lines because STM32 IDE and blah, blah, blah. But as part of this, I found an application note from ST, the microcontroller debug toolbox. And it talks about development tools like ST-Link probes and other debugger probes.

And some of their other IDEs. But also it talks about this semi-hosting and printf via UR, which is one we usually use. Printf via SWO SWV, which is kind of the same, but not quite. Okay. It seemed to use fewer interrupts. Okay. But still used the SWD lines.

It felt like it was kind of like sniffing your debugger. Sure. Which, I mean, fine. Anyway, I'll link that because it was kind of interesting to have a microcontroller vendor have this application note on some debug tools. And it was kind of funny that I needed to explain semi-hosting multiple times this week. It's kind of like there were bootloaders and I had a whole bunch of people to talk to about that. And then last week it was semi-hosting. Maybe this week is about linker files, because I like linker files.

I don't. I'm finding that I like being able to explain them. Yeah, I don't like their format. I think they're not... Oh, no, I mean it's a language that is worse than C. Human readable or understandable, no. I mean, it's a language that is worse than C. Human readable or understandable. Okay. So from Sayhill, there's this comment. Maybe this is just relevant to my current situation, but I'm curious at your thoughts on master's degrees for embedded software and how you recommend people build up their skills tree.

And there's some discussion of the skills tree I put together with Maker Queen Steph, which is just a list of embedded skills with cute little icons. I think there are only a couple of spelling errors still. And do you have any thoughts on how do you build up your skills in Embedded? This is kind of a hard question because it's like, well, first you go back to 1990-something. Yeah, I mean applying to myself, that's not going to be useful for anybody. The original question was a master's degree? Sure, let's go with that.

I don't know. it's kind of like phd department in physics and then us finding out that all of the phd people in physics we knew were software engineers i just this is gonna sound weird but i don't know what a master's in embedded development would look like like a master's degree it's not quite a PhD, of course, but you're still doing research. I guess you can do a project. I don't know. I just don't think of master's degrees

as like industry. I guess they are. I don't know. You have a master's degree. I have a master's, but not in computers. In physics. Yeah. So it's not really applicable

or comparable. I mean, if you Yeah. So it's not really applicable or comparable. I mean, if you want to, it's certainly valuable from an employer's standpoint to see that. I think you can pick up skills doing that, certainly, especially if you pick a research project that, you know, you do your thesis on something that's going to force you to learn some things and do some development on your own. I just don't know what a curriculum, a master's curriculum in like embedded development would be. Like a lot of double E stuff. I could see that. I mean, it's only going to be a one or two year program. It's not going to be CS stuff because that's wildly not applicable most of the time. Depends on what your original degree was in.

If your original degree was EE, then CS stuff makes sense. If your original degree was CS, then... Sort of, but I still think most of the CS stuff is not applicable. You don't think so? So many times I look at code and I'm like, this could be solved with data abstraction. Yeah, but, yeah, I don't know. I'm probably a bad person to answer this.

I'm thinking about the CS courses that the CS department taught when we were there. And they're not applicable partly because they're out of date. My AI class spent so long on Boolean logic. I got so good at just DeMorgan's law and everything that I could use it in the cafeteria when people were making bad arguments. A lot of the teaching was in Scheme or Lisp or C++, which was newish at that time. There was no C.

All the C I learned, I learned working for the CS department writing utilities. Yeah. So, I mean mean that's not uh so I don't know what I would have to like to answer this question I would have to look and see what what a modern I don't even know what I guess it's a master's in computer science with a focus on embedded I don't know what that looks like so I have to see what they were teaching them I mean a master's in robotics would be fine yeah Yeah, yeah, I mean, that'd be fine.

But that's going to be a lot of EE and motion control. I guess I would say... Motion control or navigation systems? I would say, yeah, it's going to be an EE-heavy thing where you're kind of on the edge and learning how to interface with physical systems or other things. I wouldn't go in and get a master's degree in, like, CS and focus on AI or any of the more theoretical stuff.

I don't know because there's so much inference we do now that having an AI... Yeah, but embedded developers aren't going to do anything except take a model from somebody down the street and stick it on an NPU. And yet employers would be thrilled to get an AI-trained embedded systems engineer. I don't know why, I just

know that for a limited time... Well, yeah, if you're trying to game your resume, that's a separate issue from trying to learn skills. I'm very muddled about this because I don't actually have a good sense for what that degree would entail. And a master's degree is supposed

to be two years. So figure what you can do in two years of intensive study. And is that the right use of your time? I don't think it's a bad use. It's not a bad use, but it's expensive. There's opportunity cost because you're not getting paid to work. That's two years of prime employment ladder climbing slash earning. But it may work out later because a master's degree is slightly more valuable, but not hugely more valuable. I have not found that to be particularly true. Yeah, because, yeah, okay. I don't know.

Yeah, I am. Yeah, it's not a satisfying answer. I haven't found it to be anti-true. I mean, I haven't found it to be that a master's degree is less useful than being in industry for those two years. Really? According to, I mean, okay. Just a lot of times I've been asked, I've seen job things that want master's degrees. Okay. And like for development jobs? Yeah.

But also for higher level IC and architecture jobs. Okay, but that's that is someplace, yes. If you're doing digital design, you should have probably an advanced degree. No, IC and architecture embedded software jobs.

Designing ICs? No, no, I'm in architecture embedded software jobs. Designing ICs? No, no, I'm sorry. Individual contributor. I'm so sorry. I've been looking at hiring stuff and got into the jargon. Sorry. Yeah, so yes, of course. I don't know.

I haven't been looking that much, but I... Individual contributor as like tech lead or engineer beyond developer. But are they looking for... Yeah, okay. Just masters. It wasn't even like masters in our degree, in our area of application. Yeah. I don't know.

Okay, so... Just don't do what I did and take seven years. You were working for at least half that time. Working for probably 75 or 80% of that time. And you chose a field that you hated, so that was unclear. Didn't hate it while I was doing it. I hated it before.

I enjoyed it. Peter asked about how to move up the skills tree if you get stuck. And my answer to that is jump to another branch. I mean, it's not a ladder, it's a tree. So if you're stuck here, just go around. Especially since, yeah, as an analogy for other things,

like when you get stuck practicing an instrument or something, the common advice is to stop on what you're doing and do something else um and then come back to that because sometimes you just need a break yeah sometimes you need a different perspective different perspective or insight you find a new tool and sometimes the thing you were working on isn't that useful that you're stuck on um so yeah um peter also asked if we had thoughts and speculations about the new rp 2350 no not really i mean i've seen it read about it i think there's some interesting parts on it my thoughts and speculation are all about how their documentation is going to go from the best documentation ever to the same as everyone else's.

Why? Just because they have too many variants? The variants are very far apart. They're named closely. Well, it depends on... And they're going to want to put the same API, but it's not going to fit exactly the same. Maybe not. And so you're going to get good documentation,

and then you're going to end up having something that doesn't quite work for your version of it. But, I mean, this is product proliferation. You have one product. You can do a really, really good job explaining it. Once you have two, you're not going to put twice as much effort into it. Yeah, but I don't know that they're going to continue maintaining all of them all the time. I think the first one is worth maintaining

at least for a good long time. I don't feel like this was a replacement. It's much bigger. Yeah. All right. Yeah, I mean, I don't know. It has some interesting things. I think it comes down to, do you need more power?

Do you want to play with RISC-V? And do you need that fancy serial communications thing that can do... The whole FPGA thing? DVI. No, no, no. They have a new interface that's high-speed serial that you can do things like high-speed video and other stuff. I don't know. Is there an FPGA block, too?

That high-speed serial thing. Has some programmability. Has some, yeah. Because they have their whole PIO thing, and that's the same. Well, that's one of the things that I'm talking about, is going to want to have the same API, because people are going to think those are similar, but they're going to behave so drastically different.

Maybe. The same API is going to make it worse instead of better. I don't know. I mean, that stuff is not... That's a peripheral. That's not part of the... So they could probably have just taken that same peripheral. No, no.

The 2350s is huge and massive instead of... Oh, the PIO stuff? Well, the high-speed... That's different. That's a new peripheral. Okay. The PIO stuff is the programmable IOs. You had a little C language, assembly language thing. You could make it

write UARTs and stuff in that. I think that's the same, but I don't know. Maybe they changed it. Okay. Oh, I have those two in the wrong order. I wasn't sure if we covered this one last time you and I talked. Simon said they hear complaints like the microcontroller was chosen without any consultation with the firmware team. And the question is, how should EEs or component selectors go about choosing parts if they don't have immediate access to or the ability to question

the firmware team? Are there obvious things to avoid like cursed IDEs, zombie docs after a corporate merger that no longer work, or weird peripherals that are easy to spot from a distance given you probably don't have time to test drive every part under consideration. It's funny, I was going to read this as, are there obvious things to avoid like cursed IDEs? MP Lab. Zombie docs with corporate merger that no longer work. Atmo.

I don't think we've answered this. Yeah. MP Lab. I just came up this week and, oh, man. MP Lab. I just came up this week and, oh man, MP Lab. I'm going to give a high level answer that I think works for most cases. Assuming you have a choice of parts that fit your application, find the one with the largest community online talking about it. I had that microchip madness. Yeah. And one of the criteria was search for the part number

and whoever had the most hits wins as one of the... And make sure that they're not, you know, this part lights on fire and there's a million complaints about the part light on fire. But, you know, this part lights on fire, and there's a million complaints about the part lighting on fire, but if you're choosing a part, and there's not a lot of communication about it, there's not

an active forum, or it's very new, and not a lot of people have experience with it, you're going to have a bad time. Your firmware engineers are going to have a bad time. And that's a red flag. If they want you to sign an NDA to even look at the data sheet, your firmware engineers are likely to hate you.

Because that means they can't talk about it. And that's not to say you can't choose that part, but there has to be a really good reason. Like, this is the only part that fits our application and fits our power profile and does the thing we want to do. And so you're going to have to think about it. But I've seen double E's just pick stuff because that works and that's it with no consideration for development afterward. And then it's a real problem where, you know, people come in and it's, well, I've used this PIC for 34 years, and it's worked for me for 34 years. But it's also completely out of date, and people want modern features or something like that.

Oh, I wanted to drive a high-resolution display and do Bluetooth. I'm like, not with a PIC-16, you're not. But that's a wild example. So I think having an active community is good because your firmware engineers are going to want to find information about it. All these parts are different. They all have quirks. They all work poorly in some corners. And so being able to talk with other engineers, you know, without revealing the company secrets or whatever about what this is happening or communicate with the company's engineers is really important.

If they have a stellar support department and you can somehow find that out, that can replace that. But it's hard though. It's so much easier to go read what other people's problems are than to try to formulate your whole thing and then try to get a minimal code set. And the other thing I will say along those lines is, well, it's two things. They're kind of related. How much example code is out there?

Right, search for this part on Git. Yeah. How much example code is out there? On GitHub, sorry. And is it well implemented in Zephyr? And if it is, run. No, wait, no, no, Zephyr's good. Zephyr's good.

That gives you an indication how popular it is and what support is, whether people are going to be able to find how to use it and issues like that. But I think the hardest times I've had is where it's a weird chip. And that came up at Fitbit, where we were using an ARM, you know, a Cortex, but it was from a strange manufacturer. Okay, not a... It's been from a manufacturer you've all heard of. But not for making chips. But not for making chips. And it had some funky peripherals.

And one of the funky peripherals was a 2D graphics engine, which was pretty cool and unusual. At least at the time for a Cortex-M4 SoC. And it could do a lot of stuff. But everything to figure out how that worked was in communication under NDA with those folks. Was it 24-hour turnaround time? Longer, sometimes weeks. Or in their documentation, which was challenging. And so that was, you know, took probably 10 times as long to do things than if we'd chosen something else

that was maybe a little less capable and rolled our own solution for a few things. Okay, so let me summarize some of these. We don't want NDAs for the documentation because that means that we can't talk to other people about it and there's a good chance we want to talk to other people about it we want a community where possible and that can be somewhat

determined by looking at just how large the community is you don't need to dig into how good it is and we want not strange things. And that not strange things, you can find a good community. Like, let's say ST, for example, just to beat on ST. They have a huge

forum. Huge! And they have a lot of people talking all the time about all their parts. But you could still pick a weird ST part that nobody's talking about on their forum. Right? And they get into trouble. So, I mean, you have to use a little care there and not just say, oh, nobody ever got fired for choosing ST, but then choose the STM32XL378-core underscore MPMPM44

that's not even a Cortex chip. It's got an A-core in there for some reason and only runs Linux. A-Cores. Yeah. And, I mean, I really am not happy with MPLAB. Even though you can export everything, use GCC and VS Code, sometimes you want to go back and make sure that you're working within the constraints of the vendor.

And wow, they have made that very challenging and their, their documentation. I mean, it's like you can tell if this was written before Atmo was purchased or after, and before itmo was purchased or after. And before, it makes a lot of sense. It just doesn't apply to your chip.

And after, it just... What? Why are you telling me this? What were some of the other questions? Posts? You had some other... Weird peripherals that are easy to spot from a distance. Yes.

Well, I don't know about weird peripherals. I mean, certainly if there's a peripheral that excites you, that always makes me nervous. Like a GPU or a neural processing unit or an image processing block for cameras. All those things are generally... Oh, and USB. Careful with USB. USB is the worst.

All those things are generally IP that the company either bought and integrated. And doesn't really support. They don't really understand it very well. Or there's going to be less example code. It's going to be just stuff people aren't talking about. But of course, if you need that stuff, you you need that stuff and you have to deal with it do you need it on the chip or can you buy a specialized chip that will go between you and whatever and not need to have is there another solution um and that's the thing is sometimes you get

these chips that solve all your problems and that often pushes all of your problems to the firmware. It's caused all my problems. Because the Homer car of chips might have all of these things, but they might be just not as good as if you'd piece together a system from a multi-chip solution. That's, I guess, the way to say that. I mean, yeah. It's hard. It's hard. And I know at double E's get mad every time the firmware says why did you choose this and some some high percent of the time it's it's a situation i'm talking

about where firmware didn't exist they come in and stuff's already done and you know it's a it's a it's just a silly choice of chip not not it wasn't even a chip like we need this it's like well this is what i've used in the past it's fine kind of so that's a different situation then i can't work with this it's that this wasn't the best choice oh right no this isn't the more modern choice that gives you lower power or a better bluetooth stack or you know access to zephyr or whatever it's just this chip chose this weird old chip because he used it before, and that's a completely different situation.

So yeah, definitely look around and see what's current, I would say, too. And maybe consider listing your needed features in your system because, again, some of your features can go on to your microcontroller but might also be better in a separate chip. Like if you need high-speed ADCs, is that going to be part of your microcontroller or not? In the beginning, it doesn't matter. It can go either way.

Now, if you're pressed for cost or power or space. Or, well, I mean, then there's low noise. Or low noise or location where the sensors are. Yeah. There's all kinds of reasons you'd get pushed one way or another. But choose the hardest parts of your system to design around first. In the end, how good the UART driver is in the hardware abstraction layer does not matter. Right. Right.

Yeah. It matters, you know, if you truly need high-speed USB, don't get a chip that has never done high-speed USB. Yeah. Okay. Anyway, I hope that answers your question, Simon, or gets us fired from all of our contracts. One of the two. All the contracts I referred to are in the past, so. Okay.

They can, like, fire me in the past. Retroactively? Yeah, they're retroactively fired. Okay, this is, okay, well, we have Guy Randy's typical question. I recall an episode where you talked about installing an antenna to talk to your dad. How is that going? No progress at this time. I recall that about four months ago, three months ago,

you started a six-month intensive drum course. Yes, which is actually a year long. It's going well. It's very challenging. It's breaking down my understanding of my fundamentals of playing. It's embarrassing me that some of the things I can't do, it's, you know. But you have noticed actual progress in some areas. I think so. It's hard because I'm focused on exercises and not playing stuff.

But yeah, I'm trying to practice an hour to an hour and a half a day, five or six times a week, which is a lot for a person of my age and joints. So yeah, no, it's good. Yeah, it's a good course. And it's, you know, it's about some fundamentals of stuff that when you try to learn on your own, it's hard. There's a lot of books and things, but it helps to have an instructor. And this course has an instructor who I can meet with a couple times a week and ask questions of, who reviews video of my practicing and gives me feedback. And who cares about instruction as opposed to is a and trying to find the things that have the greatest impact and focus on those and not maybe the more common exercises and things that happen in drumming that people sit at with a pad for 15 hours and don't feel much progress. So he's kind of focused on

what things, how can we break down to exercises that have the most impact in the shortest amount of time? And a lot of those are focused on things like proper timekeeping, dynamics, and just clean playing and stuff like that. So they're very hard, and some of them, you know, I've spent weeks on to get anywhere. But that's stuff I wouldn't have done without at least an instructor online occasionally checking in and saying, you know, that looks fine or this doesn't. Because I would give up because these are so painful and challenging. And you have people around you who are going through some of the same. Yeah, there's other students who I can talk to. And you're not all in the same chapter all the time, but you do get to see what their exercises look like.

They're all variants of things advanced, so we all know what we're talking about. But yeah, the ham radio stuff, no. My dad got COVID back in April, and that kind of slowed things down a little bit. He's doing okay now. Yeah, he's trying to figure out an antenna outside he doesn't he needs a better antenna than he had which means putting one up outside but there's he lives in a place where lightning is actually a thing a lot so that makes makes the whole antenna thing a lot more complicated and from a safety perspective so it's kind of a pain

i'm trying to keep up with morse code by putting myself to sleep by doing the alphabet in my head but i probably need to get back onto learning morse code better do you just go through the alphabet or do you choose things to spell i choose both that's how i got better at the international phonetic alphabetphabet. I would spell things from my day. Okay. Talking about these things, do you ever feel like you're collecting badges? No.

Okay. Sorry. For like... Advanced drum play. I mean, I was an actual Boy Scout and collected badges. Were you? Yeah. I never knew. Yeah.

How far did you get? Not far. Oh. I was what they called the Weeblos. Weeblos. Yeah, they were like the one below Boy Scout. Weeblos, you push them and they don't fall down? So I think it goes Weeblos and then Boy Scouts and then Eagle Scouts or whatever.

Yeah. It was a small troop and then Eagle Scouts or whatever. Yeah. It was a small troop, and we didn't do very much. Did you get any badges? I think so. I don't remember what they were for. So this had a huge impact on your life? No. But, you know, it didn't inspire me to continue collecting

or making up fake badges for myself, no. I didn't know what badge I would give for, you can't just say advanced drumming. First of all, I'm not advanced. Second of all. Okay, drumming 220 words per minute. Wait, no,

that's two different badges. That's Morse code. 220 words per minute for Morse code would be really impressive, actually. 220 beats per minute is only just could just be 220 beats per minute it's only just pretty fast 220 beats per minute is also extremely fast oh all right a normal pop song is like 100 to 120 beats per minute maybe up to 150 if there's a real bang you know kind of fast song 220 is double time well i mean you have the double double time. Well, I mean, you have the double.

Double time, not double. I am not being helpful. I'm collecting my unhelpful badge. I already have a whole collection, but I'm hoping for the advanced version. Will you kill that moth? No. Oh.

Oh, there it is. Sure. Scintillating podcasting. Anyway, do we have anything else? Well, you were going to ask me about my collection of badges. I'm sorry. I'm sorry. I got distracted by the moth. Are you collecting any badges? It's funny. I saw a book many years ago about collecting badges and women, I don't know,

it was maybe the well-rounded woman's guide to badges in life. I don't know. What? The first part was okay. It just went down. But it was kind of a try-everything sort of book. And it was kind of ridiculous in that it gave you little badges. And honestly, I didn't buy the book. This is the book that has most influence in me that I have never purchased.

Okay. But I do, I mean, like, I think NaNoWriMo was part of that, that I did, not now NaNoWriMo, which is in so much trouble, but when I did NaNoWriMo many years ago, it was part of that. It was a, okay, yeah, I'm just going to try this to see how it works. Yeah. And so now I am working to collect my Have an Art Show badge. Okay. And so if anybody is in the Aptos area in November on a day when the Aptos library is open, you can see my art show.

Cool. Which is entirely self-sponsored, self-produced, self-installed. It's in somebody else's building, so I think it counts. It's in somebody else's building. It definitely counts. And if they hate it, they can ask me to remove it. And afterwards, I will collect a badge of my own making, probably out of origami. Okay. Should I say thank you and everything?

I think you should say thank you and everything. Yeah. Okay. Thank you to Christopher for co-hosting and producing. Okay. Thank you to Jojo the dog for being quiet and adorable and only trying to steal my soul with her eyes once. Thank Memphout for their support of this show. We really appreciate it. Thank you to our Patreon listener Slack group for their questions.

You can join the Slack group or just email questions. And, oh, you can join the Slack group by supporting us on Patreon under the support tab on the website, embedded.fm, which is where the show notes will be. And thank you for listening. And they can also go to coffee, ko-fi. Coffee. Coffee. It's also on a support thing online. And last time I read a lot because I wanted to finish the chapter.

So now we have a new chapter of Winnie the Pooh. Sorry. I have to switch glasses because old. Okay. Chapter 7. In which Kanga and Baby Roo come to the forest and Piglet has a bath.

Nobody seemed to know where they came from, but there they were in the forest, Kanga and Baby Roo. When Pooh asked Christopher Robin, How did they get here? Christopher Robin said, In the usual way, if you know what I mean, Pooh. And Pooh, who didn't, said, Oh. And then he nodded his head twice and said, In the usual way, if you know what I mean, Pooh. And Pooh, who didn't, said, Oh. And then he nodded his head twice and said, In the usual way, ah. Then he went to call upon his friend Piglet to see what he thought about it.

And at Piglet's house he found Rabbit, so they all talked about it together. What I don't like about it is this, said Rabbit. Here they are, you, pig, me, and suddenly, and Eeyore, said Pooh, and Eeyore, and then suddenly, and Owl, said Pooh, and Owl, and then all of a sudden, oh, and Eeyore, said Pooh. I was forgetting him. Here we are, said Rabbit, very slowly, all of us, and then suddenly we wake up one morning and what do we find we find a strange animal among us an animal of whom we have never heard before an animal who carries her family around in her pocket suppose i carried my family with me in my pocket

how many pockets what should i want 16 said piglet 17 isn't it said rabbit and one more for a handkerchief that's 18 18 pockets in one suit i don't have time there was a long and thoughtful silence and then poo who had been frowning very hard for some minutes said i make 15 what said rabbit 15 what 15 what your family what about them? Pooh rubbed his nose and said he thought the rabbit had been talking about his family. Did I? said Rabbit carelessly. Yes, you said. Never mind, Pooh, said Piglet impatiently.

The question is, what are we to do about Kanga? Oh, I see, said Pooh. The best way, said Rabbit, would be this. The best way would be to steal Baby Roo and hide him. And then when Kanga says, where's Baby Roo? We can say, aha. Aha, said Pooh, practicing. Aha. Aha. Of course, he went on. We could say, aha, even if we hadn't stolen Baby Roo. Pooh said rabbit kindly, you haven't any brain. I know, said Pooh humbly. We say, aha, so that Kanga knows we know where Baby Roo is. Aha means we'll tell you where Baby Roo is if you promise to go away from the forest and never come back. Now don't talk while I think. Pooh went into the corner and tried saying,

Aha! in that sort of voice. Sometimes it seemed to him that it did mean what Rabbit said, and sometimes it seemed that it didn't. I suppose it's just practice, he thought. I wonder if Kanga will have to practice too, so as to understand it.