410: Emacs From the Future
Transcript from 410: Emacs From the Future with Elecia White and Christopher White.
EW (00:07):
Welcome to Embedded. I am Elecia White, here with Christopher White, and today it's just us chatting about tools, and interrupts, and whatever else we feel like
CW (00:21):
Okey dokey. Let's do it.
EW (00:23):
How are you doing?
CW (00:24):
I'm excited to be here.
EW (00:26):
Are you?
CW (00:26):
Always.
EW (00:28):
Pretty sure he shook his head when he said that.
CW (00:30):
It was more of a diagonal nod.
EW (00:32):
Okay.
CW (00:33):
Yeah. No, I'm doing too much. Doing too much.
EW (00:36):
What are you up to these days?
CW (00:37):
I have clients that want me to do things for them.
EW (00:41):
That's terrible.
CW (00:42):
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. Yeah, mostly working.
CW (01:03):
I'm practicing a lot of music, but I'm not writing a lot or recording a lot. So I did send out a plea on Twitter for, if anybody needs drums or bass on anything, I'm available.
EW (01:16):
You've been practicing playing really fast. Has it affected your typing?
CW (01:20):
No. What? My typing is as poor as it has been since the '80s, since I learned poorly on an Apple II Plus keyboard.
EW (01:34):
I have a couple of notes from the last time you and I talked.
CW (01:39):
Okay.
EW (01:40):
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.
CW (02:00):
Okay, fine. We won't do that.
EW (02:02):
And then I get an email that was concerned that the show has to grow, because we have been pushing growth, or it will die.
CW (02:12):
Yeah.
EW (02:12):
And that was never it.
CW (02:14):
Everything dies.
EW (02:16):
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.
CW (02:24):
Well, certainly if we start to have way less listeners at some point.
EW (02:29):
Yes.
CW (02:29):
If nobody's listening to us, which I don't know why I want people to listen to me, but anyway, yes, there's -
EW (02:36):
But there was some concern that it was grow or stop doing it. And that wasn't it. It was -
CW (02:41):
Yeah.
EW (02:42):
- 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.
CW (02:54):
Yeah. Yeah.
EW (02:56):
And we hate trying new things. So we've been in that for a while.
CW (02:58):
Yeah, yeah.
EW (03:00):
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?
CW (03:28):
You're going to do the ad live?
EW (03:29):
Yeah.
CW (03:30):
Alright. Let's do it. Let's do it.
EW (03:33):
Okay. We are sponsored by Newark -
CW (03:36):
Newark!
EW (03:36):
- Electronics. And instead of telling you how cool they are, I'm going to type in newark.com, -
CW (03:45):
Uh-oh. I wasn't prepared for this.
EW (03:47):
- and we're going to play a game. So you should type in newark.com too.
CW (03:51):
Okay. Here I am. I'm on Newark. No, that's "new aardvark."
EW (03:55):
N-E-W-A-R-K.
CW (03:57):
See, you shouldn't depend on me live-typing on the podcast. Okay. Here I am. I'm on it.
EW (04:02):
Okay.
CW (04:02):
Alright.
EW (04:02):
So now you are on newark.com.
CW (04:05):
I am on newark.com.
EW (04:07):
I am thinking of a part -
CW (04:08):
Okay. What's the part?
EW (04:09):
- that is on newark.com.
CW (04:11):
Okay.
EW (04:11):
And you have to guess it.
CW (04:13):
..Okay. That seems difficult. They have a lot of parts.
EW (04:16):
It doesn't have to be just yes or no.
CW (04:17):
Okay.
EW (04:17):
You can ask me for things that are on the page that I'm looking at.
CW (04:20):
Okay. Alright. Let's do it.
EW (04:24):
Go.
CW (04:24):
Oh, is it an IC?
EW (04:31):
[Pause]. Yes.
CW (04:31):
That took too long. Does it have more pins than eight or less?...How many pins does it have?
EW (04:43):
Four pins.
CW (04:43):
Four pins. Is it a 555 timer?
EW (04:47):
No.
CW (04:47):
That's all I know. Is it a comparator?
EW (04:51):
No.
CW (04:52):
Okay. It's four pins. Four pins?
EW (04:55):
You could ask me for the manufacturer.
CW (04:58):
Okay, -
EW (04:58):
You could ask me for the price.
CW (04:59):
Who's the manufacturer?
EW (05:01):
NXP.
CW (05:02):
NXP and four pins?
EW (05:04):
Yes.
CW (05:05):
Not eight pins, but four pins.
EW (05:06):
But four pins.
CW (05:07):
Four pins.
EW (05:08):
Although if I count, it looks like there's eight, but it says here that there are four.
CW (05:14):
Is it an 8-bit microcontroller?
EW (05:16):
No.
CW (05:17):
Oh, wow. Is it some sort of sensor?
EW (05:19):
No.
CW (05:21):
What does it do?
EW (05:23):
No, I think that's too much.
CW (05:27):
Okay. What doesn't it do?
EW (05:29):
Add or subtract things.
CW (05:33):
Okay...Here's my final answer. I'm going to say it's a bipolar transistor.
EW (05:44):
You're very, very close.
CW (05:46):
Okay. Give me a hint. Give me one more hint.
EW (05:49):
It costs $282.38, and there are 63 in stock in the UK.
CW (06:02):
So, wow. Okay. $280 for a 4-pin device.
EW (06:07):
Only quality devices here.
CW (06:09):
I give up. I give up...I'm not going to get it. What is it?
EW (06:14):
It's an RF power transistor for high rugged -
CW (06:19):
High rugged.
EW (06:21):
And so it is the MRF1K50HR5.
CW (06:29):
They are four pins too. Those aren't really pins though. They're more paddles.
EW (06:33):
That was what I said when I counted there were eight.
CW (06:36):
Alright. Well, thank you for playing. I've lost this game, but you did a good job picking something difficult, and weird, expensive, and small.
EW (06:46):
And thank you to Newark for supporting the show. We really appreciate it.
CW (06:50):
Yay, Newark.
EW (06:52):
You can try the coupon code, the voucher code PODSAVE20, P-O-D-S-A-V-E20, 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.
CW (07:10):
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.
EW (07:25):
So I hear you got a J-link recently.
CW (07:26):
I did.
EW (07:27):
You finally broke down and bought your own.
CW (07:30):
Yeah. Well, I mean, you make it sound like I've been avoiding them. I thought I already had one is the problem.
EW (07:38):
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. And...I already had one, but he needed one, because we were using it at the same time.
CW (07:52):
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 -
EW (08:09):
I have two, but okay.
CW (08:10):
Well, yes, but anyway, in the annals of embedded development...I have a new MacBook. I have one of the M1-based MacBook Pros.
EW (08:24):
And Arm-based.
CW (08:24):
Arm-based MacBook pro.
EW (08:25):
Right.
CW (08:25):
Yes. And we're doing a project. Both of us have the same client, and they are 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
EW (08:52):
In Parallels.
CW (08:52):
In Parallels, -
EW (08:53):
Okay.
CW (08:53):
- the VM host that I like. 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.
CW (09:08):
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. And it's been very complicated, but surprisingly, everything works.
EW (09:23):
I'm really surprised everything works.
CW (09:24):
Oh, I am too. I was thinking I was going to have to switch to an Intel computer for this, but yeah, J-link works. Debugging works. VS Code, everything's working. It's pretty cool.
EW (09:37):
So the VS Code was my part of the puzzle recently.
CW (09:41):
Well, not just VS Code, GCC too, right?
EW (09:43):
Right. We switched from a pay-for compiler in a vendor IDE to GCC and VS Code. And I was led to believe this would all be very easy.
CW (09:58):
Who led you to believe that?
EW (10:00):
I don't know. When we talked to Tyler, he made it sound so good.
CW (10:04):
I mean, it is good.
EW (10:05):
It is -
CW (10:05):
It's not easy.
EW (10:06):
- good, but it is not easy.
CW (10:09):
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.
EW (10:26):
I still hate tools. Oh, yeah. I still hate tools.
CW (10:30):
So...what did you have to do?
EW (10:33):
Okay. So it started out, I needed to go to GCC away from a pay-for compiler because the team is growing. And so that's not that big a deal. That was done really quickly.
CW (10:46):
Okay.
EW (10:46):
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. I mean, it was just -
CW (10:59):
It was bare bones, real bare bones.
EW (11:01):
You can't edit while you're debugging? It locks out the typey bits?
CW (11:08):
Yeah. Well, it puts a little lock symbol on all the tabs you've got so you know.
EW (11:12):
Oh, God, it was so awful. I wanted to cry.
CW (11:15):
As far as I could tell it had no RTOS integration.
EW (11:18):
No.
CW (11:18):
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.
EW (11:27):
We could have lived with all of that -
CW (11:28):
Yeah.
EW (11:28):
- except that there were flags that it would call GCC with that you could not change.
CW (11:37):
Oh. Oh, for building.
EW (11:39):
For building.
CW (11:40):
Oh.
EW (11:41):
And so we had to get out of the IDE, because we needed it to stop sending those terrible flags.
CW (11:48):
Was one of the flags the very important use hardware floating-point?
EW (11:52):
It was.
CW (11:53):
Yeah.
EW (11:53):
Yeah. Sometimes if you have a hardware floating-point, you should use it. And why would your IDE disallow that?
CW (12:02):
I mean, you might hurt yourself.
EW (12:04):
Yeah.
CW (12:04):
I mean, they are floating-points.
EW (12:06):
Right. The points might stick you.
CW (12:08):
Yeah.
EW (12:09):
So I needed to go to Make, instead of their build system, and then 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.
EW (12:27):
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.
CW (12:37):
Well, we're not there yet, but yes.
EW (12:40):
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 ahead.
CW (13:04):
Okay....So does that do the work of talking to the J-link and the GDB server and making that all hook into VS Code, or is that part of VS Code already?
EW (13:15):
That was really confusing, because there are parts that are part of VS Code already.
CW (13:20):
Okay.
EW (13:21):
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.
CW (13:36):
Oh, okay. Yeah. We talked to Reinhard Keil about that a little bit.
EW (13:38):
About that. Yeah. And so it takes those files and then you can look at your peripheral registers, because they're all listed out there.
CW (13:48):
Right.
EW (13:48):
And the Cortex-Debug makes that look pretty-ish.
CW (13:53):
So you can actually see how you've got a particular SPI thing or whatever, timers, stuff like that configured.
EW (14:03):
Or you can see as you step through the code when the GPIOS change, if you're looking at the GPIO registers.
CW (14:08):
Oh. Wow. Okay.
EW (14:09):
It also took in information about FreeRTOS, 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.
EW (14:36):
Some people wanted to use SEGGER's SystemView to see where all the cycles were going. That required a different kind of J-link. And of course all these need to be supported in VS Code.
EW (14:49):
And we're doing a multiprocessor 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. And...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.
EW (15:17):
And it tells you, step by step, how to go through it. And most of it was still very correct. Very true. All of the extensions that they give you were very good.
CW (15:26):
MCU on Eclipse?
EW (15:27):
I'm pretty sure...I mean, it depends on -
CW (15:31):
It's a blog post about VS Code on a website called MCU on Eclipse.
EW (15:35):
Yes.
CW (15:35):
That's fine.
EW (15:36):
Yes.
CW (15:36):
I'm just making sure, because... -
EW (15:40):
It's by Erich Styger.
CW (15:43):
Okay.
EW (15:43):
It's MCU on Eclipse. Yes.
CW (15:45):
Okay. That's fine.
EW (15:46):
But it says it's a four-part series, and then there a couple more and a couple more. And then it turns out to be a nine-part series.
CW (15:52):
So one of the things that I found difficult watching you go through this process was the usual thing of, "Okay, in order to set this up, you need to install this. And then you install this, but you install this, and only this, at this specific version. Do not install anything else, or you will not be happy."
CW (16:15):
And it's an endless string of dependencies of very specific versions of things. It's very brittle, right?
EW (16:23):
Oh, so brittle. So the Cortex-Debug that I liked, I had installed it earlier, because it was something I had looked at. It wasn't something I'd used. And I was talking to one of my teammates who said that my launch script -
CW (16:39):
Doesn't work.
EW (16:40):
- had weird things happening.
CW (16:40):
Yeah.
EW (16:41):
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.
EW (17:00):
And I was getting 0.4.91, and everybody else had 1.3.2 or something. And...the extension didn't update to the zero to one. And then when I went, and uninstalled, and reinstalled, and...opened my VS Code, and closed it, and rebooted, I eventually got to the -
CW (17:24):
That's not what happened.
EW (17:25):
- to the new one. What happened?
CW (17:27):
Do you remember what happened?
EW (17:27):
No. What happened?
CW (17:28):
You were running a nine-month-old version of VS Code.
EW (17:32):
Oh, right.
CW (17:33):
Somehow you hadn't updated VS Code.
EW (17:35):
Right.
CW (17:36):
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.
EW (17:43):
Well, that's not actually -
CW (17:43):
But that was what I think happened, is the plugin didn't update, because it wasn't compatible with the newer version -
EW (17:48):
Yeah.
CW (17:48):
- of VS code, which you did not have.
EW (17:50):
But then...also, I started out with... -
CW (18:00):
Oh, GNU, -
EW (18:00):
- GNU arm-none-eabi -
CW (18:01):
- all the tools and stuff. Yeah.
EW (18:02):
- GCC.
CW (18:03):
MSys, and Cygwin, and WSL.
EW (18:06):
But that wasn't the problem.
CW (18:07):
Yeah.
EW (18:07):
The problem was that I started out with the Arm GNU tools.
CW (18:14):
Yeah.
EW (18:15):
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 really seen 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.
EW (18:38):
And then I had to do it in MinGW, except that didn't work. And I ended up with MSys, 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.
CW (18:53):
And the people who are screaming Docker at us at this point, -
EW (18:56):
I know.
CW (18:56):
- go for it. Docker does not solve this problem.
EW (18:58):
Windows.
CW (18:58):
This is Windows.
EW (19:00):
Well, and then it turns out that, okay, so Python 2 no longer exists. You can't do anything with Python 2. Just delete it from your system. Forget -
CW (19:11):
Except -
EW (19:13):
GNU arm-none-eabi-gdb depends on a specific version of Python 2.8, and not just 2.8, but 2.8 point something.
CW (19:26):
Yeah.
EW (19:27):
I mean,...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.
CW (19:45):
Honestly, 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 -
EW (19:58):
There was that. I would've been happy to go to a Linux
CW (20:01):
- that supports these tools. But we can't really, because -
EW (20:06):
The vendor has tools.
CW (20:06):
- 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. But so, yeah, it's just the tool situation, it's getting better in kind of a weird, random walk way.
EW (20:19):
Yes.
CW (20:20):
The individual tools are getting much better. VS 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 have 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.
CW (20:41):
I'm on Windows 11...That was one problem with me being on Windows Arm is WSL is totally messed up for -
EW (20:49):
Yep.
CW (20:49):
- doing that in a virtualization.
EW (20:52):
Because you couldn't have a virtualization inside a virtualization.
CW (20:56):
Yeah. Yeah. Which you sort of can do, but Parallels for Arm doesn't support that yet. So that's a mess and that -
EW (21:03):
There were two people on the team who had that problem. So it wasn't just you.
CW (21:07):
Okay. Well, anyway. And that's a side thing, but yeah. I mean, a lot of it's just 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 ten ways to mess it up."
EW (21:23):
And setting up the J-link debugger, which I finally got every on J-link, so I don't have to support OpenOCD.
CW (21:30):
Yeah.
EW (21:30):
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?"
CW (21:48):
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, VS Code. Remember that thing I had, was it this morning I was trying to, yeah, yeah. It needed -
EW (22:01):
Oh, it needed Python 3, because our build -
CW (22:03):
Oh, no, no, it was when we needed Python 2.
EW (22:04):
Oh. Oh, that was terrible.
CW (22:06):
So yesterday we needed Python 2. So I'd say, "Okay. I'm all done." I got everything set up, pushed 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's like -
EW (22:17):
And it didn't even look like the GDB server had a problem.
CW (22:21):
No -
EW (22:21):
GDB server says, "Well, nobody ever talked to me."
CW (22:23):
No. Right. If you go to the verbose output in the terminal, it says, "GDB server, everything's great. Waiting to connect."
EW (22:31):
Yeah.
CW (22:31):
And it's like, "Oh, okay."
EW (22:32):
And that was because there wasn't a 2.8 -
CW (22:35):
I didn't have Python 2. -
EW (22:36):
- DLL available for it.
CW (22:38):
- 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?
EW (22:48):
I did it all on command line initially, before I set up the launch files.
CW (22:53):
But how did you know you needed Python 2.7? Did it say, "Where's my Python?"
EW (22:57):
Because at some point when you're not using the command line tools, when you're stumbling around using GDB, I got an error.
CW (23:09):
Alright.
EW (23:09):
Maybe...I didn't type, "no GUI" on something, and so therefore it actually did pop up an error window. Yeah. It was awful.
CW (23:23):
Oh, I also had to reconfigure my J-link to work on Windows Arm.
EW (23:26):
Right.
CW (23:27):
Because...SEGGER's gotten rid of, they had a J-link driver, a USB driver, that used to be specific, and then is now a WinUSB driver, which is more universal, and 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.
CW (23:49):
Because you can't run the J-link configurator on the Arm, because you can't talk to it. Yeah.
EW (23:56):
I don't know why.
CW (23:56):
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..But everyone's behind, at least from Windows.
CW (24:10):
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.
EW (24:23):
I can show you how to change the launch file and the build file to have a different operating system.
CW (24:28):
Well, it's getting Arm and all that stuff installed.
EW (24:31):
Yes. Good luck on that. I'm not participating in tools any further.
CW (24:33):
Conda. I'm going to do it in Conda and it's going to be fine.
EW (24:38):
Yeah. Sigh.
CW (24:40):
Anyway. Yeah. Well, that's the other thing is, now that all this stuff is set up, at some point, the client should consider making it -
EW (24:48):
But we have a built server now.
CW (24:50):
- a deployable thing.
EW (24:52):
Oh, no, we don't have that.
CW (24:54):
A Conda YAML or something like that.
EW (24:56):
Yeah. I think that is on the list, but the client realized that if they asked me for that, it was going to be another six months.
CW (25:04):
Ex-client.
EW (25:07):
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 Classpert class...My students keep having a lot of questions about interrupts, and I understand why.
EW (25:25):
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.
CW (25:32):
Yeah.
EW (25:34):
But...they're 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.
CW (25:44):
A little bit, maybe. Yeah. I think it's because of 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."
EW (26:05):
Line 10 Print "Hello." Line 20, go to line 10.
CW (26:10):
And introducing something that can just say, what did the Hawaiian Punch guy, it's the Hawaiian Punch guy coming through the wall.
EW (26:22):
I know what you're saying, but he said something?
CW (26:23):
Yeah, yeah, yeah. Anyway, it's a difficult way of thinking, because now this thing can come in. And...it can toss the room, change all your data, and then you come back, and you don't even know that happened. That's the whole multi-threading problem.
CW (26:43):
And I think interrupts in a way are harder than multi-threading, because...when you write multi-threading stuff, you feel like you have control of the whole architecture.
CW (26:55):
But with interrupts, it's like, "This is how this works. And this piece of code that's not something you really devised except to handle this thing is here now." And it just jumps in. I don't know.
EW (27:13):
Your point about concurrency is probably right. For the folks that...don't have a software background, the idea of concurrency is probably strange.
EW (27:23):
I mean, you see it completely in FPGAs, but that's different than the concurrency we get from threads and interrupts. I wonder if that's what I needed to do. I need to go back and say, "let's talk about concurrency."
CW (27:37):
Yeah. Because all the problems are the same, right? You have race conditions. You have shared resources. You have timing issues and all of those things. I mean, that's how I always thought of interrupts -
EW (27:54):
Me too.
CW (27:54):
- as a high priority thread -
EW (27:55):
Yeah.
CW (27:55):
- 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.
EW (28:14):
That's good. I should take a step back and think about, "Stop answering the little questions and deal with the big one."
CW (28:21):
What are some of their little questions?
EW (28:24):
One person had a question about ISRs versus asserts versus callbacks...Are they all the same thing?
CW (28:35):
Oh, I see. Well -
EW (28:38):
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, -
CW (28:52):
No, it's not.
EW (28:52):
- and it calls you when your SPI is done.
CW (28:53):
It's not.
EW (28:53):
That's not really the same at all.
CW (28:54):
Yeah. Yeah, no, that'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.
EW (29:09):
Voluntary defenestration versus -
CW (29:14):
Getting a phone call.
EW (29:15):
- getting a phone call.
CW (29:17):
In the middle of what you were doing
EW (29:19):
In the middle of dinner.
CW (29:19):
Yeah. No, asserts are completely different. Assert is, "This condition is not as I expected. Stop everything."
EW (29:28):
Asserts can lead to hard fault interrupts. It's a software -
CW (29:34):
Hard fault interrupt.
EW (29:36):
I mean, it's a non-maskable interrupt.
CW (29:39):
Yeah, sure.
EW (29:40):
And so an assert can lead to an interrupt, -
CW (29:43):
Okay.
EW (29:45):
- and then be treated like it was a hard fault. And if you have hard fault logging, -
CW (29:49):
Yeah. Yeah, yeah.
EW (29:50):
- it goes in there.
CW (29:51):
It doesn't have to be though.
EW (29:52):
It doesn't have to be. An assert can actually be caught, and logged, and then you reset yourself or whatever.
CW (29:58):
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.
EW (30:03):
I always question that.
CW (30:05):
The merit to that aside, yeah. And a callback is just a general class of things. It is a function that you hand to somebody to call you back.
EW (30:16):
If this was the $25,000 pyramid, you just lost.
CW (30:22):
Yeah, but I mean, it's such a general thing, right?...In graphics libraries, often you'll associate a callback with a particular window and it says, "Draw my window." And they say, "Give us a call back so we can draw the contents of this window."
CW (30:39):
Because when the GUI library comes around 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.
CW (30:53):
And it doesn't have to know what it is. It's just, "Oh, time to draw this window. And they gave me this function, and I can go draw it."
CW (30:58):
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.
EW (31:12):
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.
CW (31:22):
Right, because who's calling it back? That can't be right. Where is that coming from?
EW (31:26):
I mean,...it should just return. It shouldn't call you back.
CW (31:30):
Yeah.
EW (31:32):
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.
CW (31:42):
Yeah. And of course with more modern languages, all the 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 point where you say, "Here's my callback, bracket, bunch of code."
EW (31:59):
It's like an inline function.
CW (32:01):
Yeah, it is. And with asynchronous stuff, I mean, modern languages all have asynchronous primitives so that stuff can happen. Concurrently is a little weird, because sometimes it's a lie. If you have one CPU, concurrency, isn't really happening...
CW (32:17):
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.
EW (32:32):
The illusion of concurrency. That's my new band name.
CW (32:36):
Anyway...Yeah. Yeah. It's hard. I mean, a lot of these are fundamental concepts that are getting mapped onto things like ISRs.
EW (32:47):
And if I could do better with the fundamental concept, I think that would work better.
CW (32:54):
And I think ISRs are confusing too, because there's a lot of mechanics around them that have nothing to do with the fundamental concepts that are tricky and weird, right?
EW (33:01):
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 -
CW (33:15):
I don't even know the answer to that question all the time.
EW (33:16):
- an interrupt, -
CW (33:18):
Yes.
EW (33:18):
- and it happens -
CW (33:20):
Again.
EW (33:21):
- while I am in my interrupt, what happens? Yeah, they had a lot of -
CW (33:27):
And see, those have nothing to do with concurrency, because threads, you don't have to be crazy careful about necessarily, "oh, I've got to get out of here as quickly as possible." Because you might have architected your system and the thread can run a long time.
CW (33:39):
But an 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..., and even I don't know those answers -
EW (33:53):
Its inconsistent.
CW (33:54):
- all the time. Yeah. It's not consistent. And then there's interrupts that can be cued.
EW (33:59):
And nested, I mean, -
CW (34:01):
And nested.
EW (34:01):
- nested and prioritized.
CW (34:02):
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."
EW (34:15):
Yeah. I think I made a joke in one of my lectures about how it's really important to know the nested and interrupt priorities just as it's really important to know about, and I don't even remember what the other thing was. But it was something entirely pointless.
EW (34:31):
I 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."
CW (34:40):
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 interrupts. And now you're really talking.
EW (34:55):
...If we ever need to have a contest, we should have the deepest interrupt stack. Anyway, let's see. They also had, "What happens when an interrupt isn't handled?"
CW (35:12):
Yeah. Well, generally you crash.
EW (35:15):
Well, no, I mean that doesn't have to be.
CW (35:17):
Right.
EW (35:17):
It depends on how your vector table is set up and almost all -
CW (35:20):
But by default, the HALs crash you. No?
EW (35:23):
They put you in an infinite loop.
CW (35:24):
Yeah. Yeah. Okay. Crash is the wrong word, but -
EW (35:27):
But it -
CW (35:28):
- they do not just silently say, "Well, I don't know what that was. Guess it's okay."
EW (35:32):
Yes. But you can let it be okay. Which is dangerous.
CW (35:37):
So 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."
EW (35:58):
But you need to know that those interrupts are happening and not being handled. Because they will affect your processor speed.
CW (36:06):
Right.
EW (36:06):
And so you find those out, and then you turn them off. And then you never have to deal with them again.
CW (36:11):
Right. It would still be nice. Infinite loop is not the nicest response.
EW (36:18):
Yeah. True. True, true, true.
CW (36:20):
Yeah. I'm just thinking of Unix, if you have signals and stuff. Yeah, I think uncaught signals. I don't remember what happens with uncaught signals. If I give it a user signal, does it stop my program, or does it ignore it?
EW (36:33):
It probably ignores it -
CW (36:34):
Yeah, I don't remember.
EW (36:34):
- or has a default at the end that says -
CW (36:37):
Yeah.
EW (36:38):
- unhandled signals.
CW (36:39):
Anyway, yeah. Well, but that's another thing that's different between HALs, right, you said?
EW (36:45):
Oh, totally...And your vector table could be written in assembly, -
CW (36:51):
Yeah.
EW (36:51):
- or it could be written in C, and...how your interrupt service routines are handled, and then the whole weak keyword. Do you - ?
CW (37:03):
Oh yeah. The weak keyword is cool. Yeah.
EW (37:05):
I don't remember being taught the weak keyword. Do you know when it came?
CW (37:09):
I think it's a C99 thing.
EW (37:12):
That would explain why it's always been a little new and nifty to me, which only dates me. I know.
CW (37:17):
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.
EW (37:29):
Oh, that's a way to look at it.
CW (37:32):
I mean, it just says this can be overwritten, right?
EW (37:35):
Yeah.
CW (37:36):
So that's what it is.
EW (37:39):
And we use it in interrupts, because the HAL will put all of the interrupts to -
CW (37:47):
Default things.
EW (37:48):
- a default interrupt handler -
CW (37:50):
Yeah.
EW (37:50):
- which is the one that loops. And then when you come along and you want it to have a ISR SPI2 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?
CW (38:14):
I'm not sure this is a C feature. I think this is...a GCC feature.
EW (38:20):
All of the other embedded compilers I've been using lately have it.
CW (38:24):
Yeah. Yeah. Everybody has it, but... -
EW (38:25):
So it may just be a feature that everybody has that isn't really part of the language.
CW (38:29):
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.
EW (38:42):
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?"
CW (39:04):
This from a person who I caught last night playing a video game that is apparently copy editing books.
EW (39:12):
Yes.
CW (39:12):
And you score points for copy editing. And do you realize you're getting paid for this?
EW (39:17):
It was fun.
CW (39:20):
Is this like Simon and Schuster outsources copy editing?
EW (39:24):
No, they use classics.
CW (39:26):
Oh, okay.
EW (39:27):
And so I was -
CW (39:28):
They mess up public domain books?
EW (39:29):
- reading "Pride and Prejudice," and it was messed up. And then I was reading Japanese fairy tales.
CW (39:36):
Okay. No. No, no, no.
EW (39:37):
It's called Dear Reader if anybody really wants to know.
CW (39:41):
Might be fun.
EW (39:41):
Pretty silly.
CW (39:44):
Well, you have talked about doing a second edition, which would allow you to make all new typos.
EW (39:51):
Yes. I have talked about that, and it may happen. I think it's mostly a matter of how much time I have over the next year more than anything. I have a long list of things that I would put into a second edition. So, I have a lot of ideas. It's just, "Do I have a lot of time for writing?"
CW (40:16):
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.
EW (40:27):
And yet we're going to do it anyway.
CW (40:29):
Well, sometimes you've got to do what you've got to do.
EW (40:31):
Actually, I don't know if the PIC compiler allowed weak symbols. That was the last one I messed with vector table on. And that was only a year ago.
CW (40:41):
Doubt it. I mean, it's a linker thing, right?
EW (40:45):
Well, I mean, it has to be acceptable to the compiler.
CW (40:46):
Right, right.
EW (40:47):
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.
CW (41:02):
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 too, which adds more stuff you've got to worry about.
EW (41:13):
Like what?
CW (41:15):
Like how do you get from the interrupt to your code?
EW (41:20):
You just put a semaphore out.
CW (41:22):
Okay. Or a message. But yeah, you just do one -
EW (41:25):
But you don't wait for a mutex.
CW (41:27):
Anyway,...there's more stuff to do.
EW (41:30):
Yes.
CW (41:31):
You don't just set a global variable, or something, or stomp on your shared resource.
EW (41:37):
I do have a couple more things to talk about. I'm still playing with Wokwi, and I'm still enjoying it.
CW (41:43):
You're using it for the class, right?
EW (41:45):
I'm using it for the class. I'm using the C-based Raspberry Pi Pico simulator.
CW (41:52):
Okay.
EW (41:53):
And I have a command line system on that that you can type to...
CW (41:59):
Oh.
EW (42:00):
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.
CW (42:18):
And it'll export the logic analyzer data to a file. And then you can open that in the thing that I forget the name.
EW (42:26):
PulseView.
CW (42:26):
Yes. PulseView.
EW (42:27):
Yes. When you stop simulating, it downloads a file, and then -
CW (42:30):
Got it.
EW (42:30):
- you can see what it was. And it's just like looking at a Saleae. Pretty cool.
CW (42:35):
Neato.
EW (42:37):
Let's see, there were a couple things in Patreon Slack. First,...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, -"
CW (42:54):
Oh, excellent.
EW (42:55):
- 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 datasheet, what sections do you read regardless of your particular application?'
CW (43:15):
If I have a 900-page datasheet, the section I read is the termination criterion for my contract.
EW (43:24):
That's not true. You and I are both working on a 1400-page -
CW (43:28):
What? That's not a datasheet.
EW (43:30):
- manual or whatever.
CW (43:33):
Well, the one I've got is only 180.
EW (43:36):
Yeah.
CW (43:36):
Alright. What section?
EW (43:37):
Using the other one soon.
CW (43:38):
What section. Are you asking?
EW (43:41):
Yeah.
CW (43:45):
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...there used to be app notes, which I haven't -
EW (44:03):
There still are.
CW (44:03):
There still are, but a lot of times you just get the datasheet 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."
CW (44:17):
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 still stuck on 900 pages. What is that thing?...I mean, is that the Arm reference manual?
EW (44:36):
I mean, some of the TI chips, basically they throw everything in in some files.
CW (44:42):
Yeah.
EW (44:45):
For me, I said, and I stand by, I read the table of contents.
CW (44:50):
Yeah. I mean, that's fair.
EW (44:52):
Because I want to know what's in it.
CW (44:53):
Yeah.
EW (44:54):
...I mean the introduction, -
CW (44:57):
Well, it's not always -
EW (44:57):
- and if they have a references table, which I guess is kind of what you were talking about.
CW (45:01):
The...question isn't what do you read first? It's what do you always read regardless of your application?
EW (45:06):
And so the files it points to, the table contents, an introduction, if there's something called a "getting started" area.
CW (45:16):
Yeah.
EW (45:16):
I read that part.
CW (45:17):
I jokingly answered earlier, errata.
EW (45:20):
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.
CW (45:27):
It's 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?"...It's a typo.
EW (45:48):
Oh, nice.
CW (45:49):
Yeah. Yeah, yeah. I guess to turn the around..., "What sections do you wish every datasheet had?" And I definitely want application notes. Tell me how you think someone should use this thing, because if it's just registers and the block diagram, that's not enough.
CW (46:14):
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 for your device.
EW (46:33):
Seems awfully specific.
CW (46:35):
What?
EW (46:37):
Are you having this problem currently on two different parts?
CW (46:41):
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 ancestral knowledge of what to program in them.
CW (46:56):
And people just pass it down from GitHub to GitHub. And you hope you get it right. And then there's eight registers that actually do stuff that you can configure. But the rest are just, who knows?
EW (47:09):
Incantations.
CW (47:10):
In register 98, put the following 12 bytes.
EW (47:18):
I saw some other stuff on the Patreon. Phillip Johnston of Embedded Artistry and 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 -
CW (47:43):
Cool.
EW (47:45):
- which we talked about a little bit on the show. But...they have another person from the Fitbit team.
CW (47:52):
Shiva.
EW (47:52):
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 waitlist for this. So you might want to take a look and make sure you are on the next one.
CW (48:12):
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.
EW (48:22):
At Golioth, where Chris Gammell and Jonathan Beri 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.
CW (48:44):
Yeah. That closes one major hole in kind of the WSL story for doing embedded development. So that's good if progress is being made there.
EW (48:56):
Let's see...The last one was somebody's project that made 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.
CW (49:11):
I mean, is it a kite?
EW (49:13):
No.
CW (49:13):
Oh.
EW (49:14):
No, no.
CW (49:15):
Well then I don't know how it works.
EW (49:18):
It's pretty cool. I mean, it looks like an airplane, but it's not.
CW (49:24):
Alright. Alright. Well, I think that covers it for everything I had.
EW (49:31):
Well, and Winnie the Pooh this week is actually really related to some career stuff.
CW (49:42):
Yeah. But you need to close the show first.
EW (49:44):
Oh, I shouldn't just start reading?
CW (49:46):
You shouldn't just start reading. Yeah.
EW (49:47):
Oh, okay. Let's see. Thank you to Christopher for producing and co-hosting. Thank you for listening. Thank our Patreon listener Slack group for some questions.
EW (50:01):
Thank my students for their many, many questions on Classpert. And our email is show@embedded.fm, or you can hit the contact link on embedded.fm.
CW (50:12):
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.
EW (50:28):
0 to 20%...
CW (50:30):
I think zero's, yeah, disappointing.
EW (50:32):
It's still fine. You should still use the voucher.
CW (50:34):
Okay.
EW (50:35):
But it's kind of like a lottery. It's exciting now.
CW (50:39):
Alright. Thanks, Newark.
EW (50:42):
[Winnie the Pooh excerpt].