Embedded - 426: Equivalently Annoying

Episode Date: September 9, 2022

Elecia and Chris are back from vacation and catching up! Today’s topics include: last week’s burnout episode and what we learned, what is a PSoC and why would you want one, how to get up to speed as a junior engineer, and a few more side quests. The burnout episode with Keith Hildesheim was last week, we encourage you to check it out, we learned some things about ourselves and maybe you will too. Chris mentioned astrophotography and here’s the link to the reddit post that inspires him to keep going: astrounding Jupiter video. In case you missed it in the newsletter, which you should definitely sign up for, here’s Chris’ list of VSCode extensions: AutoScroll - Have a log file open that you're monitoring? This extension keeps the tab scrolled to the bottom at all times. Doxygen Documentation Generator - Quickly generate and pre-fill those tedious doxygen style comments. GitHub Pull Requests and Issues - Make pull-requests or do reviews for Github right in the editor. GitLens - Easily see revision history and "blame" for every line of code in a pretty unobtrusive way. Header source switch - Ever want to switch really quickly to a C file's header (or vice versa)? This adds a keyboard shortcut to do just that. TODO Highlight - Makes those millions of TODOs and FIXMEs light up in a nice neon color so you can't ignore them anymore. Transcript

Welcome to Embedded. I am Alicia White, here with Christopher White. I asked on Twitter what we should talk about, since we are just chatting amongst ourselves today, and threatened that if I didn't get a response, we would be discussing our vacation pictures. On a podcast. And I didn't get a response. we would be discussing our vacation pictures. On a podcast. And I didn't get a response. All right, let's go through it. So first, we've got some pictures here, looks like, of a forest.

Forest, flowers, otters, birds. Some birds, some waves. The giant squid painted on the large machinery crane thing. The giant squid, the giant squid on the side of a building. Yep. Some sand, rocks, a few rocks. I got a cute picture of a bee and a flower. There were three pictures.

There's the bee on top, and then you can, at the third one, you can just barely see its little bee butt. I think we should pick one photo and go into really good detail about it, describing each section individually. The colors, the contrast, that sort of thing. Don't we have a book club for that? Yes, I did convince our book club to read a picture book. It was hilarious. It was like the best.

It's not a kid's picture book. It's a picture book. But it's a book of pictures, which is not to be—I It's a picture book. But it's a book of pictures, which is not to be, I mean, a picture book is one thing. A book of pictures is something else. Anyway,

this week, I think we're going to have some introspection about burnout, class, the podcast, vacation. That's what we do every week. But there's also going to be some random advice. Random advice.

Go ahead. Don't stick forks in electrical outlets. But there's also going to be some random advice. Random advice. Go ahead. Don't stick forks in electrical outlets. That is slightly random. What are we talking about? Well, I wanted to touch on a couple of things we've talked about in the past. All right. Let's do it. Let's keep this to a tight 49.

Okay. Class is going and we're headed into micromadness and hardware. And so that's going along. What's micromadness? Oh, so I guess the students don't know this either, but it's okay. So I assign them all boards. Yeah. And they're all arm cortex boards of different varieties, M7s to M0s. And they have to learn about the board, including the processor. I ask them completely arbitrary things about their processors and put them into a March Madness NCAA-style basketball tournament.

And they compete on these completely arbitrary qualifications, which, I mean, realistically, when we choose processors, sometimes it feels really arbitrary. It has to be the smallest of the two. It has to be the least expensive. It has to have the most number of pins. It has to be the least expensive. It has to have the most number of pins. It has to have the nicest silkscreen. I don't think so. I don't think that's one of them. But I do believe the number of vowels in the part number might be one of them,

just to show how silly it can get. And I mean, some of the criteria are based on the boards, and some are based on the processors. So this, I mean, this is a chapter about learning to read the data sheets and learning to understand the documentation that surrounds the processors and the boards and what you look for when you buy things. So we end up having this competition. And if you lose to somebody else's board, you become part of their team, so now you have to learn about some other processors. It's really silly and fun and kind of frenetic, but the goal of trying to get a view of the industry is... Well, and it helps them read specs and part sheets and stuff.

And if people haven't done that before, it's kind of a pain. And the interaction of being there and getting asked questions that you don't know the answer to and have to look them up relatively quickly feels just like meetings sometimes.

Well, why shouldn't I order 10,000 of these right now? Right. Well, because you can't buy 10,000 of anything, but that's fine. We actually, last time we had trouble

buying boards, you know, buying in quantity. And this time we didn't have trouble. So I feel like the parts are loosening up some. I think I've heard that. I haven't had to buy anything, so. Well, you bought something. Yeah, but it's not related.

Next. Oh, sorry. What? I mean, I was going to... No, I'm not going to talk about my consumer product purchases. Well, let's just say, Wendell, thanks a lot for this. Anybody who wants to check that call back. Let's see.

We also had a show about burnout. Yes, we did. That was last week's show. Well, yes, it was last week's see. We also had a show about burnout. Yes, we did. That was last week's show. Well, yes, it was last week's show. It was confusing because we actually recorded it. A couple weeks before that. And then we went on vacation. It was last week's show.

But to everybody else, it was last week's show. Yeah, that was good for me. It was good for you? How so? What did you learn? Well, I mean, I looked at, we did that show, and then we went on vacation. Right. Like, we recorded on Friday, and then the next week was off.

Right. Which made me think about all the things we brought up. Like, what are your values? I took, like, five online quizzes about what my values were. And I thought about all of these things and things that I don't like to do. And I didn't have work and suddenly I was actually quite a bit happier. So it really is work related. Another four or five weeks of vacation, I think I would have felt a lot better. It was only one week though.. There are things I like to do. I actually like Twitter. Of course, I use it mostly as an output-only device. I don't read it a lot.

But I also realize that there are things I do that are shoved between other things that I consider work, like the transcript review and monitoring the podcast social media and the newsletter. And it ends up being chores. I don't see them as a priority. And that's kind of not good. Because those are the things that I want to be happy about.

