Embedded - 524: This Isn't a Movie

Episode Date: April 16, 2026

Nathan Jones spoke with us about hardware security, motivation, conference talks, and writing. Nathan wrote an in-depth series of posts about the benefits of superloops vs RTOS: You Don't Need an RTOS (Part 1), Part 2, Part 3, and Part 4. He also wrote about How Hardware Gets Hacked (Part 1) and Part 2 which discusses the MITRE embedded CTF (Capture the Flag) challenge. See his EmbeddedRelated profile and Digikey profile. And Nathan's excellent Embedded for Everyone Github repo. Nathan recommends The Hardware Hacking Handbook by Jasper van Woudenberg and Colin O'Flynn. It is an excellent resource on embedded security. We spoke with Jasper about the book in 431: Becoming More of a Smurf and with Colin about the Chip Whisperer in 286: Twenty Cans of Gas. The European Cyber Resilience Act (CRA) has specific features that are required to be implemented by all devices that want the safety CE label. This is important for products shipping to Europe. If you are going to the Embedded Online Conference, you can get a discount with the code JONES100. Nathan will be giving a workshop on the Chip Whisperer Nano. (Recent guest Mark Omo will also be presenting: Security for the Rest of Us: What Matters and Where to Start.) Another conference for the security-minded is Hardwear.io which is in Santa Clara, CA, USA at the end of May and in Amsterdam in November. Last year, Nathan spoke about Exception Handling for EOC 2025 (video). Elecia mentioned her own Creating Chaos and Hard Faults from EOC 2024. The Embedded Slack book club is reading The Pragmatic Programmer, 20th Anniversary Edition. Well, some of us are just watching.  The quote came from Elizabeth Bear's Ancestral Night (White Space) which is part of a series with some neat mechanics around brain chemistry.  Transcript

Welcome to Embedded. I am Elyssia White here with Christopher White. This week we will be talking to Nathan Jones about teaching embedded systems, aratas, and potentially mental health. I don't really know because I didn't make an outline. Hi, Nathan. Welcome back to the show. What's up to you, too? It's so good to be here. Could you tell us about yourself as if we met at a real table at the Embedded Online conference, which has no real tables. Very confusing, but okay. Maybe virtual tables? Yeah, I'd say I'm just super stoked to be back at the conference. I get to present again this year on, I'm given a two-hour workshop on security stuff.

And I spent 15 years in the military, but sort of stumbled my way into embedded systems. And now I get to spend all my time writing articles for Digi-key and figuring out how to teach people cool stuff, which is just a blast. All right. And it appears I prepared no. Look, it's been a rough couple of weeks, folks. I'm sorry. This is what you're going to get.

This is going to be a great episode. Nathan's going to carry it. Lightning around is on vacation. Lighten around is on vacation, yes. Okay, but I've got a tip. Okay, go for it. Good, yeah. And again, I had to think long and hard about this,

but I settled on. The tip that everyone once a day should go out for a hot girl walk. Excuse me? I like to call it a hot dad walk. Okay. So, which for me, it's, I just, if you go outside, man, every time it's just beautiful, it's awesome. You step away from her screen for a bit. Do you like one little lap around your block and your mind is refreshed.

But for me, the other key is to pop in the earbuds and play a YouTube video where a guy did a bunch of funk covers of Lincoln Park. works greatest sits. And it's a amazing. I'm like dancing and sliding my way around my loop every time. It's just, it brings a joy. So part of it is, is the being silly part? Yeah. I think that part is the part I miss sometimes.

We have the dog. The dog, the dog adds like a plus three to silliness without us doing anything. How's your beagle doing? Oh, no, she's not a beagle. Oh, yeah, we're going to. Okay. So misconception. In my fault.

Zoe was a beagle. We got her decades ago. 2004. And she passed away what feels like recently, but probably isn't. And the new dog is not a beagle. The new dog is a pound pup. She might be a miniature snowser. I can't say that.

Miniature, schnauzer something. Yes. If we gave her a beagle. She looked hilarious. But when we got her, she was, it was pretty much don't have any loud noises or kids or pets or cats, dogs, dogs, butterflies, everything. She was just very scared all the time. But now she's almost a normal dog. No, we don't have a beagle anymore.

Beagles are awesome. but the thing that they say in the books about beagles is that they're merrily stubborn, which means they are having a good time, but they think you're stupid. And I can't tell you how many times my dog looked at me, how many times Zoe looked at me, and was just like, I don't understand why you're not rolling in this with me. You must be completely out of my mind. Why are you trying to stop me from this obviously fun thing I'm doing, eating poison mushrooms? Yes.

Jojo is while she's small like 12 pounds, she's on the Labrador scale. Okay. In terms of affection. She loves us. Like really, truly honestly, happy to have us home would do anything that she could in order to get belly scratches. She's just, she loves us. So we don't have a beagle anymore. We have a dog who actually likes us, although I loved the beagle so much.

and Jojo's great too. And anyway, dogs are great. It's a good way to walk around the neighborhood and say hello to everybody, too. As opposed to being that weird guy who walks around the neighborhood and is constantly, like, doing, like, weird hip things. Excuse me? Tip things. Hip things. He's sliding around to Lincoln Park's funky hits.

Got it, got it, got it, got it, got it, got it. We should probably move on to something else. Yes. You said you have been writing for Digiqi and also for Embedded Related. One of the things that I was wondering about was who is your audience when you're writing? And how do you decide that? You know, I don't go through a super rigorous process. I think my audience is, you know, me before I start the project that I just finished to be able to. explain it. It's hard because sometimes you need to explain early career things like what is a race condition. And sometimes you need to be more mindful of, well, we've already been doing this for 10

years. Let me give you the lowdown without having to use all the words. Because we're skipping to something more advanced. Because we're skipping to something pretty advanced. And I can't really tell you about this unless you already understand that mutexes are a solution to this problem, and I'm going to give you a different solution. Yeah, you know, and I try not to overthink it. I mean, I guess if the topic's a little niche, a little more niche, then I pay a little more attention to making sure there's a longer kind of on-ramp before we get to the meat of the article. And otherwise, I try to just sort of assume, you know, I'm going to help folks take one or two steps to kind of lead into it. And I'm playing around with things that I can do in the articles

using little drop downs or, you know, HTML will give you like some hover text or it's like, okay, I don't need to explain this term if, but, you know, there's clearly a link here. So if you hover over it or follow it to a footnote or something, it'll give you a little more depth for those folks that wanted or needed and to not necessarily clutter up things with folks that see that term and are like, yeah, I know what you're talking about. How often do you write something or are thinking about writing something and then find another article that explains it well enough? Oh, it's the classic PhD conundrum, right?

