Embedded - 410: Emacs From the Future

Episode Date: April 21, 2022

Chris and Elecia chat about tools, interrupts, and general happenings.  Thank you to Newark for supporting the show! The part that was not guessed was an RF FET: MRF1K50HR5. Elecia found MCU on Eclipse (Eric Styger)’s tutorials on Visual Studio Code for C/C++ with ARM Cortex-M (Part 1). Embedded has a Patreon page where you can get access to the Slack group. The book club is starting Prototype to Product: A Practical Guide for Getting to Market by Alan Cohen. Wokwi Raspberry Pi Pico projects from Elecia: Command Line Interface and PWM Experiments with Logic Analyzer Phillip Johnston of Embedded Artistry and Tyler Hoffman from Memfault are kicking off a quarterly embedded discussion panel. This month is about building embedded systems at scale using device metrics: Embedded Device Observability Metrics Panel  Jonathan Beri from Golioth created instructions on how to use USB from WSL2. Copy-editing game. Transcript. Thank you to Newark for sponsoring this episode of Embedded!

Welcome to Embedded. I am Alicia White, here with Christopher White. And today it's just us chatting about tools and interrupts and whatever else we feel like. Okie dokie. Let's do it. How you doing? I'm excited to be here. Are you? Always.

Pretty sure he shook his head when he said that. It was more of a diagonal nod. Okay. Yeah. No, I'm doing too much. Doing too much. What are you up to these days? I have clients that want me to do things for them.

That's terrible. It is. I don't know how this keeps happening. And one client wants me to do more for them when I had kind of enjoyed them being on the back burner. So now they're in the mid burner, trying not to get burned. And yeah, mostly working. Practicing a lot of music, but I'm not writing a lot or recording a lot. I did set out a plea on Twitter for if anybody needs drums or bass on anything.

I'm available. You've been practicing playing really fast. Has it affected your typing? No. What? My typing is as poor as it has been since the 80s, since I learned poorly on an Apple II Plus keyboard. I have a couple of notes from the last time you and I talked. Okay. The first was about the 10-minute podcast,

something I will forever regret bringing up. I'm sorry, we're not doing it. The goal was never to stop doing the longer podcast. It was just to make a shorter magazine version. But the truth is, no, let's not do that. Okay, fine. We won't do that. And then I got an email that was concerned that the show has to grow because we have been pushing growth or it will die. Yeah.

And that was never it. Everything dies. Yes, but it's not a we need more listeners or we're going to stop doing this. I want to reassure listeners that's not true. Well, certainly if we start to have way less listeners at some point, you know, if nobody's listening to us,

which I don't know why I want people to listen to me, but anyway. But there was some concern that it was grow or stop doing it, and that wasn't it. It was I really think there are people out there who could enjoy and benefit from the show. And unfortunately, we have reached the limit of the people we can reach without trying new things. Yeah.

And we hate trying new things. So we've been in that for a while. Yeah. But no, if the podcast doesn't grow, that's not an indicator that we think the podcast isn't useful. It's just an indicator that we still don't know how to reach the other people, the students, the teachers, the engineers who don't listen to the amp hour. Okay, so do you want to do our ad now or do you want to talk about tools first you can do the ad live yeah all right let's let's do it let's do it okay we are sponsored by newark newark electronics and instead of telling you how cool they are I'm going to type in newark.com. Uh-oh. I wasn't prepared for this.

And we're going to play a game. So you should type in newark.com too. Okay, here I am. I'm on Newark. No, that's Newark. N-E-W-A-R-K. See, you shouldn't depend on me live typing on the podcast. Okay, here I am.

I'm on it. Okay, so now you are on newark.com. I am on newark.com. I am thinking of a part. Okay, what's the podcast? Okay, here I am. I'm on it. Okay, so now you are on Newark.com. I am on Newark.com. I am thinking of a part. Okay, what's the part? That is on Newark.com and you have to guess it. That seems okay. That seems difficult. They have a lot of parts.

It doesn't have to be just yes or no. You can ask me for things that are on the page that I'm looking at. Okay. Alright. Let's do it. Go. Oh, is it an ic yes i took too long uh does it have more pins than eight or or or less oh you said i, how many pins does it have? Four pins. Four pins. Is it a 555 timer? No.

That's all I know. Is it a comparator? No. Okay, it's four pins. Four pins? You could ask me for the manufacturer. You could ask me for the price. Who's the manufacturer?