But because I'm spending all of my time on things that I don't really want to be doing. Anyway, the burnout show is really good because it's making me look at these things and making me realize that I can't just keep pushing the boulder down the street and saying, this is hard. I actually need to probably talk to a professional of some sort. All right. Yeah. Which I was going to do today today but we have the podcast so i

decided to push it off to next week um yeah no i thought it was a good show i thought i thought they had some pretty cool insights i don't know that it helped me very much because i don't i don't really know that i'm burnt out or if i'm just always been this way just kind of never been super super engaged with work for long periods of time. I'm very bursty and always have been. So I don't, I don't think that's really burnout. I think that's just the way I work. But yeah. Yeah. I think one of our listeners was surprised that it was me talking about burnout. And they expected it was be about you, but you've always worked like this. I'm just cranky.

Me not liking work is new and weird and kind of unpleasant. No, I've been generally burnt out, but I don't think that's my current state right now. What are your values? I don't know. That was such a hard question and kind of a dumb question. Well. I mean, the online things, they're like, intelligence is a value, but kindness isn't? Like I said to you earlier, that those online tests are very silly.

They're very vague, broad categories of values. Like, you could value origami, right? That's a more specific thing. Like, I like doing origami. I value that as a part of my, of what I like to do. And so I'm going to do things to make it so I can do more origami or whatever, just as an example. But saying I value creativity, it's not really all that actionable, right? Or I value intelligence. Great. Good for you. Most people do. It's not, so I don't,

I wouldn't take those online quizzes as an indication that kind of surveying, trying to figure out what your values are is a useless activity. Oh, wait a minute. Those online quizzes aren't the end all be all of all medical and social and psychological things? That's what I hear.

Man. Yeah, come and just talk to me because it turns out I'm, you know, a type A extrovert. I did take five of them and average the results. That works, right? That's probably better. You know, if you take total garbage and average it over a long time, then the data becomes good. That's what I've heard. It works sometimes for an ADC, occasionally. No, no, total garbage. If your signal-to-noise ratio is zero and you keep averaging it, it's still going to be zero.

Did you enjoy our vacation? I did. It also made me think I need to rethink how I do work and stuff. Because I do spend a lot of time dreading work and doing not much. Because you're dreading it. Because I'm dreading work, but I should be working. So I don't do anything else because I'm too guilty to do something I would enjoy. So I tend to push things toward the end of the day when I'm, guilty to do something I would enjoy. So I tend to push, I just tend to push things toward the end of the day when I'm quote done working, uh, like, you know, music or whatever, or exercise, um, or going to the beach or whenever I tend to push them, you know, oh,

well, it's around four. It's time to knock off work. That's the end of the day because that's how things work. But maybe I didn't even start until 10. And so I, you know, wasted a couple hours in the morning sitting around waiting for work to commence. But you wasted those because you didn't do something you enjoy. Sometimes. I mean, sometimes I'm catching up on, you know, blogs and RSS feeds and stuff. And that's stuff I do enjoy at some level, but is it stuff I enjoy more than, hey, maybe I should go, you know, play some guitar or something. I don don't know so that that's where you know values comes into it's like how much do you value you know this creative activity that you're not making time for versus

idle you know real idle time maybe real idle time is is more more valuable to you but you should be conscious of that well and if it's going to be idle time it should be conscious of that. Well, if it's going to be idle time, it should be idle time that is energizing instead of idle time that is... I mean, there's a value... Idle time is good. I don't think we should be doing something all the time. No, no. But sometimes they

play stupid games or read books that aren't making me happy or they're just passing time, which is not fun. Yeah. Okay. So, let's see. Anything else about our vacation?

No. I tried to... I've been trying to get into astronomy again, sort of, slowly. It's not going well. But stars are cool. Planets are cool. But it's all expensive and painful.

Well, and then there was that guy with the huge Dobsonian who takes backyard planet pictures that are just amazing. I'll put a link to that in the show notes. But there's a guy on the astrophotography subreddit who's been posting some photos he does, photos and videos he does of planets, particularly Jupiter is one of the good ones. And they look like stuff from like, well, I mean, if you'd showed this photo to somebody in the 80s, it was like, oh, Hubble's doing real well.

Yeah. And it's just, you know, a backyard, it's a big telescope. It's a 16-inch Dobsonian, which is quite large. But with a video, you know, a few hundred dollar video camera, and he does a lot of processing and stuff. It's not easy. The kinds of things you can get for your backyard if you have the skills are quite impressive. I mean, you need the camera and telephones.

The camera's the easy part. And the dark skies, which is one of the harder things, isn't it? You don't need dark skies for planets. Really? Planets are very bright doesn't matter yeah you can do all sorts of planet stuff without dark skies i mean think of the moon nobody needs dark skies for take pictures of the moon you need brighter skies to tone it down so you get better earth shine but the planets are super what you need is good seeing which is steady, but that's independent of dark skies usually.

I'm not sure our seeing is very good being so close to the beach. So anyway, I've been pursuing how to figure out how to do astronomy again without... I mean, the other problem is everything is so heavy. The gear I have, which is old, but it's like 80 pounds for the telescope plus the mount. And by the time I get that outside in the afternoon preparing for the evening, I don't want to do anything ever again. So, yeah, I have a lot of equipment to get rid of. So that's going to be one thing that's a little challenging

because not that many people want 80-pound telescope mounts. So if anybody wants an 80-pound telescope mount that's a computerized go-to German equatorial mount... And is willing to pick it up. And is willing to pick it up here. Let me know. I'll throw in the telescope. Yeah, we started a swap meet channel on our Slack.

And Chris actually has sold things. So that's very funny. I think I'm the only person who successfully sold anything. I feel a little bad about that. But yeah. Let's see. We are working on having t-shirts. So expect to see a link up for that in like the next month.

We have the design, which is super good, but we haven't chosen the vendor or the t-shirts or the colors or how much to charge. I mean, it's not like we make much on the shirts. I don't usually price them to be fundraisers. It's more just kind of cool to be able to see somebody and say, oh, you like Embedded too? Which is, I guess, my reminder to say, if you like the show, please tell a friend.