Like, you hope no one scoops you on your PhD thesis or something. I would say, I mean, that's, that's, that's, it's definitely a, uh, uh, a concern, a fear. unwarranted or not, you know, and I find lots of articles that I use for references that are where things are really well explained. But maybe it's just because I'm a little like on the spectrum or something, but like none of them usually hit exactly kind of the ordering that I want or the way it's, you know, things are explained or has enough pictures. So I always feel that, you know, the my contribution, you know, maybe I'm not necessarily often. anything novel, but I'm explaining it in a different way. And, you know, when I was an instructor

at West Point, that's valuable, right? Like, a lot of times as a student, you read the description of something in the textbook, and it's not inaccurate. It just doesn't quite make sense on the first past, and you need to hear someone explain it two or three or four other ways for that fourth one finally clicks, and you go, oh, okay, I think I get it. So I like to, I try to remind myself that, you know, even just sort of adding to the corpus of information is valuable. Maybe there's someone where none of that made sense, but they read mine and they go, oh, I finally get it. I think that's totally valid, and I find that myself reading about stuff that I want to see,

not just, oh, this person explained it differently, but sometimes it's a different voice, and I can, especially for a dry topic, like, if it's in, I don't know, Zephyr documentation voice, it's a lot harder for me to get through something than somebody who's writing, you know, walk through and well, here's what my experience was and throws in a little bit of, you know, humanity. Yeah. It's kind of easier to go through technical documents or technical tutorials and explanations that way. And I think at a minimum, there's nothing wrong with having people explain things a different way. That's why there's 50 different physics textbooks.

We don't just have one physics textbook that everybody says this is the physics textbook. We wrote it in 1950 and that's the way it is. I mean, everyone has a different perspective. I think that's quite useful. physics hasn't changed since then. Why didn't need a new one? Yeah, I find that I personally, too, I like a lot more graphics and demonstrations than are in a lot of texts. And even I will go sometimes, I'll read articles that I wrote. You know, I finished a couple months or a year ago and I go, oh, man, I should have put a diagram or something right here because there's a little block of paragraph where I describe something that I feel like is clear.

But I had a picture in my head and I was like, ah, but I should have given that to the reader. I'm looking at your R-Tos series of posts for Embedded Related, which was two years ago, so I'm not going to give you quizzes on it. Thank goodness. What does the R and R-N-R-R-Tas stand for? R-N-R-Tas. I'm really proud of that one, honestly. That was probably took, that was probably two or three years in the making, honestly.

It's tough because there are books about R-Tosses, and you take the position that a superloop might be enough, that we don't necessarily need Artauses all the time. Why? Isn't an artis simpler? Shouldn't we all just be using Zephyr? Anyone missing the subtext is missing the subtext that Zephyr is pretty complicated.

It's, I can, you know, I'll suffer all the time these days. Yeah, and as a consultant, you know, I'm sure maybe at one point someone's going to pay me to have to do something with it, but I'm going to try to avoid it right now, which is maybe unfair because I haven't done too much with it, but it just feels like the Swiss Army knife that's supposed to solve a thousand problems, but when you try to do that,

the code just gets big and complicated. There's goodness to it. There's a lot of goodness to it. Yeah, I know. So to your question about Artas, I mean, I think there are, If you want something like just kind of off the shelf, you don't want to touch, you know, the code that manages multiple tasks, then pulling something like, you know, a free Ritas or a ThreadX and kind of throwing it at your system is totally fine. It probably will be the quickest way to just getting something going.

But I think I was really taken aback the more I looked into things how hard it is to, you know, write code for a preemptive Rtos, like pre-artos or thread X, in a way that's safe, that's thread safe. It's because it's one of the things I mean, you know, I share a couple examples in that article series of race conditions, and some of them are, they're super nefarious. They come down to sometimes your processor reordering instructions in a way that opens up your thread to an error condition if something happens to interrupt it at exactly the wrong time. And so my stance, you know, at the end of this was kind of like, okay, there are lots of tasks and applications that need the things that an Artax gives it.

But when you do so, you have to understand you open yourself up to a lot of really nefarious bugs that might creep into your code through these race conditions. And unless you absolutely need the response time that you get from an Artax, you're probably better off just avoiding it entirely. And I thought it was really cool in looking at the math, actually, that there are, in fact, some sets of tasks where you can come up with the numbers where on an Rtas, the tasks, some of the tasks missed their deadlines, but in a super loop, they don't. And that's fair. If your main concern is real-time response, I feel like that's actually not high on most people's lists these days when deciding whether or not. to use an artos. It's more like I don't want to write a bunch of kind of boilerplate

code to do either tasks or synchronization or messaging or my handling my ISR or scheduling events and that kind of thing. I feel like most of the time I'm working on a project, real time is not that interesting. It's more like this is too complicated

and there's, you know, as soon as you had Bluetooth or networking, things explode. But yeah, I mean, if you're looking at the real time response. Certainly, it's much easier to control all of that if you're in a loop. And you added preemption in there. Could you explain what preemption is? Yeah. So, you know, the crux of the problem is we have an application that's trying to do multiple things. It's reading from a sensor at the same time. It's writing to a display. At the same time, it's, you know, calculating some filter coefficient or whatever. And even on a

single core processor, we can do that by just sort of wrap. rapidly switching between tasks. The simplest way to do it is with that super loop where in the most basic form, literally inside Maine, I reach a Y-O-1 loop that does, you know, read sensor, update display, calculate new coefficient, and then loops back up to the top. And the nice part of that, primarily is the simplicity. I can just throw my tasks in there and I know that they run kind of in order. But the problem comes when, I don't know, let's say I need, I need to take sensor readings at a very specific rate. And if I'm updating my display and it takes a long time, well, maybe that rate there's jitter, or maybe I miss a sample because I'm spending too much time updating the display. So in the article series, I talk about a couple of ways where you can kind of state with the super loop and stay with that simplicity

and get out of certain tasks faster to kind of go back to reading a sensor. But all those are forms of what we might call cooperative scheduling, where the task itself has to finish and, you know, the function has to return, has to yield back to the scheduler in order for another task to run in a preemptive scheduler like FreeArtos, essentially at a minimum, you know, once every timer ticks, once a millisecond at a minimum, but also any time one of the functions makes a, you know, requests the scheduler for a mutex or message queue or something, it gives Free Artas a chance to say, hey, is there any other task that's asking for my attention?

And so those API calls, those timer interrupts or whatever, they can potentially at that point say, oh, hang on display task. The ADC needs to run and grab a sensor, and it'll manually sort of shuffle things around in memory to let that task execute and then return to whatever task was processing, like the display thing. But yeah, like I said, I mean, that you have to, you know, that gives you the ability to assign tasks to be very high priority and to know that they're going