NXP. NXP at four pins? Yes. Not eight pins, but four pins. But four pins. Four pins. Although if I count, it looks like there's eight, but it says here that there are four. Is it an eight-bit microcontroller? No. Oh, wow. Is it some sort of sensor? No. What does it do? No, I think that's too much. Okay. What doesn't it do um no i think that's that's that's too much okay what doesn't it do uh add or subtract things okay um i'm gonna go this is my final answer i'm gonna say it's a uh

it's a it's a uh it's a bipolar transistor you You're very, very close. Okay, give me a hint. Give me one more hint. It costs $282.38, and there are 63 in stock in the UK. So, wow. Okay, $280 for a four pin device only quality devices here I give up I give up

I'm not going to get it what is it it's an RF power transistor for high rugged and so it is the MRF 1K50HR5. Oh, they are four pins too. Those aren't really pins though. They're more paddles.

That was what I said when I counted. There was eight. All right. Well, thank you for playing. I have lost this game, but you did a good job picking something difficult and weird, expensive and small. And thank you to Newark for supporting the show. We really appreciate it. Yay, Newark!

You can try the coupon code, the voucher code, PODSAVE20, P-O-D-S-A-V-E 20, all caps. And that will get you something off. It might be 20%. It might be 5%. If you're in the U.S., it's more likely to get you more off. So if you need one of those $280 RF ruggedized power transistor things, you can get a fair amount off. Or a J-Link. Not that I know that that voucher would work on J-Links.

So I hear you got a J-Link recently. I did. You finally broke down and bought your own. Yeah, well, I mean, you make it sound like I've been avoiding them, but I thought I already had one. That's the problem. We usually borrow our clients' J-Links because then at the end of the project, when they hire someone new or they need to send the project to manufacturing, the J-Link goes with them. So finally, I already had one, but he needed one because we were using it at the same time. Yeah. And I first got it set up yesterday. So really, really making progress with that. But

I mean, I'm doing weird crap now. So to let you know, before you start on the topic, which I think is going to be the topic of the day. I have two, but okay. Well, yes, but it's... Anyway, in the annals of embedded development, I... So I have a new MacBook. I have one of the M1-based MacBook Pros. And ARM-based. ARM-based MacBook Pro, yes.

And we're doing a project. Both of us have the same client, and they're using a particular vendor's device, which we might talk about later. But anyway, lots of the usual Windows tools, right? So I am running Windows 11 ARM preview in a VM. So I have Windows ARM running on Mac ARM. In Parallels.

In Parallels, the VM host that I like. And that, and now the Mac will translate x86 code very efficiently. So that's not usually a problem. But running on Windows, Windows also needs to translate x86 code. So I've got a bunch of tools and IDEs and things that are running Windows x86 being

translated by Windows ARM, running in a VM host running on Mac ARM, and some drivers. It's been very complicated, but surprisingly everything works. I'm really surprised everything works. Oh, I am too. I was thinking I was going to have to switch to an Intel computer for this. But yeah, Jlink works, debugging works, VS Code, everything's working.

It's pretty cool. So the VS Code was my part of the puzzle recently. Well, not just VS Code, GCC too, right? Right. We switched from a pay-for compiler in a vendor IDE to GCC and VS Code. And, you know, I was led to believe this would all be very easy. Who led you to believe that? I don't know.

When we talked to Tyler, he made it sound so good. I mean, it is good. It's not easy. It is good, but it is not easy. Yeah, I wanted you to talk about this today because we have had recent shows where we've talked about tools. And you have said you hate tools with a fiery passion before even doing this. And yet somehow you ended up doing it. So tell me all about how you feel about it now. I still hate tools.

Oh, yeah, I still hate tools. So what did you have to do? Okay, so it started out, I needed to go to GCC away from a pay-for compiler because the team was growing. And so that's not that big a deal. That was done really quickly. Okay. But it turned out that it didn't have the debugging features we wanted in the vendor's

IDE. The vendor's IDE debugging was nonsensical to me. It was bare bones, real bare bones. You can't edit while you're debugging? It locks out the typey bits? Yeah, well, it puts a little lock symbol on all the tabs you've got, so you know. Oh my god, it was so awful.

I wanted to cry. As far as I could tell, it had a no RTOS integration. No. So you're basically in the thread you're in when you're debugging and that's pretty much it, and you don't know any details of stacks or anything. We could have lived with all of that except that there were flags that it would call GCC with that you could not change. Oh, for building?

For building. Oh. And so we had to get out of the IDE because we needed it to stop sending those terrible flags. Was one of the flags the very important use hardware floating point? It was. Yeah. Yeah. You know, sometimes if you have a hardware floating point, you should use it.