Or an enemy. Or an enemy. Tell anyone. Yeah, really. Let's see. We are abandoning our Instagram and Facebook accounts, I think. Well, I mean, we're not deleting them, but we're not going to update them as regularly as we used to. But I will try to keep the list of episodes up to date, which is one of those things that our transcription and social media person was doing.

But she has left us for better and greener pastures. And I'm still, I've got the newsletter now. So if there's any complaints, if it's late, if there's weird typos, if I discuss something that's completely unrelated to the show, that's all my fault. This week you put in your favorite VS Code extensions. I'm trying to throw something in there because, you know, sometimes... Just in case somebody actually gets to the bottom. Yeah, yeah.

You know, some exciting little bonus, you know, material. So, yeah, I went through what I had installed on VS Code that I regularly use and that isn't just one of the usual, of the usual C++ extension or Python or whatever. Just a few kind of cool little things that I like. Oh, you want me to go through them now? What are they, Christopher? Oh, I see. Instead of saying sign up for the newsletter and then get the past back issues.

I don't know how they get the back newsletters. I'm pretty sure they can, but I don't know how. All right. And if I don't know how they get the back newsletters. I'm pretty sure they can, but I don't know how. All right. And if I don't know how, I don't think they know how. Here is the list in what appears to be alphabetical order. Oh, I didn't try to do it that way. So alphabetical order, no other meaning behind the order.

Autoscroll. What does that do? So I do a lot of machine learning training or things that have log files that are spitting stuff out constantly. Oh, okay. And so normally if you open a log file, VS Code does keep up. Like if it changes on disk, it will update the tab that has the log file in it. But it won't keep you at the bottom. So it'll keep scrolling and you'll have to, you know, page down or grab the scroll bar to get to the bottom. Autoscroll says for files like that, it keeps track and anytime it's updated, it scrolls

to the bottom. So you've always got the latest thing right on the screen. Nice. So pretty simple. I think that one has a few weird interactions with some built-in VS Code stuff, so you may have to disable it sometimes when you're doing regular code work

because every time I try to command click to a symbol, it goes to the file, it goes to where the symbol is, and it scrolls to the bottom. So I'm pretty sure that's a bug there. Let's see, the next one, Doxygen Documentation Generator for places that require you to have Doxygen comments in the headers. Is that one you have to install separately?

Because I didn't think I did that, but when I type slash star star, it automatically fills in. That's one dummy. I have it installed, DoxygenDump, and I think you installed it. It's probably that I installed it, yes. Anyway, what it does is if you've got the, what do you call it, the prototype for your function in your header, and you're right above it, the cursor's right above it, line up,

and you do slash star star, it makes the header and finds all the parameters and stuff and fills in all those little at things for you. And all you have to do is tab over and type the brief description and fill in some description stuff, but it formats the whole thing. So it saves some time with, you know,

asterisks and slashes and ASCII drawing. And the cut and paste error of copying the previous one. Yeah. The next one's cool. There's GitHub pull requests and issues. And if you do stuff on GitHub, this links up with your GitHub account

and so you can see your pull requests, other people's pull requests for the particular repository your working directory's in. And you can do reviews in line in your editor and respond to comments and stuff. And Mark's stuff is done right there. So that's pretty cool.

Next one is also Git-related. Git Lens. And this is really cool. It allows you to see revision history and who edited each line of a file right in the editor. And you'd think that would be really obtrusive, but it's really cool the way they do it. It's just a very light gray if you hover over the line and it puts it in a place where it's unobtrusive so you can see it.

And then you can also dig a little deeper. It has some other features for digging deeper into the history of particular sets of lines or lines in the code. I didn't believe him on that one, but I did install it. And it's like light gray. For me, I have a dark background, and it's light gray letters. You can barely see. But when you're walking through and you're like, oh, why did this happen?

And you actually look at the line, suddenly it tells you. Two months ago, so-and-so edited this line. You committed it, yeah. On this commit. And the comment says, I shouldn't do this. I don't know why I'm doing this. Exactly. This one's really silly, and I'm surprised that VS Code doesn't have a built-in thing, and maybe it does.

It's called Header Source Switch. And it gives you a keyboard shortcut to switch from the C file to the header file, or vice versa. So if you're sitting in the C file and you're like, I've got to get to the header, you can either file or vice versa. So if you're sitting in the C file and you're like, I've got to go get to the header, you can either command P and try to type the header file name and click over, but this is just one keystroke and it opens and switches to the header file.

So that's cool. Okay, I'm wondering about the utility of that, but I'm installing it anyway. Well, it's actually built in a bunch of other editors I've always used, like Xcode. So, I mean, you don't find yourself in a C file wanting to get back to the header? I usually, I mean, I split the screen and the headers are here. What if you don't have it open? Well, then I control P and type. Exactly. Now all I have to do is hit alt whatever.

Alt O. Yeah, Which you can change. And the last one. To do highlight. This one is... You don't have to do this one, but I like this one. It takes all the comments with to do or fix me

in them, and it highlights them in orange and puts them in the gutter. The little orange... Puts the little orange pips in the gutter in the scroll area to show you where they are. So if you open a file and you're scrolling around, it's blinking. No, they're not blinking. Sorry.

Didn't want to alarm release you. They're orange or highlighted some color. So as you're scrolling through, you can quickly see the to-dos and note that maybe there's 50 in a file and somebody should deal with that. Like just remove them all. Don't bother to say anything. There was a comment today and I asked the author, what the heck? And the author said, well, that's old.

We should get rid of it. I'm like, yes, you should have gotten rid of it. Before I asked, you should have gotten rid of it. Before I asked, you should have gotten rid of it. Now we've both wasted our time. Anyway, that's six that I use a lot. I have a few more, but those are the main kind of off-the-wall ones that I like. And you have Cortex Debug. You have to have Cortex Debug if you're going to debug on a Cortex.

That's why I didn't include stuff like that. These are just quality of life improvement things that you can live without. There's a whole bunch of good extensions out there. Sometimes I have some that I just needed for a minute.