to run almost as soon as they're ready to go. But you then also have to consider, okay, you know, if these things are touching shared resources, show data or something like that, you know, what are the race conditions? What are the bad things that could potentially happen if my display task between any two machine instructions gets interrupted to do something else? on one hand it's much simpler because you don't have to worry because the high priority tasks are going to happen when they need to happen. On the other hand, you can dig yourself a deep hole with the shared resources because the protection for them is gone because at any time the high priority thing could happen. Which is always true if you have interrupts. It is.

And I think if you think about interrupts as preemptive tasks, Yes, if preemptive tasks make more sense to you than interrupts do, then that totally makes sense. Interrupts, for me, were interrupts first. You know, it's like older processors, you had special instructions to return from interrupts, and you had to handle the interrupts differently. But yes, they can happen at any time, and that's why interrupts need volatile variables and to be locked out, or if you're changing a variable that might need multiple instructions, you need to do if, to keep out other interests.

I don't even know what I'm saying anymore. You need to be careful because you're managing resources that could be in use in the other context. Right. And so that's true of tasks as well, to a slightly lesser degree, but still true. And it's easy to get, if we follow the rules with interrupts, like we have all of these handed down rules, you don't put printout interrupts. You try to get out of an interrupt as soon as possible.

You try not to do a lot of math in an interrupt. You take the data and you set it up for next time and you go away. These are all because we don't want to deal with the preemption that the interrupts cause. but yeah there are other ways of handling this form of asynchronous behavior if you think about

the difference between the preemption of interrupts and the preemption of tasks in artas you could have a blocking no interrupt system as long as you polled often enough

it would be fine it's kind of the same when you have a non-preempting In Artos, you are polling tasks to see if they're ready yet. Anyway, I'm sure I was going somewhere with that. So how long do you think about now? What have you been working on lately for articles? The latest projects, the big one is I started a tiers on hardware security for Digi key that's based off of the mitre, the mitre, embedded capture the flag competition.

So back in 2023, I tried to get a team at West Point to compete. And we did. We signed up. We started our little defense phase, but we never quite made it too far because cadets time is just so squeezed. And I really wanted to kind of go back and say, what would we have done had we, you know, been able to actually take this project to completion? And so I'm starting with that competition, which was,

the mitre gave each team sort of a car key fob system with a really basic insecure implementation of being able to press a button on a dev board to simulate unlocking the car and have that communicate over UART to a second board that functioned as a as the car and then it had to do a couple of the things but ultimately the teams had to protect these two systems and the neat part about the ECTF was that when the teams moved into the team. the attack phase, they could download other teams' code onto the boards that they had on their lab bench. And so in addition to just, you know, all kinds of different logical attacks, they can attack the actual hardware to try to extract secrets and cause it to do things it wasn't

made to do. So working on that. And then I got a presentation also on hardware security for the Embedded Online Conference, and I'll be giving a two-day workshop. on hardware security at CPPCon. Okay, let's talk about the Embedded Online Conference that's coming up in May. Yeah. When is it? Yes.

Yes, May. I think like the second week or so, like the 10th or 11th or something. That's coming up in May. It's the 11th through the 15th. And people can sign up for that now, and you have a code? Can we publicize your code? Absolutely.

Jones 100. We'll take $100 off registration. Cool. Speakers get codes. Yeah. And you're going to give the workshop. It's called Introduction to Hardware Insecurity with the Chip Whisperer Nano. Yeah, I was very proud of that title.

Yeah. So this is in some parts, an introduction to, the chip whisper device that Colin O'Flynn makes over at new A.E. Tech, but perhaps in kind of a larger context, an introduction to the idea of power analysis attacks. So we're going to spend the majority of the two hours showing how by monitoring the power trace of a device performing AES encryption, you can use that data to extract the AES key, the secret key that's being used on that device. And hopefully I'll have enough time at the end also to demonstrate the voltage fault injection to skip over a password check. Cool. So I should bring this device that I want to hack

and you'll help me? That is highly encouraged, but I recognize that not everyone is going to have it with them. So I'm also making sure the workshop materials, you know, I have simulated data to do all the exercises. So the only part you really miss out is using the device. itself to like collect data in real time. And also, I hope is to also have that kind of third path of where you get to do the same exercises on a much, much reduced subset of data, like small enough that you can like print a little table on the worksheet so you can like in Excel or by hand actually kind of follow along. So I mean, we've talked to Colin before. So I know a little bit about the chip whisperer.

I even have one. I've never used it. And as an engineer, I find it kind of impossible for me to write code to make it safe against this attack. But it's been a long time since this has been in the wild, so I assume something exists to harden things. Yeah, I think the weirdest part is just that

it kind of involves looking at your device from a perspective that is not well trained. The techniques to safeguard a system against something like this are just kind of non-weird. They're non-standard. So it's just not a thing that I think comes naturally or is readily trained. But with the EU's Cyber Resiliency Act coming into force,

I think it's September, you know, a lot of companies, I think, in the U.S. are going to suddenly realize that they have to, you know, or they can't sell in the EU markets. Because of attacks like this? Well, so the Cyberresensi acts kind of establishes a baseline level of protectiveness for devices being sold in the EU. And it includes simple things like there has to be an S-bomb up to there have to be ways of pushing security updates to the device for like a minimum of five years, and it has to kind of default to a safe mode. It's not super technically oriented, so I don't know if this attack is listed in there

is needing to be defended against. But for higher vulnerability devices, like smart cards or secure keys or things like that. I think it's absolutely something that those companies need to be considering if they aren't. And is this something where, okay, I have this loop that does my AES calculation and it alters the power. Can you just insert, I don't know, random things that make the power to, can I just fuzz the power usage to defeat this, basically? Yeah, in a sense.

So, I mean, the kind of the basic idea is that, um, So like every engineer that works on embedded nose, I can monitor the power trace to determine how much stuff my device is doing. And if I need to go to a lower power level, I can start turning off peripherals and turning off things. So we already have this implicit understanding that how much current my device is drawing is related to what's kind of going on in the chip. When you do something called a simple power analysis, you can actually start to kind of align. features in the current trace to things that the microcontroller is doing. So for one example is when you're doing like RSA encryption, based on each bit of the secret key, you do either a multiply or a square and multiply.

And so even if the device itself is super secure, I can look at the power trace and I can, you know, if I kind of know where in the power trace this encryption is occurring, all they need to do is sort of look for a repeated section that's shorter than another repeated section. And that's intentionally enough information to determine whether the thing is doing a square or a square and multiply and to recover the zeros and ones that make up the RSA key. To recover an AES key, we have to kind of go one step further, which is to make the sort of rough estimation that the magnitude, if you will,