And why would your IDE disallow that? I mean, you might hurt yourself. Yeah. I mean, there are floating points. Right. The you might hurt yourself. Yeah. I mean, there are floating points. Right. The points might stick you. Yeah. So I needed to go to Make instead of their build system.

And now we're out of their build system. We need a new IDE, one that doesn't disable typing while you're debugging. Sorry, it was really traumatizing. And so VS Code, because everybody likes VS Code, and then people can run in their native environments instead of doing things like ARM Mac, Parallels, ARM Windows. Well, we're not there yet, but yes. That turned out not to be as important to the client as it was to me,

which is funny because I run Windows, so I was basically running the native versions. So I went over to VS Code, and Cortex debug is one of the most popular extensions to VS Code that lets you debug Cortexes, which is what I had. Okay, so does that do the work of talking to the JLINK and the GDB server and making that all hook into VS Code, or is that part of VS Code already? That was really confusing, because there are parts that are part of VS Code already, but this made the Cortex-specific things easier. For example, it takes one of the CMSIS SVD files that defines all of the registers for

each different type of processor from each different type of vendor. Oh, okay. Yeah, we talked to Reinhard about that a little bit. And so it takes those files and then you can look at your peripheral registers because they're all listed out there. And the Cortex debug makes that look pretty-ish. So you can actually see how you've got a particular SPI thing or whatever, timers, stuff like that configured. Or you can see as you step through the code when the GPIOs change, if you're looking at the GPIO registers.

Wow, okay. It also took in information about free RTOS, which we're using right now. And so that was nice because the old IDE, you didn't have any RTOS information. But one person had one type of programmer JTAG unit. One person had another type of programmer unit. Some people wanted to use Seger's system view to see where all the cycles were going. That required a different kind of JLINK. And of course, all these need to be supported in VS Code. And we're doing a multi-processor

thing, so which processor you're debugging when is always an adventure. And a firmware update thing, so security and dealing with post-build actions. It was just, the system was complex. The way to set it up was that there is a great series by MCU on Eclipse that I will link to in the show notes. And it tells you step by step how to go through it. And, you know, most of it was still very correct, very true. All of the extensions that they give you were very good.

MCU on Eclipse? I'm pretty sure that's, I mean, you know, it depends on... It's a blog post about VS Code on a website called MCU on Eclipse. Yes. That's fine. I'm just making sure because it's... It's by Eric Steiger. It's MCU on Eclipse, yes.

Okay, that's fine. But it says it's a four-part series, and then there are a up, you need to install this, and then you install this, you install this, and only this. It's this specific version. Do not install anything else or you will not be happy. It's an endless string of dependencies of very specific versions of things. It's very brittle, right?

Oh, so brittle. So the Cortex debug that I liked, I had installed it earlier because, you know, it was something I had looked at. It wasn't something I had used. And I was talking to one of my teammates who said that my launch script had weird things happening. It was giving him errors. And I updated to the latest just to make sure. And then finally screen shared to see what was different. And I updated to the latest. I pushed the button that said update to the latest. And Chris watched me later,

push the button that said update to the latest. And I was getting like 0.4.91, and everybody else had 1.3.2 or something. And it was, you know, the extension didn't update to the 0 to 1. And then when I went and uninstalled and reinstalled and opened my VS Code and closed it and rebooted, I eventually got to the— That's not what happened. Got to the new one. What happened? Do you remember what happened? No, what happened?

You were running a nine-month-old version of VS Code. Oh, right. Somehow you hadn't updated VS Code. Right. Which is weird because it auto-updates, so you must have just had the same VS Code open for a year. No, I don't know. I don't know what happened there.

Well, that's not actually... That was what I think happened is the plugin didn't update because it wasn't compatible with the newer version of VS Code, which you did not have. But then there was also, I used, I started out with I needed GNU

ARM 9 GCC. MSIS and SIGWIN and WSL. But that wasn't the problem. The problem was that I started out with the ARM GNU tools. Yeah. The version 10 and below tools. And then in February, I think, I mean, just a couple of months ago,

it switched to GNU ARM tools, where ARM started releasing it instead of GNU starting to release it. And so the GNU site was deprecated, and I had to go to the ARM site, which had different rules about how to set things up. And then I had to do it in MinGW, except that didn't work, and I ended up with Emsys, and it was just really, really gross. There was no push the button, and it all just works, even though what I wanted was super standard. And the people who are screaming Docker at us at this point, go for it. Docker does not solve this problem. Windows. This is Windows.