It's like, oh, CSV file. There's lots of great ones for CSV file, JSON editing, YAML, a lot of specific file ones that are really nice. And occasionally there's weird stuff out there for very specific purposes. There's a Docker one. I don't really know what that one does. I thought of installing it when I was doing a lot of Docker stuff, and then I figured maybe I shouldn't move close to the Docker light any

closer. CSV to table and rainbow CSV. Yeah, I think I've got one or two of those. But you couldn't find a serial port interface. Nope, there is not one. It's funny, when you were telling me that, I was running

Python, PySerial, and typing at a terminal in VS Code. Right. But it was a terminal of my own, making through a Python script that I was building. But, yeah, I couldn't find anything. I just want what I want, and it doesn't exist, as far as I can tell,

is a good serial terminal emulator that I can stick in a tab. And so I don't have to, I mean, it's dead simple. Maybe I should just write it myself, but it's really stupid. Stupid simple, should be stupid simple, but maybe it's not because it doesn't exist.

There was one thing for, I think, Platformio or Arduino, but it was very specific to that framework. And I don't... I just want... What I want is Putty or whatever the Windows thing or Minicom. Terater. Whatever you call them, I want that

in a VS Code tab. Because I've already got terminals. I mean, I can pull up Minicom and a terminal in there, I guess, but it would be pretty convenient to have it just be a thing. Huh? There was one released in June. Oh,

I'll go look for that. Send and receive text from serial ports. Huh? Huh? Huh? What's it called? Serial monitor. That's one of those trickily named ones.

Trickily? I don't think that's the right word what is the right word? it's not just tricky because it's an adverb right trick trisky trisky

that's it that's the stuff Chris likes section of today's show. This is all over the place today. I mean, we should still be talking about our pictures. I have some really great flower pictures, and I got photo bound by a hummingbird twice.

Well, two hummingbirds, but where I was taking pictures of flowers and the hummingbirds just showed up. Let's see. I mentioned Cortex Debug, which now I have learned how to do chain configurations. Sounds awful. I mean, they're really powerful,

and probably as a regular app developer, they totally make sense. But as an embedded developer, it was a little hard to figure out. But now that I have them figured out, it's like, okay, that's totally easy. You should charge for that specific information. You should have a little mini course

how to set up chain configurations and we'll sell it on the website. Yeah, I don't know about courses. I mean, I like the course I'm teaching. It's not a course. It's a 15-minute YouTube video. And instead of giving it to people for free, which is what most people do on YouTube,

we will host it ourselves and charge a lot of money for it. More likely, I would just write a blog post and give it away for free. Alright. But I needed to do that because we've been using the P-Soc chips, the Cypress PSOC chips.

PSOC. That have a Cortex-M and a Cortex-0, and they have to be booted in a certain order. They're both Cortex-Ms. There's a 4 and a 0. Right. There's an M0 and an M4, and they have to be booted in the right order, and one controls the other, and blah, blah, blah, blah, blah. But as I was waitingining about that on the complainatorium,

somebody asked, what is PSOC and why would somebody want to use it, given our extreme amount of whining? There's no good answer for the second question. Well, first, we have to talk about what

a PSOC is, Programmable system on a chip. That's what I guess the P stands for. I suppose it could stand for peripheral system on a chip. I mean, remember, PICS didn't stand for anything that made sense for a long time. They kept changing it. Well, no, the thing is, PSOC was a term before Cypress trademarked it. I know. And, you know, there used to be a time when you would get a microprocessor, and then you would get RAM, and you would get flash.

And a clock, and you have to hook all that to a bus. And everything was all separate. Yeah, that's not a microcontroller. And then the microcontroller was when you combine them all together, but sometimes you could combine them all together and call it a system on a chip or a programmable system on a chip if you had Flash because you were programming the system on a chip. But that's not what people are complaining about when they're complaining about PSoCs these days. People being us.

Us. Yeah. And some others. And others who remain nameless. Yeah. It's, remain nameless. Yeah. The hardware is probably fine. I think so. The hardware is fine.

I think the hardware is fine. I haven't had any weird issues with the hardware. Why is it special? The P-SAR? Yeah. I don't know. It had some... Nope, not going to go with that joke.

It's special because... Okay. You know how you get an STM32 and it's got a bunch of timers and a UR and a couple I squared Cs and a couple of spies and maybe you can route the I squared C and spies to a couple different places, but that's the limit of that.

And all your peripherals are laid out, and they go to specific pins, right? Well, that's not how the PSoC works. PSoC works by having a surrounding penumbra, an aura, an enveloping umbrella of programmable logic outside the actual CPU, and that programmable logic is used to implement most of the peripherals. So if you want to have 100 UARTs, you just need to have all of the pins that can support that. And enough logic elements in the FPGA thing.

Right. Which it probably doesn't. But if you want to have five UARTs, you totally can do that. Yeah, you can do that. You can have a bunch of hardware timers and you can link those up onto interrupt pins. You can bus interrupt pins together.

You can put a bus on it. You can say, these eight pins are now a parallel bus that I'm talking to an LCD display, which is actually pretty hard to do on like an STM32, I think, unless they have a specific TFT interface on them, usually, TFT 8-bit interface.

So on paper, it sounds great. And you can even do more stuff because it's a realish FPGA interface. So if you really want to dig down, you can build your logic out of elements and put like, you know, an actual schematic together that does something.

Say you wanted to debounce a button in hardware or, you know, have some comparator or some logic that specific logic to do something. I mean, cameras are a good place where you can actually do some, some things to the data in hardware. Not sure it's that capable.

Oh, really? I mean, I haven't played that layer of it. I don't know. I don't know. And, and then you get the,

you know, you can get a processor or two, depending on what model you buy. And it's a normal, you know, micro controller with flash and, and all you buy. And it's a normal microcontroller with flash and all these things. And now it can have as many peripherals of whatever type you want it. So it's the chip that you want and nothing else.

Yeah, yeah. Kind of like Batman is the hero that you deserve or whatever. But don't need or no, that's not right. Yeah, you need something. So that all sounds great, except you have to do this. Right. You have to do this. Even if you have a bog standard system.