of the current draw is actually related to the magnitude of the number of ones that are on in the MCU at that time. And that's not enough to necessarily resolve, like, the value in a single register. But if I make an educated guess as to a bit in the microcontroller as it's doing an encryption, I can take my power traces and I can sort them into two groups. And if my guess was correct, then the group where that, my guess, assumed the bit was a one, will statistically have a higher power trace

right at the point where that bit was on in the encryption process. And if I average my two datasets and subtract them, that's the differential part of differential power analysis, then I can actually see that as a tiny peak in my graph. And essentially what this does is it takes, you know, the process of brute forcing an AES key from, you know, two to the 256 into more like two to the eighth because each bit in a bite, I just sort of have to guess what value the bite had and sort these power traces and subtracting to see if I find this

peak. And ultimately I can recover the AES key that way. How much of this is turnkey? I just walk up to my chip whisper, wave it nearby, and it comes up with an answer for me. You know none of it from what I am. This isn't a movie. Why not? Just write a Python script that does it. I mean, the chip whisper, with the chip whisperer, it's chunky because they set it up that way.

One of the biggest limitations is the fact that the current consumption on the device spikes right at the clock edge, right? Because as soon as the clock transitions, that's when all these lines go high or low. And so if, so on the chip whisper, they can get away with not needing a ton of expensive hardware on there because they clock the microcontroller on the device that you're sort of exploiting, they clock it from the same clock source that they run the ADC at so they can ensure that those data samples align at the exact point in the clock cycle every time. If you don't have that, or like on a device if it's running from an internal clock and I don't have access to that, then I essentially need a much, much more expensive a solar scope to sample at, you know, 10 times or higher the clock rate

with a much higher bandwidth to try to grab, you know, enough of the data to get what I need. And there's a whole bunch of other parameters I need to sort of, you know, control for, well, I need to be able to, if it's a real device, I need to be able to sort of trigger encryption on my command, thousands and thousands of times a second, potentially, hopefully, to get all this data. And so, you know, one of the ways of thinking about your secured and your device is,

well, you know, if that represents a typical operation, I need to, you know, hopefully shut that down in a way on a real device where I can only grab a couple of samples before it makes me wait. And that would, you know, make it take much, much longer to collect enough traces to analyze. So it's, no, I got a lot of my information from Collins book that he wrote with Jasper van Wootenberg, who was also on the show, the hardware hacking handbook. and they're pretty quick to say like, hey, sometimes we spend weeks, you know, setting up these experiments and taking data. Just, you know, can't get the info we need. I guess it's reassuring that in many cases it's very difficult still and you have to be motivated, but there's a lot of motivated people out there who would like to, for better or for worse, crack into things. So. Yeah. Yeah, it comes down to just, you know, what do I feel like I need

to protect in my system and at what level do I want to protect it? I mean, at some point, you know, if you hand your device to a nation-state hacker with government's resources like you are, there's just nothing you can do to protect against that. But for most people, that's not a scenario they need to really consider. So we just need to sort of make it, you know, hardened enough that we can say we did our due diligence, you know. Yeah. At some point, physical access is all access if somebody wants to decap the chip or do fancy things. Yep. Nathan mentioned the Cyber Resilience Act for the EU.

And one of the things there is that companies need to conduct a cyber risk assessment before the product is put on market. And that's in order to carry the CE marking, which is, you know, one of the basic ones. That alone, I mean, all of the other stuff, you need to have security updates, you need to keep security separate from features. Those are all really interesting. I just am excited that people will have to think about security before they put it on the market. Because that seems to be a loss for a lot of companies.

It's just like it doesn't really matter. Who would want to break into our thing? We're only going to ship a thousand of a. Or our thing isn't important. But maybe your thing being hacked gets them access to a cloud key, which gets them access to your S3 bucket, which gets them denial of service your entire thing, and then they ransomware. You have to think a few steps ahead from,

oh, I'm making this little wearable that just counts my dog steps and puts it in the cloud. How is that going to hurt anybody if it gets hacked? Well, there's probably ways. Yeah, well, I mean, TIA, right, person identifiable information can be enough to figure out who an exact person is if I just have a couple of pieces of information,

if the device is storing my users, you know, log in to the app on my company. If I can extract their login, then that's money on the, that I can sell that to someone else because there's a good chance they're using that same login on a different website. So, yeah, there's lots of different ways where extracting, you know, seemingly small piece of information can accrue.

We used to, in the military intelligence, we used to call it, What was it? I forget in the term, but it's classification by, I'm forgetting the term now, but it's the idea that I can take a whole bunch of different pieces of information that are each individually unclassified. But if I put them all together, it paints a picture that's suddenly at a secret or top secret level. How are you staying up to date with, I guess, security, since you've been doing a lot of security? How do you, I mean, you're writing about it, but you're also learning about it. How do you, where do you go to learn more?

Oh, man, you totally just like hit the kid in me that's like, I don't know, man, I'm trying to figure it out. We all are. That's why we're asking you. I mean, I think security is an interesting field, especially hardware security, because there are lots of great people out there doing security research. You know, Colin and Jasper and Mark Homo was on the show a couple weeks ago. But I think in embedded, it's still on the newish side of things. So going back to the idea of how do I write my articles to try to make sure that I'm reaching a broad audience. These are articles or workshops that I think, okay, I need a longer tail because I think there's a lot of embedded engineers out there that haven't thought they needed to worry about it. Like, oh, it's not connecting to the internet.

It's fine. So at the moment, I mean, I, the biggest, the biggest info has been that hardware hacking handbook and then me working through, okay, how do I actually conduct these attacks? I don't tell Chris, but I use chat GPT and cloud a lot to like bounce ideas off of and just say, hey, is this how would, you know, just this attack makes sense? how could I, you know, what are other attacks I need to consider? But hopefully soon I'll get a chance to head also to the Hardware I-O conference that is in your year. That's a whole hardware security conference. They usually have some in the U.S. too. Oh, really?

Yeah. This is hardware H-A-R-D-W-E-A-R. Yeah. It's confusing to me, and it has nothing to do with wearables. Or hard hats? No. So what has been, for the two of you, what's been your experience professionally with security or hardware security? Has it been usually an afterthought or have you worked at places where it was really given kind of first rate?

Consumables. Anything that has a consumable suddenly has a lot more security around it because the consumables can be spoofed. Yeah. I've had that and you've had that. Yeah. My deepest experience with it was. being in charge of that. But it was a very long time ago. Principles are kind of the same. You know, you have things that are protected by keys in the firmware and things that are provisioned with keys