Well, and then it turns out that, okay, so you're like, Python 2 no longer exists. You can't do anything with Python 2. Just delete it from your system. Except GNU ARM EAB8 NONE GDB depends on a specific version of Python 2.8. And not just 2.8, but 2.8 point something. I mean, it's just, how do we get anything done? This is why people pay for compilers, because they have a whole build system you don't have to mess with. I don't want a new pet. And I know now every time anybody has build problems, they're going to come to me and I'm like, I hate tools so much.

I think at least 60% of the problem is Windows. Because if you're doing this on Linux, a lot of this stuff is not as difficult because you're not trying to figure out how to recreate a Linux environment. There was that. I would have been happy to go to a Linux system. But we can't really because we still have some vendor tools we have to run to a Linux system. But we can't, really, because... The vendor has tools. We still have some vendor tools we have to run to configure the device that are part of an IDE

that we won't use for anything else. So, yeah, it's just... The tool situation is getting... It's getting better in kind of a weird, random walkway. Like, the individual tools are getting much better. Like, VS Code, love it. It's great. It's like Emacs from the future, as far Code, love it. It's great. It's like Emacs from the future as far as I'm concerned. It's great.

But all the stuff that surrounds it, you've got to still build out of some of this older kind of things that have a lot of baggage and legacy. Windows being one of them. I'm on Windows 11. Why am I still... I mean, we could have used... That was one problem with me being on Windows Arms.

WSL is totally messed up for doing that in a virtualization. Because you couldn't have a virtualization inside a virtualization. Yeah. Which you sort of can do, but Parallels for ARM doesn't support that yet. So that's a mess. There were two people on the team who had that problem, so it wasn't just you. Okay, well, anyway. So that's a mess. There were two people on the team who had that problem, so it wasn't just you. Okay, well, anyway.

And that's a side thing. But yeah, I mean, a lot of it's like, okay, we need to get to a POSIX-like environment to make these tools work in Windows. And there's three ways to do that. And for each of those three ways, there's 10 ways to mess it up. And setting up the J-Link debugger,

which I finally got everybody on J-Link, so I don't have to support OpenOCD. Yeah. But there's still different ways to set up the debugger. And when I do it manually, it capitalizes my part number. And when I capitalize the part number in the auto form, in the launch files, it says that part doesn't exist.

And I'm just like, really, people? My favorite thing was that most of the time, all of these things fail without an error message or with an error message that makes no sense. So like VS Code, remember that thing I had, was it this morning I was trying to? Yeah, yeah, it needed. Oh, it needed Python 3 because our build.

Oh, no, no, it was when I needed Python 2. Oh, that was terrible. So yesterday, I needed Python 2. So build... Oh, no, no, it was when I needed Python 2. Oh, that was terrible. I needed Python 2. So I'd say, okay, I'm all done. I got everything set up. Push go for debug in VS Code. And it starts and connects and says, yeah, GDB server had a problem. That's the message. And it didn't even look

like the GDB server had a problem. The GDB server says, well, nobody ever talked to me. Right. If you go to the verbose output in the terminal, it says, GDB server says, well, nobody ever talked to me. Right. If you go to the verbose output in the terminal, it says, GDB server, everything's great. Waiting to connect. Yeah. And it's like, okay. And that was because there wasn't a 2.8 DLL available for it.

I didn't have Python 2.7.16 or 2.8.16, whatever it is. And without someone knowing what that means, I do not know how you solved that problem. How did you figure that out? I did it all on command line initially, before I set up the launch files. But how did you know you needed Python 2.7? Did it say, where's my Python? Because at some point when you're not using the command line tools,

when you're stumbling around using GDB, I got an error. All right. Like, maybe it was like I didn't type no GUI on something, and so therefore it actually did pop up an error window. Yeah, it was awful. Oh, I also had to reconfigure my J-Link to work on Windows ARM. Right.

Because there's no... Sega's gotten rid of the... They had a J-Link driver, USB driver, that used to be specific, and then there's now a WinUSB driver, which is more universal. It works on ARM and Intel. But in order to reconfigure your J-Link,

you have to plug it into an Intel Windows computer and run the J-Link configurator because you can't run the J-Link configurator on the ARM because you can't talk to it. Yeah, so you have to toggle something on the configurator and then you can plug it into your ARM Windows and it's happy. So why am I doing this?

It's because I have a new computer and it's fast and good, and this is, but everyone's behind, at least from Windows. I think the nice thing about all this is now I can move at least some of this stuff to native Mac, I think,

and be happy doing development on native Mac without doing any of this Windows stuff. I can show you how to change the launch file and the build file to have a different operating system. It's getting harm and all that stuff installed. Yes, good luck on that.