You have to go in and define your peripherals, which means going into the schematic interface, which isn't difficult for the peripherals for the most part. Once you get the hang of it. It's mostly dropping little toy Lego blocks of things in. Because they've implemented almost all of the peripherals you want unless you want to do something really spiffy. Yeah, and some of the nasty stuff that you have to deal with with the HAL and STM is in that, is instead on PSoC inside the GUI for that.

So if you want to adjust the spy clock and the phasing and all that, you just click around in there and that goes in that programmable hardware thing and it generates the driver for the HAL and it generates the logic for the FPGA block. But you have to do this. And the problem with you have to do this is now you have to use their tool to do this.

And their tool to do this is not, in my opinion, an A-plus tool. tool to do this and their tool to do this is not in my opinion an a plus tool that's how we're saying that these days the editor is kind of janky and i know they have a new one called modus toolbox i haven't tried that yet um so i'm using psoc creator which i think is deprecated now so it's kind of unfair um but the editor is kind of annoying. But even if it wasn't that the editor was annoying, it was the, you get to have all of these peripherals and you have to do this definition. And you can change things in the definition, which means that it,

and because it changes the hardware layer, the programmable layer, and it generates all of these files for you around the drivers, the hardwareable layer, and it generates all of these files for you around the drivers, the hardware abstraction layer. Now, every time you breathe on it, it generates 100 files, which it then has to compile. And, I mean, zero lines changed. Right.

So, the thing is, with all flexibility comes a cost. And complexity. Complexity. And with complexity comes errors and time. So, like you said, if you change something in the schematic at all, if you change a spy clock, it has to do the FPGA thing again. And the FPGA thing is not a C compiler. It's single-threaded. It's slow.

It takes a long time. It's single-threaded, it's slow, it takes a long time. It tries to optimize things. And that's all mostly fine because, I mean, on a lot of projects you're not going to be going in there too often. Yeah, once it's set up,

you're done. Once you set up, you got your peripherals, you're mostly done. Depends on the project. On some projects where something's complex and you're really,

really getting into that, that can be a problem. But the other issue is it's all kind of binary in XML files, so it's not really compatible with source control in a very friendly way. I mean, I edit my XML

files pretty often. If you do make changes, good luck merging or rebasing. You're not going to be able to. So what's going to have to happen and what has to be done is if you've got two people editing the top schematic, top schematic, that's what it's called,

the FPGA editor thing, one person has to go in and then the other person has to, let's say they were late, they made some changes. They've got to manually go in and redo their changes on top of main because there's no merge. You're not going to merge. Forget it.

It doesn't work. So it's very painful that way. So with all flexibility comes a cost, and I think the cost is quite high depending on the kind of project you're doing. And we have good computers. It shouldn't take five minutes to do anything. Well, FPGA stuff is hard. I guess so. I think that there's a lot of computation involved with that.

And one of the advantages to the PSoC is that it has been available when no other chip has been. And we can tell you why. Because it's hard. But yeah, I don't think other than that, I have not really had big complaints about the HAL versus the STM32.

I think they're equivalently annoying. Equivalently annoying, that probably should be the title. You know, there was definitely bugs in the HAL and things that people complained about six years ago that they said they fixed and they didn't and stuff like that, but that's pretty common across the industry. So I'm not saying don't choose it, but definitely go in with your eyes open and maybe grab a dev board and play around with it some to kind of get a feel for things

because it's a different kind of chip. And like all vendor tools, they put the minimal effort required into making them usable by actual engineers. Okay, so going on. Yeah. We have a question from Carson, who had recently listened to episode 19.

How? I thought we deleted all of those. You're not allowed to listen to those early ones. In which we talked about the Embedded System Conference Design West, and Carson wanted to know if that conference still happens. And the answer

is yes, sometimes. And then went on to ask, are there other conferences? Yes. There are many conferences. And at this point, I don't want to make a list because it will immediately go out of date. There are some other lists out there. QT had a list that wasn't bad.

But Search Embedded Systems Conference and your major metropolitan area, or Maker's Conference. Actually, Maker Conference in Los Angeles led me to this event page that had just hundreds of them. It was pretty cool. And Maker Conference in New York led me to the Maker Faire. And Embedded Systems Conference in New York led me to some international distributed systems conference. So, yeah, they are there. I know that there's Minnesota, Las Vegas, Los Angeles, Silicon Valley, New York. But realistically, I think it's more than that.

I think you can find the littler ones all around and some are online, like embedded online. And hardware.io usually has an online component. Supercon is coming up. There's some other conference coming up that I don't know the name to, but I keep hearing people want to go. Did you ever figure out what that one was? Super secret, super special conference that we probably shouldn't talk about, but I can't talk about it because I don't know what it is.

I assume it's taking place in my house and I don't know about it. I'm just going to wake up one morning and there's going to be all these people in my house and I'm going to tell them to get out. Okay, I have one more question for us. One more question for us. Okay. This is from Ricardo, who asked, who sounded like he was in a bit of a hard spot, started a new job. So, in your opinion, what is the best way of understanding firmware that's built on custom hardware for which there is no documentation, and the author,

who is more experienced, isn't too keen on answering questions. When the questions are somewhat answered, the answers are often more confusing than the firmware itself. What do you do as a junior engineer? Just give me flashbacks to the first actual technical job I had, which was I was an unpaid intern at a place called the San Juan Capistrano Research Institute. It was between senior year of high school and freshman year of college. And I walk into this place and they need help with various things. And they decided, hey, we have this mass spectrometer we got off the back of a truck, but we can't make it work and we don't have a manual. Let's give it to the intern.

Why don't you take a look at this thing and see if you can make it work. And I spent a few weeks with a laptop, a laptop in 1992. Don't know how I had a laptop. Maybe it wasn't a laptop. No, it must've been a laptop. Anyway, trying to hook to this thing's serial port and get it to talk to me in any way, shape, or form.