that you're supposed to be not able to rid out and all this stuff. But it's a cat and mouse game. And like I said earlier, physical access is physical access and people figure things out. So, yeah, it depends on how much of a target your thing is and what the gain is for somebody to hack it. And if it's, well, you're selling a $400 thing consumable that we can manufacture in China for free and charge somebody for knockoffs, then that's a pretty big incentive. And that's what happened at that place.

It's really hard because we make embedded systems, like one of my definitions for what is an embedded system is something purpose built for its application. Right. So you're making a microwave. It's to be a microwave. If you're making a pedometer, it's to be a pedometer. You're making a sport watch. Now maybe you're making nine things at once. But there's always too little space, not enough money.

I like the challenge of being resource limited. It's a fun challenge. But then when you add security and security for five or ten years in the future, and I have to admit, I just throw up my hands because I can't. given the security changes in the last five years or in the last 10 years, I can't predict where that's going to go except that, sure, you'll be able to crack anything I do right now if you want to. Well, and most of what I've been doing,

and I think you've been doing prior to the current client you have, is Bluetooth connected stuff. So there's a lot of security issues with Bluetooth. There's a lot of security issues with securing firmware and firmware updates, which most of the vendors are kind of doing for you now. You just kind of have to plug and go. I mean, because if they aren't doing it, nobody's doing a good job of it. But you have to be careful, right?

Because you have signing keys and things that are part of your build and you don't put them on in GitHub. So you have to be, you know. Okay, everybody who's put their signing keys in GitHub, just shake your head now and let it go. Or on one guy's laptop that's, you know, that nobody has access to and oops that I dropped it. You know, there's those kinds of considerations that kind of how do we, conform to breast practices, not, oh my God, somebody's tuning to a power. That's just not on,

I've never had that be on any client's radar yet is how do we secure our device from power monitoring hacks. Yeah, yeah. Well, and what's, see, and I feel like, too, there's going to be lots of teams. I'm speculating here. Lots of teams where, you know, even, even basic stuff, like, oh, you didn't turn off the debug port on the microcontroll.

Yep. is coming. Right, because folks, like Elyss, like you said, they're just not doing that threat modeling it. They think, oh, it's an unlabeled pinheader on my PCB that's enclosed in my plastic case. Like, why should I need to worry about that? Except that, you know, once, anytime someone opens that up and go, oh, unleveled pinheader, I'm going to see what this is. And it turns out I've got a, it's a SWD interface. Cool. Yes. Unlabeled pinheader, which one of these is TX? I'll just monitor them all. But it's, but I mean, are you going to get rid of the JTag connector? I, you needed for the, you needed for the, factory you needed for field debugging. So it's a very difficult calculation sometimes. But there's also other things you can set that say, oh, you're not allowed to, you know, rewrite this firmware.

But all of those things are an NRF, J-Prog command line away for the most part. Yeah, and there are some MCUs now that are a little more security focused where the debug port is actually authenticated. So you have to have, like, the proper, you know, key. Which is great. until you're trying to develop for this thing, and now it takes 10 extra minutes to get anything done. Or if you're trying to, I won't go into it.

But I've been fighting with Bluetooth the last two weeks, and one of the things I was trying to do was a wire shark with a sniffer. To see what the hell was going on with our throughput. And I was not able to make it work. But it's... I assure you it's possible. I believe it's possible. It just took me like five tries.

Well, I was on try eight or so, but I'm sure. And there's just things where, okay, Wireshark needs to, you need to turn off all security, but you can't turn off all security because some things are still secured between an iPhone and your device. So stuff still does a key exchange, and Wyrshark has to watch the key exchange, but it has to be in the right order, and the other device can't get in the way first, and everything has to be perfect. And then maybe you can see what's going on.

But, you know, I guess what I'm getting at is during development, security is a pain in the butt. and you turn it on too soon and people get mad. Yep. And so it's... Failed to turn it on at all and other people get mad. Yeah. It's just to make you somewhat in the military, right?

Because I, you know, as the intelligence officer for a lot of the units, I was in charge of physical security. And I couldn't tell many times, you know, the system's got this crazy, like, badge access behind every door. And I'm about to leave the building and, you know, all the exterior doors are propped open with bricks. I'm like, you've got to be kidding me. Yeah, but there's a lot of bricks in software and firmware.

You know, you can find them. and it's tough to find the right time to turn all that stuff on, and it's tough to make sure you did it right, and there's not a way to accidentally turn it back off and stuff like that. Like, even like, okay, the release image doesn't have the U-art. Okay, we're moving to the release image, and now, well, we have this fault in the field. Well, tell me what the U-art says. There isn't a U-art.

You turned it as a release image, and everybody's shaking their head. It's like, well, should we've done that that soon? You know, anyway. Yes. Yes. Yeah, I think it's, in my head at some ways, it's kind of similar to, I don't know, like thinking about reliability. You know, as an engineer, it's, you come out of school and you know how to make stuff work, but to actually ship a product, you have to actually kind of stamp out those one in a million little bugs in edge cases. And thinking of security to me is the same thing, but maybe just one step further where, you know, those one in a million in a million times are going to happen a million out of the million times because it's in the hands of an attacker.

And so I need to think just a little bit more rigorously about what my device is doing and how certain assumptions that I'm making as a developer could be circumvented by someone with malicious intent. And how do I contain that fallout just enough that, you know, I can either, I can forestall what I don't want to happen, you know, just long enough. Do you want to teach this or do you want to do this? engineer or instructor? I think I'm always going to make an instructor first, but the reason why this is fascinating to me is because, you know,

I, I, the, I mean, when I went through the the, the tutorials that Colin has for the, the chip whisper, you know, and yet the, the, the first time you, you run your attack script and a minute

and a half later, you know, your your Python script pops out, the supposedly secret AES key that's on your device, it's like, whoa. So I don't think I'll ever like full-time me hacking. But I think I'm carving out of space for myself consultancy-wide as someone who can kind of help figure out hardware security stuff. And it is fun. I mean, from that aspect, when you're not under the gun trying to make, you know,

when you don't have a UI team saying, we need to make this color different and more 3D. and at the same time somebody's screaming at you that, you know, there's a security problem. It's more fun to like think about these problems and be outside of it and be helping people rather than the one under attack, I suppose. Totally, totally.

You said that this talk is for the Embedded Online Conference. You gave one last year as well, a presentation at the Embedded Online Conference. Yep. Exception handling? Yep. That's all you're going to tell me about it. I'm a man of a few words.

You didn't ask you a question. You're right. You're right. You're right. You're right. Could you please tell me about exception handling as a presentation? Yeah. So, you know, this started, I can.