I'm not participating in tools. I'm going to do it in Conda, and it's going to be fine. Yeah, sigh. Anyway, yeah, that's the other thing, is now that all this stuff is set up, at some point, the client should consider making it. Oh it we have a build server now a deployable thing oh no we don't have that

a conda yammer something like that yeah i think i think that is on the list but uh the client realized that if they asked me for that it was going to be another six months but now i'm doing more entertaining things that if they asked me for that, it was going to be another six months. Ex-client. But now I'm doing more entertaining things. Okay, so the other thing I had on my list to talk with you about comes from my class per class. My students keep having a lot of questions about interrupts. And I understand why. They're at that point in the book.

And for the ones who haven't experienced interrupts in the past, it's kind of a new topic. Yeah. But I have, there's so much a part of my brain now that I sometimes wonder why they're so hard. I've lost the beginner mind on that. A little bit, maybe, yeah. I think it's because of the non-concurrency kind of,

or the concurrency aspect of it. I think when beginners learn to code, even now still, they learn in the kind of 1980s basic, okay, here's a series of steps, that's a recipe that the computer does. Line 10, print hello. Line 20, go to line 10.

And introducing something that can just say, what did the Hawaiian punch guy? It's the Hawaiian punch guy coming through the wall. I know what you're saying, but he said something? Yeah, yeah, yeah, anyway. It's a difficult way of thinking because now this thing can come in and it can touch everything you're already it can you know toss the room change all your data and then you come back and you don't even know that happened um you know that's the whole multi-threading problem and i think interrupts are a way in a way are harder than multi-threading problem. And I think interrupts are a way,

in a way are harder than multi-threading because you feel like you have control of, when you write multi-threading stuff, you feel like you have a control of the whole architecture. But with interrupts, it's like, this is how this works. And this piece of code,

that's not really something you, really something you really devised except to handle this thing is here now and it just jumps in. I don't know. Your point about concurrency is probably right. For the folks that don't have a software background, the idea of concurrency is probably strange. I mean, you see it completely in FPGAs, but it's different than the concurrency we get from threads and interrupts. I wonder if that's what I need to do. I need to go back and say, let's talk about concurrency. Yeah, because all the problems are the same, right? You have race conditions.

You have race conditions, you have shared resources, you have timing issues, and all of those things. I mean, that's how I was always thought of interrupts as a high priority thread preempting me. And most of the principles are exactly the same. The only difference is there's this hardware component that you have to think about. It's tied to a particular piece of hardware. There's priorities associated with that. You have to configure them differently. But yeah.

That's good. I should take a step back and think about stop answering the little questions and deal with the big ones. What are some of their little questions? One person had a question about ISRs versus asserts versus callbacks. Are they all the same thing? Oh, I see. And I can see how they got there, because I do sometimes think about interrupt service routines as callbacks, although it's callbacks from the hardware.

And it's not really the same as a callback that you get when you send it to a hardware abstraction layer and it calls you when your spy is done. That's not really the same at all. Yeah, no, it's different. I think the way to think about asserts versus ISRs is an assert is you jumping out the window when your house is on fire, whereas an interrupt is getting a phone call. Voluntary defenestration versus... Getting a phone call. Getting a phone call. In the middle of what you were doing.

In the middle of dinner. Yeah. No, asserts are completely different. Asserts is this condition is not as I expected. Stop everything. Asserts can lead to hard fault interrupts. It's a software. Hard fault interrupt.

I mean, it's a non-maskable interrupt. Yeah, sure. And so an assert can lead to an interrupt. Okay. And then be treated like it was a hard fault. And if you have hard fault logging, it goes in there. It doesn't have to be, though. It doesn't have to be.

An assert can actually be caught and logged, and then you reset yourself or whatever. If you're running in release, sometimes you turn off all the asserts so that you're not halting and you're just logging stuff. I always question that. The merits of that aside um yeah and a callback is just a general class of things it is a function that you hand to somebody to call you back if this was the 25 000 pyramid you just lost yeah but i mean it's such a general thing right it's like uh you can have it like in graphics libraries um often you'll associate a callback with a particular

window and it says draw my window and they say give us a callback so we can draw the contents of this window and because when we come when the gui library comes around to time to draw the window it needs to do it. And you want to pass it the code to do that. And so you hand it a callback, which is a function pointer. And then the GUI library has this pointer, and it doesn't have to know what it is. It says, oh, time to draw this window, and they gave me this function, and I can go draw it. And you can do that with HALs for various reasons, hardware abstraction layers, where it's like, okay, this is a handler.