And I think I was trying on BBA, like trying on the rudimentary CompuServe and other things to find documentation. Anyway, did not succeed at all. I felt very guilty, but I'm sorry. I sent him on a Capistrano recension through that spectrometer is no longer, never gonna work. Yeah. So the advantage here is you have the code, right? I'm assuming

it has the code. Yes. Access to the code. Wait a minute. Let's answer this from the other side. Why would you act like the jerk senior engineer? In what cases would you not want to answer things? Ooh, that's a really interesting question. Okay. There's a lot of reasons. Some of them, let's take, I'm just a contrary jerk out of the equation. Sure.

That's a possibility. But one is I am extremely busy. I am already being asked to do things that I can't do. And somebody is now asking me to do more things. And they're asking questions about things that I fully understand. And therefore, why don't they understand them? The code is right there. Mm-hmm.

So there's that aspect of it, which is a bit of a non-empathetic response. But when you're tired and at the end of your rope, wanting to help other people is not often the first thing that comes to mind. Yes, and the flip side of that is the more people you help, the less work you have to do. But it also sometimes feels like the more people you help, the less work you have to do. But it also sometimes feels like the more people you help, the less work you get done. But I don't want to get work done. I want to get as little work done to fulfill my job at a high

level as I can. No, no. The goal is to get a maximum amount of work done, but you don't have to do it all if you help people. Yeah. Exactly. Okay. We're going to agree. But there's also the case where you get someone new. Why? Why? Why? Yes.

Why? Why? Yes. But I don't think that. And I don't want to justify it because the truth is I did it because the other way didn't work and I never figured it out. Or I did it because they told me they were going to need some other feature and they never wanted it and now it's in this kind of crappy state and I don't want to explain. Yeah.

But given all that, it does sound like, to just take what he said as fact, that's a difficult situation because he said there's no documentation. So we're back to helping the new person. Yes. Instead of being the cranky engineer. Giving advice instead of being empathetic to the gray beard. Okay. Okay, so he said there's no documentation? There's no documentation.

There is firmware, but it you know, it's big. It's built on custom hardware. The first thing I would do is ask what your job is. That's a good one. Is your job to understand all the firmware? Because I don't understand all the firmware on any of the projects I work on. And I'm, I think, a fairly senior engineer at this point. I have a lot of gray hairs.

So that's part A, is kind of understand what you need to know, what you need to understand. Because if you're trying to understand the entire firmware, that may be a fool's errand. But understanding the idea of the firmware, understanding what the user is supposed to... Okay, go ahead. Yeah. I mean, certainly you should understand what the product is and what it looks like from the outside,

what it does, what its purpose is, what its inputs and outputs are, that sort of thing. What I'm saying is, if your task as the junior engineer is to work on bugs related to... The UI. The display the display, the UI, then you probably don't need to go learning about how the Bluetooth subsystem works right now.

Or the file system necessarily. Or the innards of some of these other lower level systems. The whole frequency processing system you may not need to know right now. What you do need to know is probably how do I get to the UI? So what's the init sequence and how does that follow? So that can be learned through a debugger or through adding logging as the system boots up. Or if there isn't logging, or if there is already logging, just looking through that and finding where those messages come out throughout the system. And then diagram that. So this is the init flow. And here's how do I get to the my piece. Once you've defined your piece, then you can start looking at the code for that.

And it's a lot less, usually, depending on how the code is written, it's a lot less of a nightmare because you're not trying to get this whole gestalt of the firmware into your head and all the little interactions and things. So that'd be my advice is figure out what you're responsible for, figure out how the system gets to what you're responsible for,

and then figure out how from that central point, things get connected. What are the events and the inputs outputs for and kind of the block diagram with that central point that kind of like the heliocentric model where your part is the center of the solar system and the other stuff may be planets you don't need to know

everything about. I would say they need the schematic and the user manual. It depends on what they are doing. I have rarely needed a schematic.

You just need the schematic to like clutch. You know, just in case. I would certainly try to get it. It's nice to have, even if you don't need it regularly. But the user manual, as you said, you need to know what it is trying to do. And there's a giant box between what it is, what the schematic

says it is. The schematic? Or the hardware block diagram, I would take that. But I'm assuming that none of the senior engineers will talk. Get all the information you can, certainly. And the schematic, sometimes you can map the software block

diagram onto the schematic. Yeah, because if there is a spy flash on the schematic, there's going to be code somewhere for a spy flash. There's a spy flash driver, yeah. So you get an idea of what the hardware is, and then you get an idea of what it's being used for. And then over time, you try to fill in the giant gap between them. And maybe that's looking at the file names

and trying to figure out what that means. I mean, you have something called spyflash.c and then you have something called kvstore.c. If you know that a kvstore is a key value store and that usually lives on a spyflash, all right, now you're going through if you don't know that then you probably don't need to play with it until somebody says i have a bug here and you figure out okay so the spy flash is here and it's used by this and that

but like i'm just thinking back to my experience early experiences as a junior engineer this was at cisco and these were big, complex devices. Those were big, complex devices. And, you know, it's hard to call them embedded systems, but they were. They had no screens or anything. They were, you know, purpose-built devices with custom hardware. And they ran a fully custom OS with lots of complexity that at the point I got there was probably 10 years old, at least. And, you know,

the stuff I was working on was very focused. I spent most of my time in two or three C files for a year and didn't really, I mean, I learned about some things outside of those, but only very briefly. And so I never got a real sense for the whole system there. So if you're being asked to do that, then that seems a little odd to me because as a junior engineer, you should not be expected to understand and be able to be productive anywhere in the system. That's fair.

I always needed to have at least an image of what the whole system was, even if I didn't understand the details. I needed the highest level, here's how it works. It depends on the complexity of the system. But it really does depend on the complexity. It's like, okay, yeah, this is a chip with these sensors and this kind of display, and it does this. But if it's something much more complicated, running a bigger OS or, you know, embedded systems comprise a lot. For all we know, he's talking about a system with an A-series ARM and Linux and, you know, a bunch of other stuff. In which case, yeah, good luck understanding all of that. But I always go back to sketches. You know, these are all the parts.