Yeah. Yeah. So this started a couple years ago, I thought, you know, my skills in terms of building robust firmware, right? You know, making sure my system can handle. errors and exceptions is lacking. So I'm going to go out and do a bunch of research. What are the leading experts kind of say on how to do all this and what seems to be kind of best practices? And so I got a bunch of notes together, kind of sifting through the differences between tri-catch and return codes and in

arguments, out arguments, all this stuff, the way that you can kind of let program know something bad has happened and how you respond to it. And I wanted to be able to share those. So we did a two-hour workshop where I presented a couple of different techniques and a little structure to think about, hey, how am I going to kind of harden this code against things that weren't necessarily supposed to happen so that the program can handle them gracefully? And I feel like at this one, I should clarify that the exception handling was not meant in any way to mean like tri-capt exceptions. It's in... Oh, no, hard fault.

Any fault, right? process works. Oh, well, the big ones. Okay. So when I would, so there's, there's not a ton of standardized language around this, but what I settled on was an error was a thing that absolutely positively should never happen. I, I get the square root of something and it gives me back an integer value, which is negative. You know, or there's like, there's just no possible way that the system is working correctly

under these conditions. And at that point, it's, you know, it could be a bit got flipped. It could be that I'm under attack. It could be that my stack got corrupted, but I'm essentially in a point where I cannot trust the execution of my code anymore. For those, I need to assert, and I need to either restart the system or sort of fail safe to like some default behavior. The exceptions are kind of one step above that.

These are things that could possibly happen, but the program can't sort of continue along its merry way with this data. You know, example might be I'm reading. from a temperature sensor and I read, you know, 30 degrees, 31 degrees, 30 degrees, negative a million degrees. Okay, maybe that last one I need to handle it differently than, you know, than the other ones. I can't necessarily tell my system that suddenly it dropped to...

Don't just average it in with the others. Right. Throw it in the bucket. It's all data. Yeah. Yeah, so, you know, step number one is to just start thinking about your functions. You don't actually have to do anything crazy. You just have to look at them and think, okay, what are the possible things that could happen that I don't want to just sort of throw back into the system.

And the easiest thing to do is just sort of, you know, at least ignore them, right? Do something to, you don't have to necessarily do anything crazy. This big error reporting logging process, I just need to not pass along garbage data. And that's easy enough to sort of put those little conditionals into your function and change the function signature a little bit so that there is, Eventually, it might hand back an error code to the system to start to be kind of close those off. Okay. The previous year, 2024, I gave a talk called Creating Chaos and Hard Faults, which was how to create hard faults and then how to get the information back to yourself after you've rebooted. Yeah.

But you're saying that the hard faults and the exceptions are not the same. Not the way I'm using the term. I mean, I think if you, in like a cortex system, you've triggered a hard fault, right? That's it telling you that, you know, you tried to assign to read only memory, right? Are you? Divide by zero. Right. Yeah.

Which I would put in that category like, okay, something's very wrong in the system. And it, I mean, it could be a one in a million or it could mean we're under attack or my stack's corrupted or I just, yeah, I don't know. But I would put that in the category of like, we need. to, this is a restart to try to start from a clean slate or go to some sort of fail-safe behavior type situation. And that one, the hard faults or the exception handling is available on YouTube. Yes. Yeah, because I got the video, because someone on the Slack channel requested it, and so it's

been posted so we can put the link in the show notes. Speaking of the Slack channel, we have been doing a book club, and you have heroically been carrying the rest of us who are spending more time reading your summary of each chapter than actually reading the books ourselves. Yeah, you should do a worse job on the summaries, I think. I'm an instructor. It's in my blood.

I haven't been in the right headspace to read technical books very much lately. How do you... I'm anxious to see where this is going. You're right. How do you force yourself to read technical books? Was that where you thought it was going to go?

Yeah, pretty much. Nathan, how do you make us better at our jobs? Nathan, please make me like computers again, please? Sorry, answer a little easier's question, not mine. Is there a way to convince myself or to convince my coworkers, if I'm not in whatever funk I'm in, to pick up more books. So, well, if this is not too personal, I mean, like, tell me more.

Like, I think you made a great point before Lisa, that, like, you know, if you're, if you're doing a lot of writing for work, then writing it in the evening is not relaxing, right? You know, you have to balance each other out. So is it that you're, you know, you feel like there's a lot of technical documentation you're already waiting through? And so reading a technical book at night is not relaxing. or is there something else?

Go ahead, but I could take a step at this too. I messed with my neurotransmitters from the bottle, and now I am just not quite functional. Work is good. Things are good. My brain is not. It's raining. It's temporary.

But I went from, yes, let's read Pragmatic Programmer. I'm in, let's read a few chapters to, I can barely read trashy novels. So that's me. Yeah. And it's temporary. And I acknowledge that now. But I also, you know, I don't.

Okay. So thank you for filling in, by the way, Nathan. I know this was very last minute. And that is because I bailed, flaked, was a complete jerk by flaking on the other guest we had for this weekend. because there was no way I was going to manage to read his book in any amount of time. Even though I started talking to him weeks ago, I just couldn't do it. I want to read pragmatic programmer.

It's not hard. I've read it before. It's very small chapters. I totally can read it. I am reading a lot for work, but I, that's, I'm okay with that. I just, I'm like, as soon as my billing stops, I'm just like, I'm checked out. That was what I'm going to say. Because we are consultants, reading technical stuff for fun, I just cannot do it because I am doing work for free. I can't bill my client for reading, oh, I should get this Bluetooth book to understand it better. And maybe I should be billing them, but I find that difficult to do. And I'm not going to bill for lying in bed reading a book. No.

I mean, it depends on how related it is to the work. Right, yeah, yeah. But it does make it a little more of a jump. I'm not working. I'm relaxing by reading this technical book. And that's kind of. It's not relaxing. It's investing in yourself. See, I can say all these words, but I am just not doing it. I know you're just trying to, yeah, be devil's advocate over there or angels advocate. I don't know. All right, Nathan, fix us. Stop working as consultants. Step one. Take all your computers, throw them out the window. Hey, man. You don't know how close I am.

Not today. It's raining. Wait for a day when it isn't raining. Oh, that'll be more permanent. I mean, I feel like those are both really great reasons to give yourselves the permission to not feel like this is a thing you need to do on your off time. You know, to excel at a thing typically means you need to give yourself the space to rest and recover between bouts of really intense work. And I think in our country, our field maybe, our culture, it's easy to just think, you just need to push and grind. But, you know, that just leads to, you know, eventually a lot of mediocre kind of substandard work. And so one of the things I'm learning as I've transitioned into this weird kind of part-time consultancy thing is how do I kind of work with the little ebbs and flows of, my attention and my focus. And some days it's, I feel like I could, you know, I could sit down and