It's just a way of handling code you didn't write, something so that it can hook into the code you did write. But this goes back to concurrency, because if you are a linear serial thinker, you're all in one path, then callbacks make no sense. Right, because who's calling it back? Oh, yeah, that can't be right. Where is that coming from? I mean, it should just return. It shouldn't call you back. A callback implies that multiple things are going on and asynchronous things are happening and you are blocking or waiting or sleeping until they're done.

Yeah, and of course with more modern languages all this stuff gets much more prevalent. You have lambdas, which are basically callbacks that you define in the place that you hand them. You just write the code instead of have a function pointer. You say, here's my callback, bracket, bunch of code.

It's like an inline function. Yeah, it is. And with asynchronous stuff, I mean, with modern languages, all have asynchronous primitives so that stuff can happen. Concurrently is a little weird because sometimes it's a lie. Like if you have one CPU, concurrency isn't really happening. There's a single flow of execution,

but things are being sliced up so that it's moving around between those things that seem like they're running at the same time. If you have multiple CPUs, then yes, in multiple threads, those can run at the same time. The illusion of concurrency. That's my new band name. Anyway, I don't, yeah. Yeah, it's hard. I mean, a lot of these are fundamental concepts that are getting mapped onto things like ISRs. And if I could do better with the fundamental concept, I think that would work better. And I think ISRs are confusing, too, because there's a lot of mechanics around them that I don't get to do with the fundamental concepts that are tricky and weird, right? When do, if I am in my ISR, when do I have to clear my ISR cause and does the processor or Hal or somebody else do that for me?

And if I disable an interrupt and it happens while I am in my interrupt, what happens? Yeah, they had a lot of... See, those have nothing to do with concurrency because threads you don't have to be crazy careful about, you know, necessarily, oh, I got to get out of here as quickly as possible because you might have architectured your system and the thread can run a long time.

But in ISR, you want to do as little as possible because it's not doing stuff you want it to do. It's keeping everything else busy. Yeah, all those little questions about it. And even I don't know those answers. It isn't consistent. Yeah, it's not consistent. And then there's interrupts that can be queued.

And nested. I mean, nested and prioritized. So it all gets very complicated. And that stuff starts to overwhelm you when you're learning, and you kind of might lose sight of the other stuff. And so it all gets mishmashed into, this is complicated, and I don't get it. Yeah, I think I made a joke in one of my lectures about how it's really important to know about the nested and interrupt priorities, just as it's really important to know about, I don't even remember what the other thing was, but it was something entirely pointless.

It was like, yes, you need to know those words, but no, please don't read that chapter in the manual until you absolutely have to. Yeah. Yeah, and the more complicated the chip is, the more complicated the interrupt system is. And there's plenty that can have interrupts that interrupt interrupt stack. Anyway, let's see. They also had what happens when an interrupt isn't handled. Yeah.

Well, generally you crash. No. I mean, that doesn't have to be. It depends on how your vector table is set up. And almost all have... But by default, the hells crash you. They put you in an infinite loop. Yeah. Okay. Crash is the wrong word.

They do not just silently say, well, I don't know what that was. I guess it's okay. Yes. But you can let it be okay, which is dangerous. What is the answer to why does my program crash if I don't handle this interrupt? It seems intuitively from a naive observer, well, I'm going to write handlers for the things I care about and anything else I don't care about, so it should just do nothing.

But you need to know that those interrupts are happening and not being handled because they will affect your processor speed. And so you find those out and then you turn them off and then you never have to deal with them again. Right. Still be nice. The infinite loop is not the nicest response. Yeah, true, true, true, true.

I'm just thinking of Unix, you know, if you have signals and stuff. Yeah, I think uncaught signals. I don't remember what happens with uncaught signals. Like if I give it a user signal, does it stop my program or does it ignore it? It probably ignores it or has a default at the end that says unhandled signals. Anyway, yeah. Well, but that's another thing that's different between PALs, right? You said?

Oh, totally. And your vector table could be written in assembly, or it could be written in C, and how your functions are, how your interrupt service routines are handled, and then the whole week keyword. Oh, yeah, the week keyword's cool, yeah. I don't remember being taught the week keyword. Do you know when it came? I think it's a C99 thing.

That would explain why it's always been a little new and nifty to me, which only dates me. Well, no, I mean, I've only come across it when I've had to do library stuff. I mean, the weak keyword is basically a C++ virtual function. Oh, that's a way to look at it. I mean, it just says this can be overridden, right? Yeah.