These are what they talk to. This is where the software goes. And knowing that there are big blocks I don't understand, and that's okay. When I get there, I will look into them. But right now, it's just something I don't need to know. It's a cartography project. Yeah. You got to put the dragons out, figure out where you're going to let the dragons live.

But then, you know, whatever coastline you need to get a fine detail, figure out what that is. Did you ever use Doxygen call graph stuff? I've used it a couple times, but I've never found it as helpful as I wanted it to be. I find Doxygen to be a proforma formality that is basically useless. Alright. The best thing I can say about Doxygen is

if people use it, it forces them to make nice function comments that can give you an API description. I'm not even going to say documentation. But it's wished. Because documentation usually involves prose,

which Doxygen does not encourage. So I have used Doxygen rarely as a consumer. I think there was one project I kind of used it. I've never found it a lot useful. And when I go to projects that depend on it for their documentation, I'm always irritated. Oh, the hells.

The hells. I could have looked at the header file. Okay, and I totally agree with you about looking through the boot logs, walking through main, trying to figure out where things go that way until you get to the part where you

need to be in the debugger. And then you need to change variables and see what paths change. And just generally, you have to get your debugger working. And the other thing, which, you know, the reason I asked about why would you be the grumpy, unhelpful person? Because there are times that that happens. And what the engineer, if they aren't a jerk, would like to help you. Most engineers are jerks. But they view training you as time that isn't spent getting things done. And so if you want to be a super, if you want to be the teacher's pet, which I know some of us do,

try to be helpful to them. Try it, try it, not, not get code, not, not get coffee. Just get coffee. I mean, I don't, I don't mean to be obsequious. Bring them cake. Bring me cake. Bring cake is always good. Give me their phone number.

I'll call them and say that they should be nice to you. But, you know, when they give you some information, try to understand as much as you can about it. So, yes, I agree. That's good advice. I'm a little... It is the company's job to make you, to give you a path to productivity.

So if they've hired you, they want you to get things done. If the company is not providing you the resources to get up to speed, that's a company problem. And I know you're a junior and there's not much you can do about it. but I'm just saying, putting this all on the senior engineer or vice versa on the junior person trying to extract information for the senior

engineer or wherever, there needs to be other support systems. And some companies are better than others at this, but to just be dumped into the deep end as a junior engineer is a failing of a company. As a junior engineer, I agree. As someone who ends up going working with little companies who have whose engineers have left, and now they need someone to make a change,

and nobody remembers how to build the system. Yeah, that's our job. And someone else's code is totally overwhelming. Yeah. And I break it apart until I understand what I need to get working, just as you were saying. But you're right. That's my job. That's my job because it is something I have worked to be good at.

Yeah. As a junior engineer. And it costs the money. Oh, yeah. It's expensive, right? And that's the last thing a company wants from one of its employees is to have an employee be a cost suck because they're stuck or lost or unable to make progress because somebody won't talk to them. So I guess what I'm saying is there should be other resources you can go to and say, I need help getting up to speed on the system. And that person goes and talks to whoever needs to talk to you instead of you going to them. But it isn't about getting everything fed to you.

Right. Which I don't think Ricardo was in that boat at all. But I did have an experience recently where somebody wanted me, wanted help, and the truth was they wanted me to spoon feed it to them. And I wasn't going to. I wasn't interested. I just, you know, I gave you the resources. I don't care if you want to. You gave them the resources.

I don't care if you want to pay me to read them aloud to you. I don't want to read them aloud to you. But you have the resources. Oh, no, I totally gave the resources. And then was irritated when they came back and said, well, that requires a login. And I'm like, yeah, and I don't work for the company that does the login. Login's free. Get a fake email account.

I don't care. Why are you talking to me still? Go, go. I don't care. Why are you talking to me still? Go, go. Sorry. Dramatic. All right. Yeah. So, I mean, you know,

without knowing the details of the situation and what resources are available and what the system's complexity is and what the management structure of the company is, that's about the extent of what I can contribute, I think, as suggestions. Me too. I mean, there are a whole bunch of unknowns, but it is a relatively common thing to do

and a common feeling to have, because I definitely have felt like that. Like, the engineer that I'm supposed to be asking a question to has pretty much said, go away, bother you, go away, kid, you're bothering me. And I don't know what I'm supposed to do. And I feel bad because I'm afraid they're going to fire me because I'm not getting anything done, but I don't know how to get anything done. And it just becomes this, and to some extent, have a little patience. You need eight hours of training. Your senior engineer has one hour a day. That doesn't mean that the time is wasted. It just means it's not going to happen as fast as you want. We're assuming they're giving him any time.

But for me, if I had understood that I was not going to be fired because I was only getting trained one hour a day and I needed eight hours of training, that would have helped me. Yeah. Because I wouldn't have felt like I'm not getting anything done, and this job is so important. I mean, I've also had that situation, and I quit a job for that reason. After six or eight months.

Yeah, that was different. I was not getting help. I could not figure out how to make progress in the code. Didn't understand anything. There was not getting help. I could not figure out how to make progress in the code. Didn't understand anything. There was no way to figure it out. The documentation was hundreds of pages of FPGA, you know, specifications that a driver was supposed to be built. Just forget it. But you were also lost between two teams.

I was lost between two teams, but that was the most irritating part of it was... Was not being able to contribute. The person I actually worked for, who was not the person I was supposed to be working for, was demanding work in a system that was impenetrable. And there was nobody there to help me because the team didn't want to talk to me. Because you were supposed to be working for someone else. Why invest time in training you when as soon as they train you you're going to go work for somebody else and yeah you know i know that feeling of here is a wall of code here is five years of work of 100 engineers good luck go make some progress on this feature which is a one-line description it's like what so i mean and the other thing is um aside from that, you know, it's not clear for me the problem is code, getting lost in the code, or just getting set up. Like, is there a problem getting your ID configured, all the stuff installed?

Is that well documented? I mean, junior people have a lot of trouble with that sometimes, too. Rightfully so. Right, because it's usually... One of the hardest things. It shouldn't be, but most companies have a completely fly-by-night, here's a Dropbox folder with eight installers,