type out 4,000 words. And some days I write the same sentence a hundred times and then call it a day. And I'm trying to, you know, in those moments go, okay, well, if writing's not at the task, it's coming to me right now, then, you know, there's something else that I can kind of work on or maybe that day I need to recognize that that's a sign that, you know, I had a tough weekend, lots of family stuff going on. I'm worried about travel that we're doing in a week. And so my brain's just not in the headspace to, like, do deep focus work. Fair. I think that's a very important consultant note, is that there usually is three or four things that you're supposed to be doing.

And if you can do the one that has the least friction, then you probably should, at least to the point where you're not overdoing it. Yeah, yeah, yeah. And just recognizing, too, that there's, you know, there might be tasks that kind of line up with that, right? Like, you know, if there's a, if after lunch, you just are not, you know, you're the kind of person where those last couple hours of work are just not, you know, you can't do anything really creative. But you still got to get through, you know, your email inbox and, you know, making plans for future, whatever. It's like, you know, you can say, I know that this is going to be a good time for that one. I don't necessarily have to have my brain at full capacity. This is when it's time to work on the CI flow.

When it's time to edit the document I wrote two days ago and have forgotten, but I'm just copy editing at this point. That's the best because then you're like in a different enough headspace from when you wrote it, that you can be like, this doesn't make sense. I got sent it back. Yeah, yeah. After lunch is the best time to read your documents because I feel it my stupidest. So I can't understand what I wrote. And, you know, I've taken a minus 15 to intelligence.

So, I've been playing more D&D. Sorry, I don't know why all these plus threes and minus things are coming up. I love it. So what's been your, Alicia, what was, I think you and Chris talked about it a little bit on the last episode,

but from the first time you read it and the little bit that you've read now, what's been your impressions of the book? It's a weird second or 20th anniversary edition. Yeah. I don't. So the book, anytime you're writing a book and you have a second edition, they want you to add more. They never want you to remove things. And so if there is something in your book that everybody comes up to you and says, I love that part, you're going to leave it in. Of course, you're not even going to change it. But if everybody comes up and says, I disagree about this, you're going to start putting the arguments in the book. In the new edition, you're going to argue with the people who have been talking to you for the last 20 years. And this edition of Pragmatic Programmer, I can feel them arguing with people who are not me. I mean...

That's okay, because in the third edition, they're coming for you. For real? Yeah. So it feels like they've added a lot of things that, to me, seem like croft. I think I mentioned it last, last episode, the don't repeat yourself. It has always been like a section that I really liked because it was so tactical.

If you are repeating code, you need to think about why am I pushing control C, control V over and over again. And then- Well, I think it's a great example too, even down to like the line level or like the print f-4 matter that I'm giving to my, right? like if these things are repeated, like I should wrap those up because at a minimum, if I want to change it, I change it at one spot. And so this, you know, it's got a nice name.

It's the dry principle. Are you writing wet code? But then in this edition... I do not like that just for the record. They've said it isn't just about code. It's about everything. You shouldn't be repeating data. Okay, that's true.

I agree. But before you had this nice tactical advice, and now you have this architectural advice that's still good advice, but... It's harder to implement. It's harder to apply, figure out what matches it. Yeah. It's a harder piece to internalize.

And I feel like they've done that with some of the others where they've expanded them because that's what you do in a new edition, but they forgot the fact that they were writing for somebody who hadn't read their previous edition. Yeah, I would totally agree. I feel like that's one of my critiques the book is that

it's, there's, there are lots of places where it could really benefit from, even just a very specific example of, hey, this doesn't call for every case. But if we're talking about, you know, this, this term orthogonality or, you know, actors and processes, right? Here's, you know, more of a, of a concrete example, what that looks like. Actually, that's a good example in that. I thought they should give more credit to design patterns and then just shuffle them off to the side.

Yes, they are super important. This is not the book for that. But they wanted to add so much more. They wanted... And so it felt like they added more, like, producers and consumers and design patterns. And I wish they hadn't, because I already have a book about that. I wish they had just told me they existed and then sent me off to go look at some other book,

which I wouldn't have read either, but that's just right now. For different reasons. No, but I mean, I'm enjoying watching people read it. I do sometimes, I intend to declare bankruptcy and read this week's chapter, but I've said that for the last three weeks, so we'll see. And you're coming at it with a different perspective, which you're admitting. If somebody's coming at this never having read it before, there's probably a lot of useful things to pull out. Indeed. And there are some good, useful reminders. There aren't as many good useful reminders as I had hoped. But then maybe if I actually was rating it, I would get more. So we'll see.

Well, speaking as someone who is reading this for the first time, I mean, I'll say, with all due respect to the authors, there's points like that we just mentioned that, like, I don't know, maybe things could have been a more tactical. There were in a couple other points in the book where I feel like things were a little unclear or even kind of misleading. There's been one or two points where I kind of disagreed with what they had written. And looking over the topic list, I feel like it's a great collection of topics. It's the kind of thing where, you know, if I was, I don't know, if I was hiring someone and they could, you know, talk as intelligently as the authors about these things, I'd be like, wow, this is a great, this is a knowledgeable person. But in terms of being able to hand this to someone and say, hey, these things are important to us as a design team, so we want you to, or development team,

so you should be familiar with these things. I feel like it would just be not the book that would get them to that point. And so, you know, to me, I remember, and I keep comparing it to Philip Copman's book, the better embedded system software. I kind of felt like between the two, they tackle similar things, but I felt like Philip Cutman's book was a little more,

had a little more oomph to it that could make it a little more implementable. Kind of sad, but cool. Okay, one more thing about the new edition. There are many more languages and many more paradigms, ideas on how to implement code. And they tried to address all of them and they ended up addressing none of them. Okay. Let's see. Your shift from full-time U.S. Army instructor at West Point to part-time embedded systems engineer and writer and conference speaker.

How major was that shift? How often do you wake up at 6 a.m. wanting to do PT? Oh, man. Thankfully, thankfully hardly ever. I think it came at a right time. I had a nice little kind of wind down that started with the Army thinking I was not major material that made me think, oh, well, maybe this isn't the, you know, 20-year career. I had thought maybe it was going to be. And I got to finish out at a great place at West Point,

having taught there for five years. At that point in my career, there just wasn't a whole lot left I really wanted to do in the military. And I was honestly more, just much more excited, having spent those couple years at West Point to do more presenting. And I mean, I'd done a little bit while I was there. That's kind of where I started to get into it. And so it's,

it felt right. I really lucked out. There was a friend on the Slack channel that I spoke with while I was doing some job hunting that kind of helped me land where I am now in getting to, you know, more or less work full-time. It's not really full-time work, but, you know, just basically 100% of what I'm doing just about is for Digi key. So I think without that, it would have been a lot scarier to have thought like I got to find a job. And, you know, I'm at a weird spot where I'm technically an entry-level engineer, but, you know, I'm almost 40. And so what do we do with that? How do I, which job do I apply for?