So that's what it is. And we use it in interrupts because the HAL will put all of the interrupts to a default interrupt handler, which is the one that loops. And then when you come along and you want to have an ISR spy to handler, you use the same name, then you don't have to change the vector table. And it calls your function because the other one is a weak function and yours is strong, normal, adequate.

I'm not sure this is a C feature. I think this is a GCC feature. All of the other embedded compilers I've been using lately have it. Yeah, everybody has it. So it may just be a feature that everybody has and isn't really part of the other embedded compilers I've been using lately have it. Yeah. So it may just be a feature that everybody has and isn't really part of the language. I'm not sure it's part of the language. I think it's been added. Yeah. Interesting.

Yeah, that's one of those things that you don't come across too often unless you're deep in the weeds. More things about class. The students keep finding bugs in my book and it's killing me. It's been out for a while and they're finding new things. And I kind of want to say, could you read a little less intensely?

Because I'm really sorry. This is from a person who i caught last night playing a video game that is apparently copy editing books and you score points for copy editing and do you realize you're not getting paid for this it was fun is this like simon and schuster outsources copy editing no they use classics. Oh, okay. They mess up public domain books. I was reading Pride and Prejudice, and it was messed up.

And then I was reading Japanese fairy tales. Okay. No, no, no. It's called Dear Reader, if anybody really wants to know. Pretty silly. Well, you have talked about you know doing a second edition which would allow you to make all new typos yes i have talked about that and it may happen um i think it's mostly a matter of how much time i have over the next year more More than anything. I have a long list of things that I

would put into a second edition. So, you know, I have a lot of ideas. It's just do I have a lot of time for writing. Weak symbols are not mentioned by the C or C++ language standards. As such, inserting them into code is not very portable. Not very portable. And yet we're going to do it anyway. Well, sometimes you got to do what you got to do. Actually, you know, I don't know if the PIC compiler allowed weak symbols. That was the last one I messed with the vector table on. And that was only like a year ago.

Doubted. I mean, it's a linker thing, right? Well, I mean, it has to be acceptable to the compiler, and it's actually directed towards the linker. I've been doing a lot of link files lately. I guess once you give a talk about map files, everybody expects

you to fix their linker files. Back on the interrupts for a second. This all excludes the complexity of dealing with the RTOS if you're using an RTOS with the interrupts for a second. This all excludes the complexity of dealing with the RTOS if you're using an RTOS with the interrupts too, which adds more stuff you got to worry about. Like what? Like how do you get from the interrupt to your code? You just put a semaphore out.

Okay, or a message. But yeah, you just do one. But you don't wait for a mutex. Anyway, it's just, there's more stuff to do. Yeah. You don't just set a global variable or something or stomp on your shared resource. I do have a couple more things to talk about. I'm still playing with Wakui and I'm still enjoying it.

You're using it for the class, right? I'm using it for the class. I'm using the C-based Raspberry Pi Pico simulator. Okay. And I have a command line system on that that you can type to. Oh. So people can see in demonstration what I mean when I talk about those. And I have one that shows off PWMs in duty cycle and frequency using LEDs and speakers. And it even has a little logic analyzer on there.

It was really cute. I was very happy with how that came out. And it'll export the logic analyzer data to a file. And you can open that in the thing that i forget the name yes pulse view yes when you stop simulating it downloads a file and then you can see what it was and it's just like looking at a salient pretty cool you know um let's see there were a couple things in patreon slack um first there is a the book club is starting a new book in the Patreon Slack for Embedded, and they're going to go through Alan Cohen's Prototype to Product.

Oh, excellent. Which is a pretty massive book, and I don't think they're going super fast, so you can still catch up if you want to. Let's see. Also in there was an interesting question. If you have a 900-page data sheet, what sections do you read regardless of your particular application? If I have a 900-page data sheet, the section I read is the termination criterion for my contract.

That's not true. You and I are both working on it. 1,400-page. contract. That's not true. You and I are both working on it. 1,400 page. What? That's not a data sheet. Manual or whatever. Well, the one I've got is only 180. Yeah.

All right. What section? Using the other one soon. What section? You're asking? Yeah. I gave an answer in the Slack, but I think the answer I really want to give is

if they have an application note section, I kind of like to look at that first to get an idea of how you're supposed to use the thing. And sometimes they'll... There used to be app notes, which... There still are. There still are, but a lot of times you just get the data sheet these days,

and they'll have application sections, which walk you through, here's how to configure this for a reasonable situation, and you do this. And it's got more of a higher level kind of, this is how the code might work to set up and use the device than just going through the 500 pages. I'm assuming, I'm still stuck on 900 pages. Like, what is that thing? Is it a, I mean, is that the ARM reference manual? I mean, some of the TI chips, basically, they throw everything in, in some files.