three of them are out of date, two are missing, and here's a Word doc that was written once but never updated. Even though everybody knows that you have to skip step six. That guides you through the process instead of, you know, here is a conda or here is a docker or here is some very simple installer that has everything you need.

Rant over on that. But if that's a problem, then that has different requirements. And sometimes you do need a senior engineer to help you with that depending on how poorly they've documented their install system. And that's another one of those things where it's like, can't make progress, and I can't make this process up from whole cloth. So management, the person you report to is the person who is responsible for your success. And if they're not helping, or if you haven't talked to them,

then that's a problem. Speaking of Docker, you've been using Docker more. Yeah. And it works the same on all the computers you're using, right? You should see him. It's not like he's turning purple. He's just so sad now.

He's like, Eeyore, I feel like I'm already reading Winnie the Pooh to you. Because Eeyore is here. Tell me about it, Eeyore. The problem is not Docker. Right. The problem is NVIDIA drivers. And that sort of thing. And CUDA drivers.

And various other drivers that are outside of Docker. Ah. I just heard the swearing. Those are responsible for the things that are different. The nice thing about Docker, to flip it around on you, is that I can run the same things on two different computers

and see that one isn't working as well. And that has nothing to do with Docker. It is an indication that something's different about the computer. Ah. Not to say I love Docker, but I do understand it a little better, and I have been using it somewhat successfully.

Yeah, when I started using it last summer, it was really useful. Still don't think I would even attempt Windows, but on Linux, it makes a lot of sense. Do you want to talk about your adventures in hardware

comparative studies? I mean, not really. I mean, there's not much to tell. I have two systems that the class, so they're not physical. Okay. TensorFlow, training machine learning models, one computer, both Docker, systems that the class so they're not physical okay tensorflow training machine learning models one computer

both docker same docker by which i mean installed from the same docker file same hardware gpu from what i can tell similar hardware for the cpu and all that stuff both Both Linux machines. And one is twice as slow as the other. So I'm kind of trying to figure out what's going on there. And it's not that easy.

So I have some ideas and I've run some benchmarks. But nothing's coming up as a red flag saying this is the thing. I suspected something silly that I haven't found yet. But that's what I've been doing for the last couple of days. Do you need to turn off the air conditioning bit like you used to in old cars? The what now? That was the turbo button. You turned off the air conditioning.

Oh, God. Sorry. I don't think so. I don't know that they have those. You know, that client, which we've shared, one time I had a similar problem. And it was because a fan failed on a CPU and so the CPU wasn't going fast enough. It could be. They've claimed to have looked at things like that.

And then there's always the disk being different. One time with a problem like that, I had two disks with different page sizes, and that made a difference because my files were all very small. That was awful. And it took me forever to figure out that it was page sizes. You know, I did benchmark the drive on both of them that I thought the data was coming on, but now I think about it might have been the wrong drive. Because there's the running drive and there's the data drive.

Yeah, and the model that caches all the images in the model directory, which is in my home directory, which is not where it's benchmarked. So it could be there. I'll look. But yeah, you know, doing Linux-y sysadmin stuff in my, for some reason, as a side project. Get paid for it. Yeah. Yeah. for some reason, as a side project. Get paid for it. Yeah.

Yeah, but I'm kind of looking, you know, after vacation, to bring it all around, back to the beginning, I'm kind of looking forward to, you know, maybe not doing so much for a little while. Yeah, I think we'll both have some time, October-ish,

and maybe we are not fishing for clients right away. Maybe we're taking a little time off. Yeah. Because October in Santa Cruz is the best month. Hopefully. Maybe it'll be the hottest month. All right, we are well over my 49.

This is not a tight 49 anymore. Okay, well then, let's see. A very clever brain. We should make it. Oh, sorry. Thank you to Christopher for producing and, of course, for co-hosting. Thank you for listening. You can always contact us at showatembedded.fm or hit the contact link on embedded.fm yeah you got it uh there may be a

couple of links to this show but there's not a lot i was going to post the astrophotography guy so i'll keep that in my head uh and we do we're still doing transcripts although they may be late and not all shows may have them but the the Burnout show did and it was very good. So if you missed that show or you want to check some fact in there, you should go back to the transcript. And we have a newsletter that you can sign up for on the website and it comes out once a week. And usually it's just stuff about the show and the upcoming show. So you get a little sneak peek of what's coming up in a couple of days. And I'm going to try to collect things that might be of interest to our listeners

to throw in there that are either tangentially related to the show or things that other people suggest. So if you have suggestions for interesting topics or articles, things to link to, you can always send that to me and I will throw them in there, assuming I like them. So at Embedded.fm, that's how you reach him too. It gets to both of us. Okay, when we last were with Pooh and Piglet,

they were trying to decide how to catch a heffalump. And they were trying to figure out whether or not a very deep pit would work, generally needed a cunning trap. Suppose, he said to Piglet, you wanted to catch me. How would you do it? Well, said Piglet, I should do it like this. I should make a trap and I should put a jar of honey in the trap and you would smell it and you would go in after it. And I would go in after it, said Pooh excitedly, only very carefully so as not to hurt myself. And I would get to the jar of honey and I should

lick around the edges first of all, pretending that there wasn't any more, you know. And then I should walk away and think about it a little. And then I should come back and start licking the middle of the jar. And then, yes, yes, well, never mind about that. There you would be and there I should catch you. Now, the first thing to think of, what do heffalumps like? I should think acorns, don't you? We'll get a lot. I say, wake up, Pooh.

Pooh, who had gone into a very happy dream, woke up with a start and said that honey was a much more trappy thing than acorns. Piglet didn't think so. And they were just going to argue about it when Piglet remembered that if they put acorns in the trap, he would have to find the acorns. But if they put honey, then Pooh would have to get up some of his own honey. So he said, all right then, honey then. Just as Pooh too remembered and was going to say, all right, acorns.

Honey, said Piglet to himself in a thoughtful way, as if it were now settled. I'll dig the pit and you go get the honey. Very well, said Pooh, and he stumped off.