But I feel very blessed. Blessed that, you know, I had a great career in the military. Blessed that I had the opportunity to build up a small portfolio while I was there of blogs and presentations and conferences that had going to help me land a great job. and blessed that my wife still works full-time. So it's not a huge financial concern when the income fluctuates from month to month. What about the two of you? Was that, I mean, in that transition to consultancy, what were those first six months to a year like? Was it really scary thinking like, oh, I'm not going to be able to make ends meet if I'd have to follow up this client with another one?

Well, the first time I did it, Chris was working full-time. Yeah. I mean, the first time Chris did it, I was working full time. Yeah. So that does leave, I mean, it gives you a steadiness that you don't get if you're a solo contractor working on your own. And when I went into, well, see, it was a long time ago, so it's a little confusing. Transitioned in and out of full time and consulting a lot, so the history gets a little messed up. But there was a time I was in grad school, so she was working full time and I was in grad school making nothing.

So that arrangement. of having one of us have a fluctuating income was not unusual. I would say that the anxiety about clients is a recent phenomenon in the last five to, say, eight years, because we had more steady long-term clients back then. And I think in the last few years, there's been a little bit more, at least on my side, a little more client churn. And so there have been longer periods where I've been seeking things out. I've been very lucky most of the time I've gotten things very quickly, but there have been some times where it's been a few months,

where that's been kind of a question, yeah. And as part of that, though, because you're pointing to your career where you can be more selective with who your clients are, you think? I would say the longest break, the longest unintentional break was not that it was, I was willing to accept more than I am now. Now I'm very tight on which clients I,

accept for various reasons. But yeah, it's not getting easier for me to find things I like doing. You're getting way pickier, which is fair. And you haven't necessarily been wanting to do the work until you found something interesting. That's true. It's hard to advertise that you're available when you also want to say, but not for most people. I mean, yeah. Yeah, but that's true full-time as well at this point.

There's very few full-time companies I would go to. Anyway, yeah, that's personal stuff. But there have been, and there's been time, you've been, you know, you're laughing at me, but there's definitely been times where you have been looking for clients or worried about getting one. And then you end up getting three after a month of angst or something and trying to figure out how to juggle it. No, no, it can be difficult to, and it's usually the, I'm done with this client, I want to say I'm going to take a few weeks off, but then about three days into those few weeks, I was like, I don't have a job.

I don't have a job. And that, that is, yeah, it's a little scary. Yeah, it takes me two months to get to that point. Yeah. My wife always complains because for her employer, they, you know, I also, go out looking for clients. And the best time to look for a client is right when you're like neck deep in a project being like, I can't take on more work. But like there's like this lead lag thing going on. And when it, when it rains, it pours, you do end up, I end up getting too many clients

and tiring myself out and then saying I need a break. And then two days into the break, I'm like, oh, no, where are the clients? So, yeah. How do you say no? Lisa, teach me this. I don't have time right now to. help you let me find you someone else. Who are you funded by? That's my usual. First go, yeah. I mean, the, I, you know, the assumption that I have a limited number of hours I can provide. And if they want, you know, three hours a week, then yes.

If they want 25, then no. Yeah, I'm booked. I'm booked. I'm booked. I'm booked. I'm booked. I'm booked. Um, it's.

And occasionally there's like. I don't know how to do that. So if you want me to do that, it's going to cost you a lot more and you might take you longer. You probably should find someone else. Yeah. I'm willing to say I'm not an expert in that. And I would love to help you, but it's not worth training me. Are you having to turn people away?

Because it is scary. It's better to turn people away than to be desperate. Well, I've just always said that problem where I want to do more than I have to. time in the day. So, I mean, like, the stuff I'm doing for Digikey and prepping for the embedded online conference and CPPCon is, uh, is already taking, you know, more time than I, I wanted it to, but, you know, it's because I, to me, if I'm not, you know, like, if I'm not, if I'm not done with May's work in January, then I feel like I'm behind.

I'm working on, working on that. Uh, so, uh, I got one, you know, an invitation recently to, uh, to work on something. And I was very proud that I didn't immediately reply, yes, yes, yes, yes. That sounds awesome. I might still, but it's harder to think, oh, man, you know, do I have the hours in the day to do this? Is this the thing that I want to do? You know, what is kind of the future look like?

And, you know, what is the ideal? And does this fit into it? I mean, yes, I am excited about this opportunity. What is your timeline? because I am partially booked at this point. Is a decent set. Because I've had clients that, you know, they gave me a long list of things. And I'm like, okay, that's four months of work.

And for the next two, that would be way over time for me. But then when I go back and I'm like, okay, what's your timeline? And they're like, oh, we want this done every year. And I'm like, okay, I can fit you in. That'd be great. Yeah, it's it is a balancing act and it's always hard to turn down because it's like you do want them to come back to you. You're only busy right now. Come back to me next time.

Which is why I end up, you know, sometimes trying to match me and say, oh, I'm not available, but I know somebody who is. I like that. On the assumption that next time they will toss me the work if I need it. All right. I'm going to wind this up. Nathan, do you have any thoughts you'd like to leave us with? I think the one is to just to say there's a quote. If I get it, hopefully I get it right.

I think it's by Howard Derman. It says, don't ask what the world needs. Ask what makes you come alive because what the world needs is people who are alive. And talking about where I am now professionally, like I said, I feel very, you know, very, very less that the opportunities came, but I think I can also see how, you know, I studied really hard in school. And at West Point, even though no one was asking me to do conferences, I asked to speak at conferences.

I found a way to publish material. And it paid off. I like to think that I kind of embodied that, that quote a little bit, that I just, I pursued the things that brought me joy and that made me feel like invigorated. And even when it didn't necessarily have an immediate monetary payback, but the world wants people who are passionate and wants people who are alive. And I think it came around. Our guest has been Nathan Jones, educator, embedded systems engineer,

15-year U.S. Army veteran and frequent contributor to our embedded-related, Digi key. He's also on the Embedded Patreon Slack and is a contributor there as well. Thanks, Nathan. It's good to talk to you today. Thanks so much, you too. It's always a pleasure. Thank you to our Patreon supporters. And thank you for listening. If you'd like to contact the show, it's show at Embedded.fm or hit the contact link on Embedded FM. You can also click that support link if you want. And now a quote to leave you with. I'm going to go with one from Ancestral Night, Elizabeth Bear because it has a really interesting mechanic around brain chemistry and is somewhat related to this show. There's value in work you enjoy or that serves in need.

There's no value in work for its own sake.