Yeah. For me, I said, and I stand stand by i read the table of contents yeah i mean that's that's fair because i want to know what's in it yeah i don't really i mean the introduction well it's not always they have a references table which i guess is kind of what you were talking about the the thing the question isn't what do you read first it's what you were talking about. The thing, the question isn't what do you read first, it's what do you always read, regardless of your application. And so the files it points to, the table of contents, an introduction, and if there's something called the getting started area, I read that part. I jokingly answered earlier, errata. That was a good and funny answer, although not true for me

because I tend to not read the errata until it's far, far too late. And then if you've got multiple versions of it that are just different for different packages, you diff them. I've been burned by that before. Hey, why is this register diagram different for this, which is the only difference by pack? It's a typo. Oh, nice. Yeah, yeah, yeah. I guess to turn the question around, it's like,

what sections do you wish every datasheet had? And I definitely want application notes. Like, tell me how you think someone should use this thing. Because if it's just registers and, you know, the block diagram, that's not enough. And if 90% of your registers are undocumented, at least tell me 90% of the registers are undocumented and what you'd like

me to put in them so I don't have to scrape the internet for somebody else's driver that happens to know what to program in the undocumented registers of your device. Seems awfully specific. What? Are you having this problem currently on two different parts?

No, only one. The other one's well-documented. It's the display controller. Apparently this is common for display controllers. There's just blocks of registers that there's lore and, you know, ancestral knowledge of what to program in them. And people just pass it down from GitHub to GitHub. You hope you get it right.

And then there's like eight registers that actually do stuff that you can configure, but the rest are just, who knows? Incantations. And register 98, put the following 12 bytes. Uh,

we saw, I saw some other stuff on the Patreon. Um, Philip Johnston of Embedded Art tyler hoffman of memfault both people we've had on the show a couple times are kicking off a quarterly embedded discussion panel the first one happened today and it was focused on the use of device metrics. Cool. Which we talked about a little bit on the show, but I bet they have another person from the Fitbit team.

Sure. And they recorded that, so I will link that in the show notes. I haven't seen it yet, but I am confident it's going to be good and that their future ones will be good. And it turned out there was a wait list for this, so you might want to take a look and make sure you are on the next one. And the link will be in the show notes. And they had a registration page, and you could pre-populate questions if you had them for the panel to answer? At Goliath, where Chris Gamble and Jonathan Berry work, also former guests, have been working on USB from WSL, which is pretty phenomenal. So there was a blog post about that that I found pretty entertaining. Yeah, that closes one major

hole in the WSL story for doing embedded development. So that's good. Progress is being made there. The last one was somebody's project that was made in the New York Times,

which was pretty cool. It's a new aircraft being built in Vermont that has no need for jet fuel. Take off without a runway. I mean, is it a kite? No. Oh. No, no. Well, then I don't know how it works.

It's pretty cool. I mean, it looks like an airplane. But it's not. All right. All right. All right. Well, I think that covers it for everything I had. Well, and Winnie the Pooh this week is actually really related to some career stuff.

Yeah, but you need to close the show first. Oh, I shouldn't just start reading? You shouldn't. Just start reading. Oh, hey, it's Zia. Thank you to Christopher for producing and co-hosting. Thank you for listening. Thank our Patreon listener Slack group for some questions. Thank my students for their many, many questions on ClassPert. And our email is

show at embedded, or you can hit the contact link on embedded.fm. And thank you to Newark for sponsoring this week's show. And you can go to newark.com and when you check out, use podsave20 to get a discount

of some number, you're telling me, that may vary regionally. Zero to 20%. I think zero is disappointing. It's still fine. You should still use the voucher. Okay. But, you know, it's kind of like a lottery. It's exciting now.

All right. Thanks, Newark. Chapter 5, In Which Piglet Meets a Heffalump One day, when Christopher Robin and Winnie the Pooh and Piglet were all talking together, Christopher Robin finished the mouthful he was eating and said carelessly, I saw a heffalump today, Piglet. What was it doing? asked Piglet. Just lumping along, said Christopher Robin. I don't think it saw me. I saw one once? asked Piglet. Just lumping along, said Christopher Robin.

I don't think it saw me. I saw one once, said Piglet. At least I think I did, he said. Only perhaps it wasn't. So did I, said Pooh, wondering what a heffalump was. You don't see them often, said Christopher Robin. Not now, said Piglet. Not at this time of the year, said Christopher Robin. Not now, said Piglet. Not at this time of the year, said Pooh.